Что хостить самостоятельно, когда команда сокращается, а расходы растут

Почему это становится сложнее, когда команда меньше

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

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

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

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

Маленькая команда может поддерживать серьёзные системы, если выбирает внимательно. Oleg Sotnikov показал, что глобальная production-платформа может оставаться компактной при правильной архитектуре и низких облачных расходах. Сложность не в том, чтобы хостить софт самостоятельно. Сложность в том, чтобы выбрать те немногие системы, которые снижают расходы и риски, не превращаясь во вторую работу по эксплуатации.

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

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

Что делает инструмент достойным самостоятельного хостинга

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

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

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

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

Поэтому внутренние системы часто логичнее, чем клиентские. Внутренняя wiki, отслеживание ошибок, сборщики для сборок или внутренние дашборды могут быть хорошими кандидатами. Команды часто успешно используют self-hosted GitLab, Sentry, Grafana и похожие инструменты, если уже умеют делать бэкапы и базовый мониторинг. Oleg Sotnikov использовал такую схему в production с компактными командами. Это полезная модель: держать у себя стабильные части, которые окупают усилия месяц за месяцем.

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

Системы, с которых часто стоит начать

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

Репозитории кода и сборочные раннеры часто оказываются в самом верху списка у продуктовых команд. Это часть ежедневной работы, расходы быстро растут, а процесс обычно понятен. Самостоятельно хостимый репозиторий с локальными или облачными раннерами может сократить плату за пользователей и минуты сборки, не меняя привычный стиль работы разработчиков. Это одна из схем, которую Oleg Sotnikov использует на практике с self-hosted GitLab и CI/CD раннерами. Она работает, потому что команда контролирует доступ, логи и шаги деплоя в одном месте.

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

Отслеживание ошибок и базовый мониторинг тоже хорошо подходят для первых шагов. Эти инструменты помогают держать остальной стек в порядке и обычно стареют спокойно. Простая схема с Sentry для ошибок и Grafana с Prometheus или Loki для метрик и логов даёт небольшой команде достаточно прозрачности без пачки отдельных SaaS-счетов. Oleg использует такой стек на серьёзном масштабе, но небольшой продуктовой команде можно начать гораздо скромнее и всё равно получать понятные уведомления.

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

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

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

Что пока лучше оставить у провайдера

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

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

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

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

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

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

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

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

Как принять решение за один день

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

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

Быстрый способ оценить

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

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

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

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

Существующие навыки меняют расчёт. Если команда уже знает такие инструменты, как GitLab, Sentry, Grafana или простую Docker-схему, усилий на настройку будет меньше. Знакомые инструменты создают меньше сюрпризов, а меньше сюрпризов — это меньше работы по вечерам и в выходные.

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

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

У продуктовой команды из четырёх человек после сокращения финансирования остаются только два инженера. Команда всё ещё выпускает продукт, но каждый ежемесячный счёт начинает болеть. Они не пытаются хостить у себя вообще всё. Это быстро съело бы их выходные.

Три системы они оставляют hosted: email, биллинг и поддержку клиентов. Email сложно хорошо обслуживать, биллинг требует доверия и соответствия требованиям, а инструменты поддержки особенно важны, когда клиенты недовольны. Экономить там немного денег обычно не стоит риска.

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

Такая схема может оставаться довольно компактной. Один сервер для репозитория, один CI-раннер и один стек мониторинга часто закрывают потребности компактной команды. Oleg Sotnikov использовал такой подход в production, сочетая self-hosted инструменты разработки и наблюдаемости с жёстким контролем расходов вместо распыления работы по множеству платных сервисов.

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

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

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

Ошибки, которые превращают всё в работу по выходным

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

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

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

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

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

Многое предотвращают несколько привычек. Читайте release notes перед обновлением. Записывайте шаги отката. Тестируйте восстановление на запасном экземпляре. Держите последние изменения конфигурации в version control. Планируйте обновления на то время, когда владелец инструмента бодрствует и доступен.

С алертами бывает не лучше. Команды настраивают уведомления о диске, CPU, SSL и бэкапах, но никто за ними не следит. В итоге получается либо постоянный шум, либо тихий отказ. Уведомление без имени ответственного рядом — это просто фоновый стресс.

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

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

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

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

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

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

Короткий простой тоже должен быть скучным. Спросите прямо: сможет ли команда работать час, если этот инструмент исчезнет? Wiki или трекер ошибок обычно могут подождать. Auth, платёжные системы и основная production-база — обычно нет. Начинайте с инструментов, которые ломаются мягко, прежде чем трогать те, что останавливают продажи или поддержку.

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

Потом честно посчитайте. Включите время на настройку, обновления, хранилище, мониторинг и стоимость человека, который будет за ним следить. Инструмент, который экономит 200 долларов в месяц, но съедает четыре часа времени дорогого специалиста, деньги не экономит.

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

Следующие шаги для более лёгкого стека

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

Выберите одну систему с понятным владельцем. Хорошие первые кандидаты — инструменты, которыми команда пользуется каждый день, которые она хорошо понимает и без которых может прожить короткое окно обслуживания. Общий password vault или схема с source control runner'ом могут быть проще в поддержке, чем клиентское приложение.

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

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

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

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

Сложным стеком часто лучше заниматься с ещё одной парой глаз. Особенно если у команды старые серверы, дублирующиеся SaaS-инструменты или незавершённые миграции. Если вам нужна такая проверка, Oleg Sotnikov at oleg.is работает со стартапами и небольшим бизнесом как fractional CTO: помогает с компактной инфраструктурой, AI first development и практическими решениями о том, что хостить самостоятельно, а что оставить у провайдера.

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