Свой ЦОД или интегратор выбирают по цене простоя

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

Я считаю такой выбор через три сценария, один горизонт и одинаковую доступность. Сначала отделяю IT-оборудование, которое понадобится при любом варианте, затем считаю площадку, электричество, людей, резервирование и срок ввода. Этот порядок быстро показывает, где собственный ЦОД дает контроль, а где организация покупает дорогую возможность, которой пока не пользуется.

Сначала зафиксируйте единицу сравнения

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

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

Зафиксируйте пять границ до получения коммерческих предложений:

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

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

Три сценария отделяют рост от паники

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

Возьмем иллюстративную организацию с горизонтом пять лет. В сценарии A средняя IT-нагрузка достигает 60 кВт, пик составляет 90 кВт. В сценарии B средняя нагрузка равна 180 кВт, пик 270 кВт. В сценарии C средняя нагрузка доходит до 450 кВт, пик до 675 кВт. Эти числа не описывают рынок и не заменяют замеры. Они показывают механику расчета, а читатель подставляет свои данные.

Проектировать собственную площадку ровно на среднее нельзя. Для примера примем установленную IT-мощность 120, 360 и 900 кВт соответственно. Двукратный запас здесь включает пик, отказ одного элемента и очередной шаг расширения, но не означает, что коэффициент два подходит всем. Если нагрузка растет блоками по 200 кВт, модуль должен соответствовать этому блоку. Если рост плавный, крупный запас лишь замораживает деньги.

Сводные значения по сценариям:

• Сценарий A: средняя IT-нагрузка 60 кВт, пик 90 кВт, установленная мощность своей площадки 120 кВт; базовая позиция - интегратор.
• Сценарий B: средняя IT-нагрузка 180 кВт, пик 270 кВт, установленная мощность своей площадки 360 кВт; базовая позиция - проверить оба варианта.
• Сценарий C: средняя IT-нагрузка 450 кВт, пик 675 кВт, установленная мощность своей площадки 900 кВт; базовая позиция - свой ЦОД или гибрид.

Последняя строка не является ответом. При 60 кВт собственная площадка может быть обязательна из-за режима данных или отсутствия подходящего объекта рядом. При 450 кВт интегратор может выиграть, если заказчику нужна мощность через несколько месяцев или нагрузка держится только короткими окнами. Таблица задает направление проверки, а не заменяет ее.

Электричество надо считать от IT-нагрузки

Годовое потребление считается от измеренной IT-нагрузки и PUE, а не от номинала вводного автомата. PUE равен отношению всей энергии площадки к энергии IT-оборудования. Руководство Федеральной программы энергоменеджмента Министерства энергетики США отдельно предупреждает: PUE описывает эффективность поддерживающей инфраструктуры, но не эффективность вычислений. Сервер, который простаивает, может стоять в площадке с хорошим PUE и по-прежнему впустую расходовать деньги.

Для модели примем PUE своей площадки 1,60, 1,45 и 1,35 по мере роста загрузки. Для инфраструктуры интегратора используем 1,40, 1,32 и 1,28. Это расчетные допущения, не обещание конкретного объекта. Запросите у оператора годовое измеренное значение, границы измерения и помесячный график, а для собственного проекта получите расчет на частичной нагрузке. Проектный PUE при полной мощности мало говорит о первом годе работы.

Формула проста:

annual_kwh = average_it_kw * PUE * 8760
electricity_cost = annual_kwh * tariff_per_kwh
five_year_cost = capex + 5 * (electricity_cost + staff_cost + maintenance + service_fees)

При заданных допущениях сценарий A потребляет 840 960 кВт·ч в год на своей площадке и 735 840 кВт·ч у интегратора. Разница равна 105 120 кВт·ч. В сценарии B получаем 2 286 360 и 2 081 376 кВт·ч, разница 204 984 кВт·ч. В сценарии C получаем 5 321 700 и 5 045 760 кВт·ч, разница 275 940 кВт·ч.

Чтобы получить деньги, умножьте каждое значение на свой полный тариф. В него должны входить энергия, передача, мощность и другие применимые начисления из счета. Если тариф обозначить T тенге за кВт·ч, годовая экономия интегратора в трех сценариях равна 105 120T, 204 984T и 275 940T тенге. Такой вид честнее случайной цены из чужого проекта и сразу показывает чувствительность результата к тарифу.

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

Капитальные расходы проигрывают ожиданию

CAPEX собственной площадки растет ступенями, а не ровной линией за киловаттом. Второй ввод, еще один ИБП, генератор, чиллер или машинный зал покупаются крупным блоком. Между ступенями часть оборудования простаивает, но организация уже заплатила за проектирование, доставку, монтаж и пусконаладку.

Соберите модель из заменяемых ячеек. Для своей площадки это стоимость помещения и строительных работ F, стоимость одного установленного киловатта инфраструктуры K, сетевой контур N и пусконаладка P. Для интегратора это разовая миграция M, подключение каналов L и ежемесячная плата S за согласованную мощность и сервисы. IT-оборудование H добавляйте в обе стороны только в той части, где оно различается.

own_capex_A = F + 120*K + N + P + H_own_A
own_capex_B = F + 360*K + N + P + H_own_B
own_capex_C = F + 900*K + N + P + H_own_C

integrator_5y = M + L + H_integrator + 60*S + variable_usage
break_even_month = (own_capex - M - L) / (integrator_monthly - own_monthly)

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

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

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

Штат нельзя спрятать в строке поддержки

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

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

Для трех сценариев используйте не выдуманное число сотрудников, а матрицу покрытия. В каждой строке укажите часы присутствия, время реакции, основного исполнителя и замену. Затем посчитайте полную стоимость сотрудника, обучение, дежурства и подрядчиков. Для сценария A разумно проверить модель с удаленным наблюдением и выездом по вызову. Для B обычно требуется постоянная эксплуатационная функция. Для C один общий IT-отдел уже не заменяет отдельную команду площадки.

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

Сравнивайте одинаковые режимы. Если собственный вариант включает дежурство 24/7, а предложение интегратора предусматривает ответ в рабочее время, низкая цена куплена за счет другого риска. И наоборот, не нагружайте внешний вариант максимальным пакетом услуг, если собственная смета предполагает реакцию одного сотрудника «по возможности».

Резервирование считают по отказам, не по буквам N

Одинаковая надпись N+1 не гарантирует одинаковую устойчивость. Нужно пройти путь питания, охлаждения, сети и данных от внешнего источника до конкретного приложения и найти общие точки отказа. Два ИБП бесполезны, если оба получают питание через один щит, а два канала связи мало помогают, когда они входят в здание по одной трассе.

Uptime Institute определяет Tier III через одновременную ремонтопригодность: каждый компонент мощности и путь распределения можно планово вывести без остановки работы. При этом объект остается уязвимым к некоторым отказам оборудования и ошибкам оператора. Это важное различие. Маркетинговая фраза «уровень Tier III» без сертификации и без схемы переключений не доказывает, что обслуживание пройдет без перерыва.

Для каждого сценария проведите четыре отказных теста на бумаге и затем на приемке:

1. Отключите основной ввод и проследите питание до стоек.
2. Выведите один ИБП и один контур охлаждения на плановое обслуживание.
3. Оборвите каждый внешний канал связи отдельно, затем проверьте общую трассу.
4. Потеряйте целый зал или площадку и восстановите сервис из копии.

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

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

Срок запуска меняет экономику

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

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

У интегратора путь короче лишь при наличии свободной мощности. Нужно проверить доступные киловатты сегодня, срок резервирования, поставку стоек или серверов, каналы связи, проверку безопасности, договор и миграцию. Фраза «площадь есть» не подтверждает наличие мощности на ИБП, охлаждении и генераторах.

В модели задайте дату потребности D и даты готовности O для своей площадки и I для интегратора. Стоимость задержки равна числу месяцев после D, умноженному на потерянную маржу, стоимость ручного обхода или штрафы, которые действительно относятся к проекту. Не используйте абстрактный «репутационный ущерб», если финансовая команда не может объяснить его расчет.

Если интегратор запускает нагрузку на 12 месяцев раньше, добавьте к собственному варианту год стоимости ожидания. Иногда это полностью переворачивает пятилетний TCO. Иногда временная площадка работает как мост: организация платит интегратору до ввода своего ЦОД, затем переносит стабильную базовую нагрузку и оставляет право быстро наращивать пик снаружи.

Гибридный контракт снижает цену ошибки

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

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

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

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

Прогноз надо проверить телеметрией до закупки

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

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

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

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

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

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

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

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

Есть еще одна граница, которую часто пропускают. Мощность, заказанная у энергоснабжающей организации, мощность инженерной инфраструктуры и мощность, доступная IT-нагрузке, являются разными величинами. Потери, резервирование и PUE связывают их, но не делают равными. Если проектировщик показывает 1 МВт на вводе, спросите, сколько кВт останется для IT при отказе одного предусмотренного компонента и при расчетной наружной температуре. Тот же вопрос задайте интегратору в точке вашего подключения.

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

Решение принимает ограничение, а не средняя цена

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

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

На защите бюджета покажите одну страницу с тремя строками сценариев и семью числами: средняя IT-нагрузка, пик, установленная мощность, годовые кВт·ч, пятилетний TCO, дата готовности и стоимость задержки. Рядом поставьте четыре доказательства устойчивости: схема питания, схема сети, результат восстановления из копии и протокол вывода компонента на обслуживание. Этой страницы достаточно, чтобы убрать из разговора лозунги о полном контроле и экономии на аренде.

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