Когда переносить инфраструктуру внутрь компании без спешки

Почему это решение часто становится сложным

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

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

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

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

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

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

Признаки того, что управляемая схема больше не подходит

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

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

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

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

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

Когда вместе появляются ровный трафик, повторяющиеся списания, компромиссы в продукте и медленная поддержка, вопрос уже не теоретический. Пора смотреть на альтернативы.

Как обычно выглядит стабильная нагрузка

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

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

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

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

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

У стабильной схемы обычно есть несколько простых признаков:

• Трафик остается в умеренном диапазоне.
• Рост данных идет по понятному месячному графику.
• Фоновые задачи запускаются по расписанию, которое вы контролируете.
• Время ответа остается довольно стабильным.
• Пиковые периоды известны заранее.

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

Что команда уже умеет

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

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

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

Быстрая проверка реальности помогает:

• Хотя бы один человек может запустить тест восстановления и объяснить каждый шаг.
• Один или два человека понимают основы правил firewall, приватных сетей и контроля доступа.
• Кто-то отвечает за шум в алертах и знает, какие уведомления действительно важны.
• Схема живет в документации, скриптах и runbook'ах, а не только в голове одного инженера.

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

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

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

Как сравнить стоимость и усилия

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

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

Разовый перенос включает планирование, настройку, миграцию, тестирование и очистку хвостов. Туда же входят и вещи, о которых часто забывают: переписывание алертов, перенос бэкапов, обновление runbook'ов и проверка правил доступа.

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

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

Картина становится яснее на простых числах. Управляемая схема может стоить 6000 долларов в месяц. Самостоятельная поддержка может снизить эту сумму до 3500 долларов, но сам перенос займет 120 часов инженеров и ops, плюс дополнительное время на проверку бэкапов, мониторинг и тренировку реагирования на инциденты. Если эти часы стоят 10 000–15 000 долларов, срок окупаемости уже не выглядит мгновенным. Переезд все равно может быть оправдан, но только если нагрузка достаточно стабильна, чтобы вернуть эти затраты.

Знания команды быстро меняют расчеты. Если ваши инженеры уже умеют работать с Docker, Linux, CI-пайплайнами и инструментами вроде Grafana или Sentry, усилий будет меньше. Если никто раньше не обслуживал production-системы, управляемый вариант может остаться дешевле даже при большем счете.

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

Простой способ проверить идею

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

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

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

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

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

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

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

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

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

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

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

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

Следующие шесть недель команда отслеживает четыре вещи:

• сколько стоит запуск воркера
• как часто падают задания
• сколько времени уходит на обслуживание
• появляются ли ночные алерты

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

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

Ошибки, которые добавляют лишнюю работу

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

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

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

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

Небольшая команда должна уметь ответить на несколько простых вопросов. Сколько времени занимает восстановление? Кто его запускает? Что вы потеряете, если последняя snapshot окажется плохой? Если никто не знает ответ, перенос еще не готов.

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

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

Гораздо безопаснее выглядит такой, менее эффектный подход:

• Сначала переносите один стабильный сервис.
• Пишите runbook до переключения.
• Проверяйте восстановление, откат и алерты.
• Убедитесь, что обслуживать его могут хотя бы два человека.
• Сравнивайте часы инженеров с убранным счетом.

Инфраструктура — это не покупка в магазине. Это операционное решение. Цена важна, но ежедневная нагрузка на поддержку важна не меньше.

Короткая проверка перед решением

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

Перед тем как принимать решение, прогоните план через несколько простых проверок. Если вы не можете ответить на них на одной короткой странице, значит, перенос, скорее всего, еще слишком рано.

• Выберите первый сервис для переноса и оставьте его небольшим. Фоновый воркер, внутренний API или staging-база безопаснее, чем основная production-база.
• Назовите человека, который будет разбирать ночные алерты. Если у pager'а нет владельца, значит, у сервиса его тоже еще нет.
• Проверьте путь отката, который можно выполнить быстро. Если новая схема не сработает, команда должна уметь вернуться назад за минуты.
• Запишите ежемесячную боль, которую вы хотите убрать. Возможно, счет растет каждый месяц, поддержка работает медленно или управляемая схема мешает нужному изменению.
• Напротив каждой задачи поставьте одного владельца: настройка, мониторинг, бэкапы, обновления безопасности и реагирование на инциденты.

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

Знания тоже важны. Если команда уже каждую неделю работает с Docker, Linux, мониторингом и бэкапами, перенос одной стабильной нагрузки внутрь компании — вполне разумный тест. Если же никто этим не занимался, экономия может быстро исчезнуть.

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

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

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

Сначала переносите стабильные нагрузки. Лучшие первые кандидаты — скучные, предсказуемые и легко измеряемые. Фоновые задачи, внутренние инструменты, хранение логов или простой API обычно подходят лучше, чем авторизация клиентов, биллинг или основная production-база.

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

Небольшая таблица оценки помогает:

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

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

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