Стоимость самостоятельного хостинга: что заложить в бюджет до сравнения

Почему счёт за сервер вводит в заблуждение

Сервер за $40 и SaaS-план за $400 покупают не одно и то же. В счёт за сервер входят вычисления, хранилище и трафик. В цену SaaS часто уже заложены люди и процессы, которые каждый день поддерживают сервис в рабочем состоянии.

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

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

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

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

• регулярный мониторинг
• проверка бэкапов и тестирование восстановления
• патчи безопасности
• планирование обновлений и откат
• реагирование по дежурству

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

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

Что на самом деле включает операционная дисциплина

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

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

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

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

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

Хорошая схема не обязана быть навороченной. Ей нужно быстро отвечать на несколько простых вопросов:

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

Runbooks замыкают цикл. Это короткие заметки для типовых проблем: переполнен диск, не продлился SSL, восстановление базы, откат после неудачного релиза. Oleg Sotnikov часто выстраивает для клиентов такой операционный стек с мониторингом, отслеживанием ошибок и простым CI/CD, потому что одни инструменты не снижают стоимость самостоятельного хостинга. Снижают её понятные и повторяемые процессы.

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

Какие расходы люди забывают включить

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

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

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

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

Инструменты вокруг сервера

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

Часто дополнительно нужны:

• хранилище для бэкапов и снапшотов
• staging-среда для обновлений
• инструменты мониторинга и оповещений
• отслеживание ошибок и хранение логов
• человек на дежурстве, когда выкладки идут не так

По отдельности всё это не выглядит драматично. Вместе — меняет картину.

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

Именно поэтому опытные операторы сравнивают self-hosting и SaaS иначе, чем те, кто делает это впервые. Они спрашивают не только: «Сколько стоит сервер?» Они спрашивают, кто ставит патчи, кто проверяет алерты, кто тестирует восстановление и кто отвечает на звонок, когда что-то ломается.

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

Как оценить реальную ежемесячную стоимость

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

Сначала выпишите повторяющиеся задачи. Простого списка достаточно:

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

Теперь оцените часы на обычный месяц, а не на месяц катастрофы. Если проверка бэкапов занимает 1 час, патчи — 2, обновления — 3, а мелкие исправления — 4, это уже 10 часов до того, как что-то пойдёт не так.

Затем назначьте этим часам реальную цену. Не ставьте «$0» только потому, что основатель делает это по ночам. Время основателя всё равно стоит денег. Если инженера пришлось бы нанять за $70 в час, а основатель выполняет инженерную работу, используйте тот же порядок цены. Хорошее правило — брать стоимость замещения, а не желаемую цифру.

Эта простая формула работает хорошо:

Real monthly cost = server and tools + (ops hours x hourly rate) + incident reserve

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

Например, допустим, ваш стек стоит $180 в месяц за хостинг и платные инструменты. Основатель тратит 6 часов, инженер — 8, и оба стоят $75 в час по стоимости замещения. Это $1,050 труда. Добавьте умеренный резерв на инциденты — 3 часа в месяц, то есть $225. Итого реальная месячная стоимость — около $1,455, а не $180.

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

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

Простой пример с реальными компромиссами

Команда из пяти человек платит $450 в месяц за hosted internal tool. Они переносят его на один облачный сервер за $90 и чувствуют, что сэкономили $360. На бумаге математика выглядит простой. На практике расходы самостоятельного хостинга появляются там, где в первом счёте их не видно.

Сервер — это только базовый слой. Команде всё ещё нужны хранилище для бэкапов, мониторинг и способ отправлять оповещения после рабочего времени. Это добавляет ещё $60–$120 в месяц, в зависимости от срока хранения и того, как всё настроено. Если нужны не просто файлы «где-то», а проверенные бэкапы, кому-то ещё нужно проверять, что восстановление работает.

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

Простой ежемесячный расчёт может выглядеть так:

• Облачный сервер: $90
• Хранилище для бэкапов: $25
• Мониторинг и оповещения: $35
• Время инженера на поддержку: $200–$400
• Стоимость дежурств: трудно оценить, пока что-то не сломается

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

Вот где сравнение self-hosting vs SaaS становится реальным. Если команда уже поддерживает бэкапы, патчи, обновления и дежурства для других систем, дополнительная нагрузка может остаться небольшой. Если нет, «дешёвый» сервер часто оказывается дороже, чем казалось в первый день.

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

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

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

Это также лучше работает, когда команда уже хорошо управляет похожими системами. Если ваши инженеры уже работают с Linux, контейнерами, мониторингом, бэкапами и реагированием на инциденты, вы не учитесь операционке с нуля параллельно миграции. Команда, которая уже поддерживает CI/CD, observability и продакшен, может гораздо честнее оценить компромисс.

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

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

А значит, нужно принять нагрузку на поддержку до переезда:

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

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

Лучшие self-hosted-системы — скучные. Команда знает, кто за них отвечает, нагрузка предсказуема, и никто не делает вид, что поддержка бесплатна.

Типичные ошибки, которые съедают экономию

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

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

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

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

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

Многие сравнения self-hosting vs SaaS ломаются ещё и потому, что команды переносят слишком много одновременно. Они мигрируют приложение, базы данных, мониторинг, CI, почту и внутренние инструменты одним рывком. Это создаёт кучу неизвестных. Когда что-то идёт не так, никто не понимает, с чего начинать.

Безопасный подход скучный, и это обычно хороший знак:

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

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

Быстрые проверки перед решением

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

Перед решением задайте себе такие вопросы:

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

На каждый ответ нужна цифра, а не догадка. «Мы быстро восстановимся» — этого мало. Восстановление может занять 20 минут для небольшого приложения с чистыми бэкапами, а может занять шесть часов, если нужно пересобирать инфраструктуру, восстанавливать секреты, проигрывать файлы и проверять данные.

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

Вспомогательные инструменты часто меняют математику. Дешёвые серверы выглядят отлично, пока вы не добавите хранилище для бэкапов, дополнительное хранение снапшотов, мониторинг, хранение логов, paging по инцидентам и план поддержки для базы данных или хостинга. Всё это тоже часть self-hosting vs SaaS, даже если счета приходят отдельно.

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

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

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

Оформите решение в простой таблице на 6–12 месяцев, а не в одном месячном счёте за сервер. Добавьте хостинг, хранилище, бэкапы, время на патчи, работу с обновлениями, мониторинг и часы, которые кто-то потратит, когда алерты сработают в выходные.

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

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

Перед тем как что-то переносить, запишите, кто отвечает за работу:

• бэкапы и тесты восстановления
• обновления версий и патчи безопасности
• алерты, логи и регулярные проверки
• реагирование по дежурству, когда что-то ломается

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

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

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

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