Из чего складывается стоимость владения ЦОД: скрытые статьи ИТ-бюджета

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

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

В этой статье Наталья Царева, директор по продуктам ISPsystem (входит в «Группу Астра»), рассказывает, что входит в совокупную стоимость владения и как грамотно ее считать.

Планирование бюджета собственной инфраструктуры, как правило, начинается с капитальных затрат (CapEx) — это наиболее заметная часть расходов.

В зависимости от масштаба проекта в CapEx могут входить:

• Оборудование — серверы, системы хранения данных, коммутаторы, маршрутизаторы и другое;
• Инженерная инфраструктура — системы электропитания, ИБП, охлаждение и другие элементы, если компания самостоятельно создает или модернизирует площадку;
• ПО и внедрение — лицензии на операционные системы, платформы виртуализации и другое системное ПО;
• Работы по созданию инфраструктуры — проектирование, монтаж и пусконаладочные работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Один из способов снизить такую нагрузку — централизовать управление физической инфраструктурой. Современные платформенные решения позволяют собирать в одном контуре информацию о серверах, СХД, сетевом оборудовании, стойках, PDU, ИБП и других компонентах — независимо от их вендора и модели. Это не только дает возможность видеть актуальный состав инфраструктуры и сопоставлять установленную мощность с фактическим использованием, но и стандартизирует работу с разнородным парком — единые сценарии диагностики, настройки и выдачи серверов применяются ко всему парку оборудования, а не только к однотипным узлам.

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

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

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

• Минимизация рисков через сквозную инвентаризацию и мониторинг

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

• Формирование регламентов управления жизненным циклом ИТ-активов

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

• Внедрение FinOps путем закрепления финансовой ответственности за отделами и командами

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