Стоимость самостоятельного хостинга после окончания бесплатного тарифа: что учитывать

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

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

Именно тогда обычно и всплывает настоящая стоимость самостоятельного хостинга. Раньше всю работу делал вендор. Теперь это делает ваша команда.

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

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

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

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

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

Команды, которые принимают удачные решения о self-hosting, начинают с одного простого вопроса: какую проблему мы пытаемся решить и сколько работы каждый месяц будет стоить этот перенос после завершения настройки?

Куда на самом деле уходят деньги

Большинство команд сравнивают счет от вендора со счетом за сервер и на этом останавливаются. Это не учитывает половину расходов и делает self-hosting дешевле, чем он окажется к третьему месяцу.

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

Затем посчитайте новую среду для этой нагрузки. Обычно это compute, хранилище, резервные копии, трафик, load balancer'ы, snapshots и немного запасной мощности, чтобы один перегруженный день не положил сервис. Не забудьте про рост. База данных, которая сейчас помещается на небольшом диске, позже может потребовать гораздо больше места, когда накопятся логи, вложения и правила хранения.

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

Последние пункты заслуживают отдельной строки, а не сноски. Если вы самостоятельно хостите сервис, вам все равно нужны проверки доступности, логи, отслеживание ошибок, метрики, алерты, управление секретами, сканирование уязвимостей, а иногда и WAF или защита от DDoS. Часть этого можно собрать на open-source инструментах, но на них все равно уйдут время и железо.

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

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

Учтите работу, которую никто не закладывает в бюджет

Счет за лицензию легко увидеть. Счет за трудозатраты — вот где self-hosting чаще всего идет не так.

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

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

После запуска работа продолжается маленькими порциями. Патч нужно протестировать. Минорное обновление меняет настройку. Истекает сертификат. Деплой проходит в staging и падает в production. По отдельности это не звучит драматично, но легко может съедать от 6 до 15 часов в месяц.

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

Соберите простое ежемесячное сравнение

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

Сделайте в таблице два простых столбца. Один — «остаться на hosted». Другой — «перейти на self-host». Держите все скучно и прямо. Сложные финансовые модели обычно не делают расходы понятнее, а наоборот прячут их.

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

Для self-host считайте деньги и время в одной таблице. Добавьте серверы, хранилище, трафик, место для бэкапов, мониторинг, логирование, трудозатраты на обновления, время on-call, реакцию на инциденты и восстановительные тесты.

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

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

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

Добавьте в сумму риск ночных алертов

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

Начните с простого вопроса: у кого ночью телефон? Если ответ — «у основателя», «у lead engineer» или «у того, кто первым заметит Slack», у вас уже есть реальная стоимость. Этот человек теряет сон, на следующий день хуже фокусируется и часто теряет несколько часов запланированной работы.

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

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

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

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

Эту часть стоимости self-hosting легко спрятать, потому что она попадает в календари и в усталость, а не в счет от вендора. Но считать ее все равно нужно. Если экономия составляет всего несколько сотен долларов в месяц, даже одна плохая ночь может ее полностью съесть.

Проверьте бэкапы до того, как начнете им доверять

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

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

Что нужно сохранять

Резервируйте те части, которые нельзя быстро восстановить заново: production-базу данных, пользовательские загрузки и сгенерированные файлы, конфигурацию приложения и переменные окружения, billing- или audit-записи, а также скрипты и заметки, необходимые для поднятия приложения.

Команды постоянно забывают об этом. Они бэкапят Postgres, а слишком поздно узнают, что счета хранились в object storage, а API-ключи — на одном старом сервере.

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

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

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

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

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

Если этих имен нет, план резервного копирования — это надежда, а не защита.

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

Команда из 12 человек ведет один B2B-продукт. Они использовали hosted-инструмент для исходного кода, CI, отслеживания ошибок и внутренних документов, пока использование укладывалось в щедрый бесплатный тариф. Потом клиентская база выросла, логов стало больше, количество build minutes увеличилось, и ежемесячный счет вырос примерно с $900 до $2,600.

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

Их планируемые ежемесячные расходы выглядели так: $540 за три облачных сервера, $140 за хранилище бэкапов и snapshots, $170 за мониторинг, почту и дополнительный трафик, примерно $600 за шесть часов регулярной админской работы и $240 за ежемесячный восстановительный тест с участием инженера и QA. В сумме это давало около $1,690.

На фоне счета SaaS в $2,600 экономия выглядит реальной.

Но потом начинается обычная жизнь. В первом квартале после переезда у команды случилось два инцидента на выходных. В одну субботу диск заполнился во время всплеска логов и остановил деплои на четыре часа. Через три недели неудачное обновление пакета сломало CI runner и заблокировало релизы до воскресного вечера.

На эти два инцидента ушло около 14 часов инженерного времени, плюс еще несколько часов у поддержки и QA в понедельник, чтобы проверить отложенные задания и сообщения клиентов. При ставке $100 в час квартал получил примерно $1,700 дополнительных трудозатрат, или около $567 в месяц, если распределить это по времени.

Теперь ежемесячная картина меняется. Запланированные $1,690 превращаются примерно в $2,257. Команда все еще платит меньше, чем $2,600, но разница уже небольшая, и еще один плохой месяц ее сотрет.

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

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

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

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

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

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

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

Еще одно плохое сравнение — только лицензия против только хостинга. Оно не учитывает трудозатраты, стресс on-call, удаленное место для бэкапов, патчи безопасности и часы, потраченные на присмотр за системой, которая раньше была управляемой. Для небольшой SaaS-команды экономия $800 в месяц на лицензиях может казаться умной, пока обновления не съедят 10 часов инженера и один инцидент на выходных не уничтожит всю выгоду.

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

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

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

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

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

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

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

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

Одно грубое правило работает хорошо: если перенос экономит $500 в месяц на лицензиях, но добавляет даже 8–10 часов квалифицированного труда, вы, возможно, просто перенесли счет в другое место. Если вы не можете четко ответить на эти проверки, подождите неделю и сначала соберите недостающие цифры.

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

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

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

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

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

Держите вариант отката дольше, чем вам комфортно. Если self-hosted-версия начинает съедать время команды, быстро вернитесь назад и воспринимайте это как полезные данные, а не как провал. Обратимое решение безопаснее, чем смелое.

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