Какую инфраструктуру небольшой компании стоит иметь в первую очередь?

Почему этот выбор быстро становится дорогим

Когда люди спрашивают, какую инфраструктуру должна иметь небольшая компания, проблема с расходами обычно начинается еще до того, как это замечают. Сервис сначала выглядит дешевым, настройка занимает один вечер, и первый счет кажется безобидным. Через шесть месяцев нагрузка растет, появляются ограничения, и ежемесячные траты уже не совпадают с первоначальным планом.

Так происходит потому, что многие управляемые инструменты берут плату за то, что растет быстрее всего. Хранилище незаметно увеличивается. Заканчиваются минуты на сборку. Объем логов резко возрастает после одного шумного релиза. Команда, которая ожидала тратить несколько сотен долларов в месяц, в итоге может платить в несколько раз больше, даже без сильного роста выручки.

Именно из-за низкой стартовой цены выбор и кажется сложным. На старте безопаснее не брать ничего на себя, но некоторые сервисы легко подключить и дорого поддерживать. Когда ваше приложение, данные, уведомления, бэкапы и внутренние процессы зависят от одного вендора, счет перестает быть простой строкой расходов. Он начинает влиять на продукт, найм и решения по поддержке.

Поздний переезд часто стоит дороже, чем раннее планирование. Данные нужно переносить. Скрипты ломаются. Команде приходится осваивать новую схему, одновременно продолжая выпускать функции и помогать клиентам. Если сервис затрагивает продакшен, даже аккуратная миграция может съесть дни поддержки и создать стресс, который никто не планировал.

Кэшфлоу чувствует это первым. Растущий счет за инфраструктуру может отложить найм, сократить бюджет на тестирование или заставить основателя снова заниматься операционкой вместо продаж или продукта. Поддержка тоже это ощущает. Время, потраченное на лимиты, перерасходы или неожиданные всплески использования, — это время, не потраченное на решение проблем клиентов.

Небольшой компании не нужно владеть всем подряд. Ей стоит внимательно смотреть на системы, которые работают каждый день, растут вместе с нагрузкой и болезненно реагируют на скачки цен. Часто именно там владение экономит деньги и делает месяц спокойнее для команды.

Что значит владеть инфраструктурой

Основатели часто слышат «владеть инфраструктурой» и думают о серверах. Но это лишь часть картины. Вы владеете инфраструктурой, когда ваша команда настраивает ее, меняет, наблюдает за ней, чинит ее и несет риск, если она ломается.

Есть простой тест. Если ваша команда может войти в систему и изменить, как она работает изо дня в день, эта система уже часть вашей инфраструктуры. Если можно задавать правила доступа, настраивать производительность, добавлять мощность, смотреть логи, делать бэкапы и восстанавливать данные, значит, вы владеете этим уровнем на практике.

Считайте те системы, которыми команда реально управляет, а не только те, за которые платит. В список часто входят вычисления, базы данных, хранилище, очереди, кэши, мониторинг, логи, секреты, бэкапы и расписанные задачи. Малые команды постоянно забывают про мониторинг и бэкапы, но этим системам все равно нужны настройка, проверка и обслуживание.

Владение предполагает и рутинную работу. Кто-то должен обновлять систему, менять секреты, проверять алерты, тестировать восстановление и решать, что делать во время сбоя. Если в вашей команде никто этим не занимается, вы на самом деле не владеете этой частью, даже если счет приходит вам.

Полезно также отделять инфраструктуру от бизнес-программ, на которые вы просто подписываетесь. Инструмент для зарплат, CRM, бухгалтерское приложение и служба поддержки могут быть очень важными, но обычно это сервисы, которыми вы пользуетесь, а не инфраструктура, которой вы управляете. Там вы управляете пользователями и оплатой. Но не движком базы данных, уровнем хранения или процессом восстановления внутри продукта.

Некоторые инструменты находятся посередине. Управляемая база данных все равно может считаться инфраструктурой, если ваша команда контролирует изменения схемы, доступы, хранение, проверку бэкапов и выбор масштаба. Вендор управляет нижними уровнями, но ваша команда все равно обслуживает сервис в повседневной работе.

Запишите это простыми словами. По каждой системе отметьте, чем ваша команда управляет без обращения в поддержку, чем управляет вендор и кого вызывают, когда все ломается. Такой список обычно полезнее, чем аккуратная схема, потому что он показывает, где владение настоящее, а где оно только кажется настоящим.

Начинайте с работы, которая не останавливается

Начинайте с частей стека, которые работают весь день и почти не делают пауз. Такие нагрузки дают самые понятные цифры по расходам, времени команды и риску сбоев.

Хорошие первые кандидаты обычно имеют ровный спрос. Они используют примерно одинаковые CPU, память, диск и сеть каждую неделю, поэтому серверы можно подбирать с меньшим количеством догадок. Продакшен-база данных, внутренние CI-раннеры, логирование, мониторинг и основной backend приложения часто подходят для этого лучше, чем пакетные загрузки или разовые маркетинговые проекты.

Работает простое правило: если сервис работает каждый день, имеет предсказуемую нагрузку и команда часто к нему обращается, владение им проще оправдать. База данных, обслуживающая приложение круглосуточно, билд-раннеры, используемые на каждом merge, панели мониторинга, которые проверяют каждую неделю, и хранилище, которое растет постепенно, — все это лучше кандидаты, чем что-то, что просыпается раз в квартал.

Такие системы еще и формируют правильные привычки. Когда люди уже умеют делать бэкап базы данных, ротировать логи, следить за диском или безопасно перезапускать сервис, они совершают меньше дорогих ошибок. Знакомые системы — лучшее место для старта, чем что-то, за чем никто не хочет присматривать в два часа ночи.

Поэтому опытные операторы часто держат ежедневные инструменты под рукой. Oleg Sotnikov, например, использует self-hosted CI/CD, observability и production-системы в среде клиентов, потому что эти инструменты нужны постоянно и месяц за месяцем окупают тщательную настройку.

Бурные, скачущие нагрузки лучше оставить на потом. Разовая квартальная аналитическая задача, пик трафика в Black Friday или экспериментальная AI-фича могут дольше оставаться на управляемых сервисах. Такие нагрузки сложнее размерить, и облачная модель оплаты все еще может быть разумной, когда использование сильно прыгает.

Сначала берите под контроль скучные и постоянные части. Их проще измерять, проще изучать и обычно дешевле хорошо обслуживать на длинной дистанции.

Ищите цены, которые меняются против вас

Низкая стартовая цена может скрывать самые неприятные расходы: те, что растут именно тогда, когда ваш бизнес наконец начинает расти. Управляемые сервисы часто выглядят дешево на маленьком масштабе, а потом превращаются в ежемесячный сюрприз, когда счет зависит от запросов, мест, событий или объема данных.

Оплата за запросы может наказывать за успех. Если ваше приложение получает больше трафика, каждый API-вызов, запуск задачи или чтение из базы данных суммируется. Оплата за пользователя бьет по-другому. Команда может вырасти с 8 до 25 человек, и вдруг инструмент, который казался мелким, становится заметной статьей расходов.

Оплата за события — одна из самых легких ловушек. Логи, алерты, трассировка и отслеживание ошибок сначала кажутся безобидными. Потом один шумный релиз, один цикл бага или один новый клиент за день многократно увеличивает объем событий.

Дополнительные сборы не менее важны, чем цена на первой странице. Сервис может выглядеть нормально, пока вы не добавите бэкапы, передачу данных, долгосрочное хранение логов или плату за восстановление. Многие небольшие команды смотрят только на основной тариф и пропускают все остальное. Такая ошибка быстро становится дорогой.

Быстрый стресс-тест помогает:

• Что будет, если нагрузка удвоится через шесть месяцев?
• Какая строка расходов растет быстрее всего?
• Какой платеж зависит от поведения, которое вы не можете полностью контролировать?
• Какой счет будет болезненным, если в следующем квартале он утроится?

Если хотя бы один ответ вызывает тревогу, присмотритесь к этому участку стека внимательнее.

Небольшая софтверная компания может спокойно платить за управляемую базу данных, потому что расходы растут довольно предсказуемо. Та же компания может захотеть держать у себя логи, бэкапы или билд-раннеры, потому что эти счета могут резко меняться из-за трафика, неудачных джобов или всплеска деплоев. Часто это и есть более разумное разделение.

Владеть инфраструктурой не значит владеть всем. Это значит брать под контроль те части, где риск цены выше, чем риск эксплуатации. Если внезапный скачок счета заставит вас заморозить найм, сократить работу над продуктом или объяснять клиентам неприятности, такая часть — хороший кандидат для переноса внутрь компании.

Используйте простой пошаговый тест

Начинайте с тех нагрузок, которые можно измерить, а не с тех, вокруг которых все любят спорить. Короткая таблица почти всегда лучше сильного мнения.

Запишите каждую нагрузку, за которую вы платите ежемесячно. Включите систему контроля версий, CI-раннеры, базы данных, бэкапы, мониторинг, логи, внутренние инструменты, файловое хранилище и все, чем команда пользуется каждую неделю. Рядом укажите реальный месячный счет, включая перерасход, поддержку и дополнительные места.

Потом разделите список на две группы: стабильные и скачущие. Базу данных, которая работает весь день и мало меняется от месяца к месяцу, проще оценить. Нагрузка, которая растет во время запусков, импортов или при сильном трафике, сложнее для владения, потому что планировать нужно худший месяц, а не средний.

Для каждой нагрузки используйте одни и те же пять проверок:

1. Запишите обычную ежемесячную стоимость и самый высокий счет за последние несколько месяцев.
2. Отметьте, остается ли использование ровным или скачет без особого предупреждения.
3. Оцените, сколько часов команды требуется, чтобы это запускать, обновлять, бэкапить и наблюдать за системой.
4. Сравните полную стоимость за один год и за три года, а не только за этот месяц.
5. Выберите одну малорисковую нагрузку, которую можно перенести первой, не подвергая клиентов опасности.

Оценка трудозатрат важнее, чем многим командам кажется. Управляемый сервис может выглядеть дорогим, пока не посчитаешь время инженеров, которое понадобится, чтобы делать то же самое своими силами. И наоборот: низкая стартовая цена может стать неприятной, когда растет хранилище, копятся логи или меняется политика вендора.

Небольшая софтверная компания может проверить это сначала на CI-раннерах. Нагрузка там ровная, риск ограничен, а команда за несколько недель может измерить время сборки, простои и ежемесячные расходы. Oleg Sotnikov использовал такой подход с self-hosted GitLab, Sentry, Grafana, Prometheus и Loki, но метод отлично работает и для команды из пяти человек.

Перенесите одну нагрузку, измеряйте результат 30–60 дней и запишите, что изменилось. Если затраты остаются ниже, а команда справляется с работой, переносите следующую стабильную нагрузку. Если переезд создает больше работы, чем экономит, остановитесь на этом.

Реальный пример небольшой софтверной компании

Представьте софтверную компанию из 10 человек. Она продает подписочное веб-приложение, а за кулисами у нее четыре важных элемента: само приложение, база данных, файловое хранилище для загрузок и почта для сброса паролей, счетов и уведомлений по аккаунту.

Сначала команда использует управляемые сервисы почти для всего, потому что настройка идет быстро. Это нормально, пока трафик небольшой. Через несколько месяцев счет начинает расти быстрее, чем клиентская база, а некоторые суммы меняются от месяца к месяцу без очевидной причины.

Команда решает оставить почту у вендора. Доставкой писем нужно заниматься каждый день, когда что-то идет не так. Меняются правила спама, копятся отказы, а репутация отправителя может быстро испортиться. Для небольшой команды это отвлекающая работа, поэтому платить специалисту оправданно.

При этом команда решает оставить у себя серверы приложения и базу данных. Нагрузка у них в большинстве дней стабильная, и трафик можно достаточно хорошо прогнозировать, чтобы арендовать несколько фиксированных серверов. Так расходы легче планировать. Плюс появляется больше контроля над бэкапами, обновлениями и отказоустойчивостью, вместо того чтобы доплачивать каждый раз, когда использование немного растет.

Файловое хранилище они считают промежуточным вариантом. Загрузки растут медленно, поэтому хранение оставляют простым и не строят вокруг него кастомную систему. Цель не в том, чтобы владеть каждой частью. Цель в том, чтобы владеть тем, где предсказуемое использование делает собственное решение дешевле.

Следующая проблема — логи и мониторинг. Сначала их счет за управляемое логирование кажется небольшим, но после того как команда добавляет больше debug-данных и более длительное хранение, платежи за события начинают неприятно расти. Они переносят логи и дашборды внутрь компании на скромный сервер. Настройка требует усилий, но ежемесячная стоимость перестает прыгать.

Через 60 дней они смотрят на три показателя:

• Общие ежемесячные расходы
• Аптайм и количество инцидентов
• Часы, которые команда тратит на поддержку и обслуживание

Если расходы снижаются, аптайм остается стабильным, а время на поддержку не становится чрезмерным, они оставляют схему. Если в одной из областей становится хуже, они откатывают ее назад. Для небольшой компании это обычно лучший ответ: владеть скучными, стабильными нагрузками и оставлять капризные у вендора.

Ошибки, которые тратят деньги впустую

Самый быстрый способ выбросить деньги — взять на себя больше, чем ваша команда реально может поддерживать. Небольшая компания покупает серверы, настраивает базы, добавляет мониторинг и месяц чувствует себя под контролем. Потом один человек уходит, алерты копятся, и никто не хочет трогать продакшен.

Дешевое железо создает ту же проблему. Ежемесячный счет выглядит отлично, но настоящая стоимость скрыта в задачах бэкапа, тестах восстановления, сбоях дисков и времени на обновление сервера. Команды часто экономят немного на бумаге и теряют гораздо больше, когда что-то ломается.

Данные клиентов только усугубляют ситуацию. Переносить их на новый стек без плана отката — это азартная игра, а не миграция. Если импорт пошел не так, права доступа сломались или поисковые индексы устарели, вам нужен понятный путь назад к старой системе в течение часов, а не расплывчатый план в чьей-то голове.

Еще одна частая утечка денег — слишком долго платить дважды. Команды оставляют старый управляемый сервис «на всякий случай» и одновременно платят за новую настройку, дополнительное хранилище и больше логов. Короткое пересечение нормально. Шесть месяцев двойной оплаты обычно означает, что за переездом так и не появился настоящий владелец.

Скрытые расходы обычно одни и те же: место под бэкапы, мониторинг, время инженеров на обновления и продление сертификатов, двойные счета во время миграции и простой, когда никто не знает шаги восстановления.

Самая неприятная ошибка совсем проста. Никто не отвечает за алерты вне рабочего времени. Инфраструктура — это не только счет за машину. Кто-то должен отвечать на уведомления, смотреть графики, перезапускать задачи и решать, может ли сбой подождать до утра. Если этот человек — «тот, кто заметил первым», значит, схема уже слишком велика для команды.

Небольшие компании выигрывают, когда начинают с одной-двух скучных систем, которые можно хорошо поддерживать. Почта, авторизация и платежные системы часто дольше остаются у вендора не просто так. База данных, билд-раннеры или внутренние инструменты могут быть более разумным первым кандидатом для владения, если они работают каждый день и расходы остаются предсказуемыми.

Если никто в вашей команде не умеет сделать бэкап системы, быстро восстановить ее и обработать алерт в два часа ночи, пока не переносите ее.

Быстрые проверки перед тем, как решиться

Владение инфраструктурой кажется дешевым, если сравнивать один месячный счет с другим. Сложная часть — все, что вокруг этого счета: настройка, обновления, мониторинг, бэкапы и ночи, когда что-то ломается.

Прежде чем переносить нагрузку на собственные системы, задайте себе пять простых вопросов:

• Могут ли один или два человека обслуживать ее без постоянной усталости от алертов?
• Знаете ли вы свою обычную месячную нагрузку достаточно хорошо, чтобы подобрать вычисления, хранилище и сетевой трафик?
• Сможете ли вы сделать бэкап и восстановить систему, когда люди устали и находятся под давлением?
• Сможете ли вы уйти позже без полной перестройки продукта?
• После учета времени команды экономия все еще существенна?

Именно здесь многие команды ошибаются в расчетах. Они сравнивают цену управляемой базы данных с ценой VM и на этом останавливаются. Они не учитывают обновления, рост диска, очистку логов, неудачные деплои или стоимость того, что вы единственный человек, который умеет чинить продакшен.

Нагрузка — еще одно слепое пятно. Если ваше приложение каждый день выполняет одинаковые фоновые задачи, использовать собственное решение проще и оно может быть оправдано. Если трафик скачет или зависит от сезонных кампаний, управляемые сервисы часто стоят дороже в месяц, но избавляют вас от бесконечного масштабирования и паники.

Возможность выйти важнее, чем многим кажется. Если вы не можете вернуться к управляемому варианту за неделю или две, ваша схема слишком прилипчива. Делайте форматы данных проще, избегайте кастомной связки там, где можно, и записывайте шаги, пока настройка еще свежа.

Именно поэтому опытные операторы обычно любят скучные схемы. Oleg Sotnikov показывал, что экономная инфраструктура может работать на серьезном масштабе, если архитектура простая, хорошо наблюдаемая и рассчитана на реальный спрос. Не копируйте чужой стек. Владейте только тем, что ваша команда может понять, восстановить и заменить.

Если вы не можете четко измерить нагрузку и быстро восстановить ее, подождите.

Что делать дальше

Выберите одну нагрузку, которая работает каждый день и ведет себя одинаково большую часть недели. Хорошие первые кандидаты — внутренний Git-хостинг, мониторинг, логирование, обычные билд-раннеры или база данных для стабильного продукта. Избегайте ярких проектов. Скучные системы проще оценить, проще наблюдать и проще проверить через месяц.

Назначьте дату проверки через 30 дней после запуска. Такой дедлайн помогает оставаться честными. В конце теста сравните четыре вещи: ежемесячные расходы, время команды, число сбоев и то, насколько тяжело была поддержка. Если собственная схема снижает расходы без нового стресса, оставляйте ее. Если она съедает время, верните сервис вендору и считайте эксперимент оплачиваемым исследованием.

Перед тем как что-то переключать, запишите, кто за что отвечает:

• Обновления и патчи безопасности
• Бэкапы и тесты восстановления
• Алерты и проверки дежурства
• Ежемесячный контроль расходов

Если никто не отвечает за эти четыре пункта, вы еще не владеете инфраструктурой. Вы владеете будущей проблемой.

Оставьте скачущие системы у вендоров пока что. То же касается узких инструментов, которым нужен глубокий профильный уход, например продвинутых поисковых кластеров или тяжелых видео-пайплайнов. На бумаге вендор может стоить дороже, но это все равно может быть дешевле, чем нанимать людей под плохое совпадение.

Здравый вариант для многих небольших софтверных компаний — сначала self-hosted CI-раннеры и observability, а email, платежи и крупную аналитику оставить управляемыми. Так вы контролируете стабильные расходы и оставляете сложные края вендорам.

Если хотите практический разбор перед тем, как что-то переносить, Oleg Sotnikov на oleg.is помогает стартапам и небольшим командам как Fractional CTO. Короткий внешний взгляд часто спасает от преждевременного владения не тем, что нужно.