Компания сравнивает два предложения. Серверы вендора A дешевле на 25%, тендерный комитет почти готов подписать. Через год разница «съедена» затратами на энергопотребление, лицензии гипервизора и платную техподдержку, а спустя три года выбор по цене вышел дороже на 15–20%.
Капитальные расходы - железо, инженерка и монтаж, редко превышают 30% от 5-летних затрат на инфраструктуру. Дальше - как корректно рассчитать TCO серверной инфраструктуры и почему смотреть только на CapEx означает планировать бюджет с зашитой ошибкой.
Что такое TCO и почему цена железа - это меньшая часть
TCO (Total Cost of Ownership, совокупная стоимость владения) - это сумма всех затрат на серверную инфраструктуру за горизонт планирования 3–5 лет. В отличие от прайса на железо, TCO отвечает на вопрос бизнеса: сколько стоит держать ИТ-сервис в рабочем состоянии все эти годы, а не сколько вы платите в момент покупки.
Структура расходов делится на два блока. CapEx (Capital Expenditure, капитальные вложения) - разовые траты на запуск: серверы, СХД, сетевое оборудование, ИБП и PDU, шкафы, монтаж и пуско-наладка. OpEx (Operating Expenditure, операционные расходы) - то, что платите ежемесячно и ежегодно за работу инфраструктуры: электричество, охлаждение, лицензии ОС и гипервизора, техподдержка вендора, ФОТ инженеров и DBA, разбор инцидентов.
По наблюдениям, на горизонте 5 лет доля CapEx редко превышает 30% от совокупной стоимости владения сервером, а OpEx забирает около 70%. Покупать дешевле по цене железа на старте, значит проигрывать на TCO уже к концу второго-третьего года: дешёвая платформа тянет за собой дорогую поддержку, прожорливые лицензии и повышенный счёт за электричество.
Что обязательно включить в расчёт TCO
Прямые затраты на инфраструктуру
CapEx-часть собирается по компонентам. Серверы - конфигурация по CPU, объёму ОЗУ и подсистеме хранения. СХД считается с резервом на рост данных, иначе через два года придётся докупать полки по уже изменившимся ценам. Сеть - коммутаторы доступа и агрегации, оптика, патч-корды, трансиверы. Дополнительно - ИБП и PDU, шкафы, монтажные работы и пуско-наладка, которые в смете часто прячут в строку «прочее».
Отдельная статья - расширение в горизонте. Через 18–24 месяца, как правило, требуется доукомплектация дисками или ОЗУ, дополнительные лицензии на новые ядра при апгрейде CPU, плановая замена комплектующих после окончания гарантии. Резерв 10–15% от стартового CapEx на доукомплектацию - статистически воспроизводимая величина, которую разумно закладывать в модель сразу.
Косвенные и операционные затраты
OpEx-часть начинается с размещения. Если серверы стоят в коммерческом ЦОД - это юниты в стойке, выделенная мощность по питанию, охлаждение, физическая безопасность. Дальше - лицензии ОС и гипервизора, лицензии СУБД с привязкой к ядрам процессора, платная техподдержка вендора, которая в среднем стоит 15–25% от стоимости железа в год. ФОТ инженеров эксплуатации и DBA учитывается в доле, пропорциональной нагрузке на контур, плюс обучение.
Отдельная и часто забываемая статья - стоимость простоев. Считается через RTO (Recovery Time Objective, целевое время восстановления) и RPO (Recovery Point Objective, целевую точку восстановления): час простоя критичного контура пересчитывается в деньги через потерянную выручку, штрафы и стоимость восстановления данных. Это полноценный элемент opex и capex серверов, а не абстракция.
По нашему опыту проектов по расчёту инфраструктурных бюджетов, если пропустить хотя бы один из этих блоков, расхождение со сметой через 3 года составит 30–50% - это уже не погрешность, а системный просчёт модели.
Где люди чаще всего ошибаются в расчётах
Типовых ошибок шесть, и они повторяются из проекта в проект независимо от отрасли. Первое - забытое энергопотребление. Считают паспортную мощность сервера и забывают про PUE (Power Usage Effectiveness, коэффициент эффективности использования энергии) ЦОД. Типовой коммерческий ЦОД в РФ работает в диапазоне 1.4–1.6: на каждый киловатт ИТ-нагрузки площадка тратит дополнительно 400–600 Вт на охлаждение и инженерные системы. Конкретные значения зависят от климата региона и архитектуры площадки, но игнорировать этот множитель нельзя.
Второе - лицензии «по ядрам» при апгрейде CPU. Замена процессора на модель с большим числом ядер автоматически увеличивает счёт за лицензии СУБД и гипервизора, и эта строка иногда удваивается. Третье - стоимость места в стойке через 5 лет: тариф ЦОД редко зафиксирован на весь горизонт, и без индексации модель занижает OpEx. Четвёртое - миграционные расходы при смене вендора железа или гипервизора в середине срока: это работа инженеров, простой сервисов, перенастройка интеграций. Пятое - каналы связи и межЦОДовая связность для георезерва, особенно когда речь про оборудование для центров обработки данных и распределённую архитектуру. Шестое - стоимость хранения резервных копий, особенно при длинных политиках удержания и репликации в удалённую площадку.
Каждая ошибка добавляет в смету несколько процентов. Вместе они дают те самые 30–50% расхождения, которые потом приходится объяснять финансовому директору.
Как считать TCO на практике
Пошаговая модель расчёта
Рабочая модель раскладывается на пять шагов, и каждый предыдущий определяет вход для следующего.
- Зафиксировать горизонт расчёта - 3 или 5 лет. От него зависят допущения по амортизации, по индексации тарифов ЦОД и по моменту, когда железо начнёт требовать плановой замены комплектующих. Менять горизонт по ходу проекта нельзя - это ломает сопоставимость вариантов.
- Собрать CapEx по компонентам: серверы, СХД, сеть, ИБП и PDU, шкафы, монтаж и пуско-наладка. К итогу добавить резерв 10–15% на доукомплектацию в горизонте.
- Посчитать OpEx по статьям: электроэнергия с учётом PUE, размещение в ЦОД, лицензии ОС, гипервизора и СУБД, техподдержка вендора, ФОТ профильных инженеров. Каждую статью провести с инфляционной поправкой по году, иначе пятый год расчёта окажется в ценах первого.
- Учесть стоимость простоев через RTO и RPO. Базовая формула: стоимость часа простоя = часовая выручка контура × доля операций, зависящих от ИТ-сервиса + штрафы по SLA + стоимость восстановления данных. Эта величина умножается на ожидаемое суммарное время инцидентов за год по статистике класса решения для двухнодового кластера с ручным failover это обычно 4–8 часов в год, для отказоустойчивой связки с автоматическим переключением - десятки минут. Полученная сумма закладывается в OpEx-часть TCO как стоимость риска, иначе она остаётся за рамками бюджета и проявляется в каждом фактическом инциденте.
- Свести все варианты в одну таблицу, приведённую к одному моменту времени через NPV или дисконтированную сумму платежей. Сравнивать варианты можно только в этой форме, иначе короткий проект с большим CapEx выглядит дороже длинного с раздутым OpEx.
Модель работает только тогда, когда таблица одна на все рассматриваемые варианты и все статьи лежат на одном листе. Раздельные сметы по отделам, как показывает практика наших проектов, теряют 20–30% затрат на стыках между ответственными: инфраструктурная часть видит одну подсчётную модель, ИБ - другую, эксплуатация - третью, и одни и те же расходы либо дублируются, либо выпадают полностью.
Сравнение по TCO: on-premise, ЦОД, облако
On-premise - это размещение серверов в собственном помещении. Высокий CapEx на запуске за счёт серверов и инженерных систем, но относительно низкий прямой OpEx по железу: вы не платите за юниты в чужой стойке. Минус - высокие косвенные затраты на помещение, кондиционирование, физическую безопасность, ФОТ дежурной смены. Модель оправдана при стабильной долгосрочной нагрузке и жёстких требованиях к контролю над контуром.
Колокация в ЦОД - это средний CapEx (вы покупаете железо, но не строите инженерку) и прозрачный OpEx, где статьи понятны заранее: юниты, выделенная мощность в киловаттах, каналы связи, кросс-коннекты. С компании снимаются вопросы инженерных систем и физической безопасности площадки. Это разумный выбор для стабильной нагрузки и горизонта планирования 3–5 лет, когда CapEx уже амортизируется, а тариф ЦОД остаётся предсказуемым.
Облако - это околонулевой CapEx и высокий, плохо прогнозируемый OpEx. Облачная модель хорошо масштабируется и удобна для пиковых, проектных и сезонных нагрузок, когда платить за неиспользуемые ресурсы было бы расточительно. Но при стабильной долгосрочной нагрузке через 2–3 года эксплуатации облако часто проигрывает on-premise и колокации по TCO - это воспроизводимый результат в нескольких отраслях, от ритейла до промышленных компаний.
Вывод простой: считать TCO нужно на свой профиль нагрузки, а не по общему ощущению «облако дешевле» или «своё железо надёжнее». Структура opex и capex серверов в каждой модели разная, и решение принимается только после сведения всех вариантов в одну таблицу.
С чего начать расчёт
Три практических совета помогают не сорвать модель уже на старте. Горизонт стоит зафиксировать на 5 годах и не двигать его в ходе сравнения - это база для амортизации и индексации. Все статьи затрат должны лежать на одном листе и в одной таблице: разнесённые по подразделениям сметы, по нашему опыту, теряют 20–30% расходов на стыках между ответственными. Модель TCO имеет смысл пересматривать раз в год - тарифы ЦОД, лицензионные политики и стоимость энергии меняются заметно.
Начинать стоит не с прайс-листа железа, а с организации ИТ-инфраструктуры и сервисного контура. Когда понятен целевой SLA, состав ролей сопровождения и политика резервного копирования, расчёт TCO серверной инфраструктуры превращается из догадки в инженерную задачу, которая собирается за пару недель и проходит финансовую проверку без сюрпризов.
