Самохостинг vs управляемые сервисы для небольших компаний

Почему это решение быстро становится запутанным

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

Но счёт — это только часть затрат. Как только вы запускаете что-то у себя, вы берёте на себя и скучную работу: обновления, бэкапы, контроль доступа, алерты, тесты восстановления и вопрос в 2 часа ночи: кто это чинит прямо сейчас.

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

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

Для небольшой компании такая сделка часто оправдана.

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

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

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

Что обычно подходит для self-hosting

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

Source control и CI часто подходят под это описание. Если команда уже знает Linux, спокойно работает с Docker и умеет читать логи, когда падает runner, то хранить git-репозитории и build jobs у себя может быть разумно.

Внутренние инструменты тоже обычно хорошо чувствуют себя на self-hosted инфраструктуре. Корпоративная wiki, внутренний dashboard, доска вакансий для команды или admin panel с ограниченным публичным доступом обычно имеют простые паттерны трафика. Если один сервер лежит 20 минут, бизнес раздражён, но не остановлен.

Логи и метрики — ещё один хороший вариант. Счета за SaaS observability быстро растут, когда объём данных увеличивается. Если ваш продукт создаёт много событий, self-hosted стек вроде Grafana, Prometheus, Loki или Sentry может сильно сократить регулярные расходы. Но это работает только если кто-то следит за ростом диска, настройками хранения и шумом алертов, прежде чем всё превратится в хаос.

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

Признаки, что это хороший вариант

Нагрузка обычно подходит для self-hosting, если большая часть этого верна:

• Трафик остаётся довольно стабильным.
• Шаги восстановления записаны и протестированы.
• Один человек отвечает за патчи, бэкапы и правила доступа.
• Команда может разбирать проблемы с Linux и сетью без паники.
• Короткий простой бьёт по продуктивности сильнее, чем по выручке.

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

Что обычно лучше оставить в managed services

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

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

Системы, связанные с деньгами, тоже в большинстве случаев лучше держать вне собственных серверов. Платежи, расчёт налогов, правила выставления счетов, проверки на fraud и обработка chargeback часто меняются, а ошибки стоят реальных денег. Если клиенту спишут деньги дважды или налог окажется неправильным в одном штате или стране, исправить проблему доверия сложнее, чем исправить код.

Публичный login — ещё одна частая ловушка. Если у команды нет серьёзной экспертизы по безопасности, используйте провайдера для authentication. Сброс пароля, MFA, работа с сессиями, защита от ботов, проверки подозрительных входов и восстановление доступа звучат рутинно, пока кто-то не начнёт всё это ломать.

То же самое относится к интернет-пограничным сервисам: DNS, CDN caching, DDoS и bot filtering, массовой работе с TLS certificates и WAF rules. Эти системы стоят перед всем остальным. Если они ломаются, пользователи даже не доходят до вашего продукта.

Инструменты с жёсткими требованиями по compliance тоже обычно лучше оставить в managed services. Если системе нужны круглосуточные audit logs, правила хранения, контроль доступа, юридические обновления или формальные сертификаты, небольшой компании чаще дешевле арендовать эту работу, чем строить её самой.

Команда SaaS из 15 человек может самохостить GitLab, внутренние dashboards и часть background workers, но при этом оставить email, auth, payments и edge protection у вендоров. Такой вариант часто и перестаёт быть спором, и начинает выглядеть операционно разумно.

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

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

Рассматривайте каждый сервис отдельно. Ваша база данных, CI runners, внутренняя документация, мониторинг и клиентский login несут разный риск, поэтому и место у них должно быть разным.

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

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

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

Последний пункт важнее, чем многие думают. Дешёвый сервер вовсе не дешёвый, если один инженер каждую неделю теряет полдня, присматривая за ним.

Потом выберите один малорисковый внутренний инструмент и переносите только его. Хорошими первыми кандидатами часто бывают CI runners, внутренняя wiki, private package registry или хранилище логов с коротким сроком хранения. Если он сломается, команда просто недовольна. Если сломается production database, уйдут клиенты.

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

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

Дайте новой схеме месяц. Потом оцените uptime, количество обращений, стресс команды и реальный счёт. Оставляйте сервис у себя, если это экономит деньги и остаётся скучным. Возвращайте его на managed service, если команде приходится его постоянно нянчить.

Простой пример для SaaS-команды из 15 человек

Представьте SaaS-компанию из 15 человек, где есть один инженер, которому действительно нравится ops-работа. Это меняет почти всё. Если никто не хочет отвечать за серверы, самохостинг превращается в груду недоделанных задач.

Эта команда делает первый шаг осторожно. Source control и CI работают у них внутри на небольшом GitLab с парой runners. Это помогает держать расходы на сборки предсказуемыми, особенно если команда часто запускает тесты, preview builds и container jobs. Хороший аудит инфраструктуры часто приводит к тому же разделению: держать build stack ближе к коду, а рискованные пограничные системы — на управляемых сервисах.

Они не пытаются перенести всё внутрь.

Billing остаётся у managed provider. Email остаётся у провайдера, который берёт на себя доставку, правила bounce и репутацию отправителя. Auth тоже остаётся управляемым, потому что сброс пароля, MFA, безопасность сессий и обработка злоупотреблений могут съесть удивительно много времени. На этом месте небольшие команды часто и обжигаются. Они экономят немного на инструменте, а потом теряют это в стрессе и поддержке.

В повседневной работе ответственность понятна. Инженер, которому ближе ops, отвечает за обновления GitLab, состояние runners, бэкапы и проверку восстановления. Каждый разработчик отвечает за сломанные pipelines и медленные jobs в своей части кода. Основатель или финансовый руководитель отвечает за настройки billing, правила налогов и проблемы со счетами внутри billing tool. Один продуктовый инженер отвечает за то, как login и signup ощущаются в приложении, а провайдер auth — за сложную часть безопасности. Поддержка следит за проблемами email, но сам email provider отвечает за репутацию и доставляемость.

Observability на старте остаётся managed по простой причине: сначала это удобно, а небольшие команды часто быстро меняют стек. Hosted logs и traces экономят время, пока продукт ещё активно двигается. Если расходы на использование вырастут настолько, что начнут бить по бюджету каждый месяц, команда сможет перенести метрики и логи внутрь с помощью Grafana, Prometheus и Loki. До этого момента self-hosting observability обычно добавляет больше работы, чем экономит.

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

О каких расходах часто забывают

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

VM за $200 в месяц может превратиться в куда более дорогую историю, когда кому-то нужно следить за патчами, minor version upgrades, продлением SSL certificates, чисткой логов, ростом диска и этими сеансами «я только проверю» в субботу вечером. В первую неделю это не кажется дорогим. К шестому месяцу оно накапливается.

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

Резервная мощность — ещё одна статья, которую люди пропускают. Если вы самохостите базу данных, build runner или внутренний Git-сервис, вам нужен запас на обслуживание и сбои. Это может означать второй узел, дополнительный диск или машину, которая в основном простаивает, пока что-то не сломается. У managed services эта часть спрятана в цене. При self-hosting вы покупаете её сами.

Стоимость людей часто оказывается самой большой. Если один инженер знает, как связаны ваш Docker host, Postgres replica и monitoring stack, этот человек становится частью плана обеспечения uptime. Отпуск, больничный или новая работа могут превратить «дешёвую» схему в аврал.

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

Последний пункт больнее, чем ожидают команды. Если два разработчика три недели переносят CI, error tracking и внутренние инструменты внутрь, эти три недели они не выпускали клиентские фичи. Экономия может быть реальной, но сравнение должно быть честным.

Вот где опытный CTO или советник может сэкономить деньги, уменьшив масштаб задачи. Вместо переноса всего сразу небольшая компания может самохостить стабильные внутренние инструменты вроде GitLab, Grafana или Sentry, а доставку email, платежи и клиентские базы данных оставить на managed services. Такой микс часто дешевле любой крайности и намного спокойнее.

Ошибки, из-за которых self-hosting становится болезненным

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

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

Ещё одна частая ошибка — копировать стек большой компании, потому что он выглядит «профессионально». Команде из 12 человек не нужен тот же набор кластеров, очередей, service mesh и уровней безопасности, что и крупной компании. Чем больше движущихся частей, тем больше обновлений, алертов и странных сбоев в 2 часа ночи. Небольшим командам обычно лучше живётся с меньшим числом компонентов и скучными настройками по умолчанию.

Ограничения по железу тоже приносят много боли. Люди покупают один мощный сервер, радуются экономии, а потом сваливают на него базы данных, мониторинг, Git, background jobs и staging. Это работает, пока один шумный сервис не съедает диск или память, и всё остальное не начинает тормозить вместе с ним. Разделение не обязано быть сложным, но некоторые нагрузки не должны сидеть на одной машине.

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

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

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

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

Спросите себя об этом перед переносом любого сервиса:

• Кто отвечает за сервис, когда он работает нормально, и кто отвечает, когда он ломается?
• Можем ли мы на этой неделе восстановить данные на тестовой машине?
• Какой простой команда и клиенты действительно могут терпеть?
• Во сколько это обходится каждый месяц — деньгами и временем сотрудников?
• Если мы пожалеем о переносе, как быстро мы вернёмся назад с коротким простоем?

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

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

Будьте честны насчёт простоя. Некоторые внутренние инструменты могут быть недоступны несколько часов, и почти никто не расстроится. Клиентский login, billing и production database обычно требуют куда более жёстких рамок. Если команда не может принять больше 30 минут простоя, ваша схема, мониторинг и план восстановления должны соответствовать этому пределу.

Теперь запишите реальную ежемесячную стоимость. Включите счёт за сервер, storage, бэкапы, мониторинг, security updates и часы сотрудников на патчи и устранение проблем. Два часа в неделю от senior engineer — это реальные затраты, даже если они никогда не появляются в cloud invoice.

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

Если вы работаете с fractional CTO, именно такой чек-лист они должны попросить вас закончить до того, как согласиться на самохостинг чего-то серьёзного.

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

Перестаньте считать это одним большим решением в стиле «да или нет». Соберите текущий стек на одной странице и сделайте его достаточно понятным, чтобы любой в команде мог прочитать это за пять минут.

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

Затем запустите небольшой пилот. Выберите один скучный внутренний сервис и самохостите только его. Хорошие кандидаты — внутренняя документация, private CI runner или инструмент мониторинга только для команды. Для первого раунда избегайте всего, что видно клиентам. Такой тест рассказывает больше, чем месяц обсуждений.

Рискованные части оставляйте на managed services, пока у команды не появится лучшего покрытия. Если система отвечает за клиентские логины, платежи, доставку email или основную production database, оставьте её там, где кто-то другой уже ночью в 2 часа занимается неприятными деталями.

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

Если компромиссы всё ещё кажутся размытыми, попросите короткий внешний обзор до того, как переносить ещё больше сервисов. Человек, который работал и с startup product teams, и с production infrastructure, обычно быстро замечает скрытые расходы.

Oleg Sotnikov делает такую fractional CTO работу на oleg.is. У него необычно широкий опыт — от software engineering до CTO и founder work, — поэтому короткий разбор может помочь небольшой команде понять, что безопасно перенести внутрь, а что лучше оставить на managed services.

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