Сколько на самом деле стоит содержать унаследованный сервер

MAATRIX

В финансовой модели унаследованный сервер обычно занимает одну строчку: хостинг, условно тысяча-две рублей в месяц. Формально это правда — именно столько снимает с карты провайдер. Но реальная стоимость владения таким сервером не сводится к счёту за аренду железа, и разница между этими двумя цифрами может быть на порядок. Ниже — не абстрактный тезис «скрытые расходы существуют», а рабочая формула, по которой можно посчитать полную стоимость владения (TCO) именно для унаследованного сервера — с примером расчёта и сравнением против переезда на чистую систему.

Почему счёт за хостинг — это только видимая часть

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

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

Полная формула выглядит так:

TCO(унаследованный сервер) =
    Прямые расходы (хостинг, лицензии, домены)
  + Время на разбор (аудит + "налог на контекст" на каждую задачу)
  + Ожидаемая стоимость простоя из-за непрозрачности
  + Премия за аварийный режим вместо планового обслуживания

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

Время на разбор: стоимость первого прикосновения к системе

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

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

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

Практически это выглядит как отдельная метка в трекере задач: не просто «поправил конфиг nginx», а «поправил конфиг nginx (25 минут) + разобрался, какой из трёх инстансов активен (40 минут)». Через месяц-два таких меток накапливается достаточно, чтобы увидеть реальное соотношение — и оно почти всегда хуже, чем казалось на старте.

Риск простоя из-за непрозрачности: как посчитать ожидаемую стоимость

Второе слагаемое — не расход, который вы точно понесёте, а ожидаемая стоимость риска, как страховая премия. Логика та же: у любого сервера случаются инциденты, но на непрозрачной системе время восстановления (MTTR) систематически выше, потому что первым шагом инженеру приходится не чинить, а выяснять, что вообще сломалось и на что это влияет.

Формула ожидаемых потерь от простоя:

Ожидаемая стоимость простоя =
    (вероятность серьёзного инцидента в год)
  × (дополнительные часы простоя из-за непрозрачности, сверх «нормального» MTTR)
  × (стоимость часа простоя для бизнеса)

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

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

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

Премия за аварийный режим вместо планового обслуживания

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

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

• Время дороже. Правка в панике посреди инцидента стоит инженеру больше часов, чем та же правка в плановом окне — приходится одновременно чинить и разбираться, что чинить.
• Риск ошибки выше. Спешка и отсутствие возможности протестировать изменение повышают шанс, что исправление одной проблемы создаст вторую.
• Долг не уменьшается, а растёт. Аварийная правка почти никогда не документируется — не до того. Каждый такой инцидент оставляет систему ещё менее прозрачной для следующего раза, а значит следующий MTTR будет ещё выше. Это самоусиливающийся цикл: непрозрачность → невозможность планового обслуживания → аварийный режим → ещё больше непрозрачности.

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

Собираем формулу: пример расчёта TCO за год

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

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

Отдельно стоит учесть ещё один пункт, который не всегда влезает в денежную формулу напрямую, но обязателен для полной картины — риск bus factor, равного единице: если знание о системе есть только у одного человека, стоимость его ухода нужно закладывать как отдельный, потенциально катастрофический сценарий, а не игнорировать её, потому что «пока никто не уволился».

Что дешевле: тащить сервер дальше или переехать на чистую систему

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

Это сравнение — не универсальный ответ «переезжать всегда дешевле» или «разбирать всегда дешевле». Оно сильно зависит от конкретной системы: TCO унаследованного сервера со временем снижается, потому что каждый час разбора превращается в постоянное знание, а не тратится заново — если, конечно, разбор действительно продвигается, а не буксует на месте. У переезда своя цена и свой риск: перенос неизвестных зависимостей может сломать то, о существовании чего вы не подозревали, а сам переезд — это тоже часы работы, просто сконцентрированные в одном спринте, а не растянутые на месяцы.

Подробный разбор признаков, по которым можно понять, что перед вами не просто недокументированная, а физически прогнившая система, где переезд объективно выгоднее многомесячного разбора, — в статье про выбор между разбором и переездом на чистый сервер. Формула TCO из этой статьи — вход для того сравнения: без неё решение «переезжать или нет» принимается на ощущениях, а не на цифрах.

Как снизить TCO, не переезжая

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

• Фиксируйте находки сразу, а не держите в голове. Каждый час разбора, потраченный без записи результата, придётся тратить заново следующему человеку — а иногда и вам самому через полгода. Достаточно одного файла с минимумом: какие сервисы критичны, где бэкапы, кто имеет доступ.
• Переводите сервисы из «аварийного» списка в «плановый» по мере разбора. Как только сервис исследован и понятен, его обслуживание должно уйти с ночного дежурства на обычное расписание — иначе выигрыш от разбора не конвертируется в снижение TCO.
• Ставьте мониторинг раньше, чем заканчиваете полный аудит. Даже базовый мониторинг доступности и ресурсов сокращает MTTR ещё до того, как система полностью понятна — вы хотя бы быстрее узнаёте, что что-то сломалось, вместо того чтобы находить это по жалобам пользователей.
• Считайте часы, а не гадайте. Трекинг задач по категориям — единственный способ увидеть, снижается ли реально «налог на контекст» от месяца к месяцу, или разбор буксует и стоит пересмотреть стратегию в пользу переезда.

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

Частые вопросы