TCO выделенного сервера: все статьи, которых нет в счёте за аренду

MAATRIX

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

Почему счёт за аренду — это не TCO

TCO (Total Cost of Ownership, полная стоимость владения) — это сумма всех расходов на инфраструктуру за период её жизни, а не только арендной платы. Провайдер выставляет счёт за то, что он контролирует: процессор, память, диски, канал, электричество, охлаждение. Всё, что происходит выше этого уровня — операционная система, приложения, данные, процессы эксплуатации — остаётся на стороне арендатора, и именно там прячутся дополнительные расходы.

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

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

Время администрирования: невидимая, но самая большая статья

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

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

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

Если этим занимается штатный DevOps- или системный администратор, посчитайте его часовую ставку и реалистичную долю рабочего времени, которую он тратит именно на эксплуатацию (не на разработку фич). Для небольшой инфраструктуры это обычно не полная ставка, а несколько часов в неделю — но за год они складываются в заметную сумму, сопоставимую с разницей между голой арендой и managed-тарифом.

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

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

Резервное копирование: инфраструктура, а не галочка

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

Составляющие реальной стоимости бэкапов:

• хранилище — копии должны лежать не на том же диске и желательно не у того же провайдера, иначе бэкап не защищает от отказа сервера или аккаунта; внешнее хранилище (S3-совместимое, отдельный сервер) — это отдельная статья расходов, растущая вместе с объёмом данных;
• инструмент — even open-source решения вроде BorgBackup, restic или Percona XtraBackup требуют настройки, тестирования расписания и мониторинга — то есть снова времени администратора;
• проверка восстановления — бэкап, который никогда не разворачивали в тестовой среде, с равной вероятностью либо сработает, либо окажется битым архивом; регулярные тестовые восстановления — это регламентная работа, которую редко кто закладывает в план, а зря;
• хранение истории версий — если политика требует хранить копии за несколько недель или месяцев (для отката к состоянию до заражения или ошибки в данных), объём хранилища растёт нелинейно, и его тоже нужно закладывать заранее.

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

DDoS-защита: базовая vs расширенная, и цена простоя без неё

Часть дата-центров включает базовую защиту от объёмных L3/L4-атак в стоимость канала — это фильтрация мусорного трафика на границе сети, которая работает без вашего участия. Но базовая защита почти всегда не покрывает прикладные атаки на уровне L7 (флуд HTTP-запросами, атаки на конкретные эндпоинты API), и именно они чаще всего кладут реальные сервисы.

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

Что стоит заложить в TCO по этой статье:

• стоимость расширенной защиты, если ваш профиль риска (публичный API, e-commerce, заметный бренд) её оправдывает;
• время на настройку правил фильтрации и rate limiting на уровне приложения — это работа, которую защита канала не заменяет;
• сценарий на случай атаки без подключённой защиты: кто принимает решение, сколько времени займёт экстренное подключение, во сколько обойдётся простой за это время.

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

Обучение персонала: разовая инвестиция, которая повторяется

Самостоятельная эксплуатация выделенного сервера требует компетенций, которых у команды может не быть в полном объёме — особенно если раньше работали только с managed-облаком или PaaS, где часть слоя инфраструктуры была скрыта от разработчиков. Переход на голое железо означает, что кто-то должен разбираться в сетевой настройке, работе с RAID, тюнинге ядра, конфигурации фаервола на уровне iptables/nftables, а не только в деплое приложения.

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

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

Если считать TCO честно, стоит заложить не только стоимость курсов или времени на самостоятельное изучение, но и риск потери компетенции при ротации кадров — либо в виде страховки (документация, runbook'и, дублирование знаний между двумя сотрудниками), либо в виде готовности в моменте нанять подрядчика на аварийной основе, что почти всегда дороже планового обучения.

Простой без SLA: когда быстрой замены оборудования нет

У managed-провайдера или облака часто есть SLA (Service Level Agreement) с гарантированным временем реакции и — что важнее — с готовым запасным оборудованием под рукой. При аренде голого выделенного сервера гарантии обычно скромнее: провайдер отвечает за физическую доступность железа, но замена вышедшего из строя диска, блока питания или целого сервера может занять часы, а не минуты, если у вас нет отдельного соглашения с ускоренной заменой.

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

• прямые потери — недополученная выручка за время недоступности, если сервис монетизируется напрямую;
• отток — часть пользователей, которые не вернутся после сбоя, особенно если это не первый инцидент;
• репутационные издержки — сложнее оценить в деньгах, но реальны для B2B, где решение о продлении контракта нередко принимается именно после серьёзного сбоя у поставщика;
• штрафы по вашему собственному SLA перед клиентами, если он есть.

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

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

Как честно посчитать TCO и на что его сравнивать

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

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

Из этого сравнения не следует, что аренда голого сервера невыгодна — для команды с достаточной экспертизой и предсказуемой нагрузкой она по-прежнему часто оказывается дешевле по итоговому TCO, просто не в 2-3 раза, как выглядит по одной строке счёта, а с более скромной, но реальной разницей. Managed-решение или облако выигрывает не универсально, а в конкретных сценариях: команда небольшая и без выделенного администратора, нагрузка непредсказуема, критичность сервиса высокая, а бюджет на резервное оборудование и расширенный SLA отсутствует.

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

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