Техническое задание на проектирование ЦОД: состав и чек-лист

Техническое задание на проектирование ЦОД должно фиксировать не перечень желаемого оборудования, а проверяемые требования к будущему объекту: назначение, IT-нагрузку, этапы роста, допустимые режимы отказа и обслуживания, границы проекта, исходные данные площадки, состав документации и критерии приёмки. Если параметр ещё не подтверждён, его отмечают как допущение с ответственным и сроком уточнения. Такой документ позволяет сравнивать предложения проектировщиков по одной базе и не переносить неопределённость в закупки и строительство.

Кому и когда нужен этот материал

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

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

Какие исходные данные нужны для ТЗ

Удобно вести не просто список файлов, а реестр исходных данных со статусом: «подтверждено документом», «измерено», «принято как допущение» или «требует решения заказчика».

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

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

Структура технического задания на проектирование ЦОД

Ни один нормативный документ не даёт универсальный шаблон ТЗ для любого дата-центра. Состав зависит от объекта, стадии и договора. На практике рабочая структура включает следующие разделы.

1. Общие сведения и цель проекта

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

2. Границы работ и интерфейсы

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

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

3. IT-нагрузка и развитие

В ТЗ разделяют:

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

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

4. Надёжность, обслуживание и аварийные сценарии

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

Формулировка «сделать Tier III» не заменяет описание режимов. Если требуется сертификация Uptime Institute, отдельно фиксируют объект сертификации, этап, ожидаемый сертификат и ответственность за сопровождение. Схемы N+1, 2N и 2N+1 также не следует назначать одинаково всем системам без анализа риска и стоимости.

5. Требования к инженерным системам

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

Неудачная формулировка	Проверяемая формулировка
«Современная система охлаждения»	Обеспечить заданные условия для утверждённой IT-нагрузки во всех предусмотренных нормальных, сервисных и аварийных режимах
«Высокая надёжность»	Перечислить допустимые события и работы, при которых IT-нагрузка должна сохраняться без остановки
«Энергоэффективный ЦОД»	Определить методику расчёта, границы измерения, расчётные режимы и показатели, проверяемые проектом и эксплуатацией
«Резерв по мощности 30 %»	Указать, к какой мощности и к какой системе относится резерв, на каком этапе он устанавливается и чем подтверждается
«Автоматическая диспетчеризация»	Перечислить контролируемые параметры, тревоги, архив, роли пользователей и сценарии управления

6. Архитектурные, строительные и площадочные ограничения

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

7. Эксплуатация и ремонтопригодность

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

8. Состав документации и информационная модель

Заказчик определяет требуемые стадии, разделы, форматы, уровень детализации, правила именования, состав расчётов и спецификаций, требования к BIM при его применении, порядок согласования и внесения изменений. Состав проектной документации объекта капитального строительства формируют с учётом действующей редакции Постановления Правительства РФ № 87, а общие правила оформления проектной и рабочей документации — ГОСТ Р 21.101-2026. Связь ТЗ с последующими комплектами раскрыта в материале об этапах и составе проекта ЦОД.

9. Проверки, испытания и приёмка результата

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

Инженерный пример: как требование влияет на проект

Допустим, заказчик планирует первую очередь на 400 кВт IT-нагрузки с ростом до 800 кВт. Этого недостаточно для выбора архитектуры. Нужно уточнить плотность стоек, характер нагрузки, допустимые окна обслуживания, условия присоединения и способ расширения.

Если в ТЗ записать только «800 кВт и N+1», проектировщики могут предложить несопоставимые варианты: сразу установить полную инфраструктуру, построить две независимые очереди или зарезервировать помещения и подключения для будущего оборудования. Все решения формально отвечают короткой фразе, но отличаются CAPEX, сроком ввода, эффективностью при частичной загрузке и риском остановки при расширении.

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

Типовые ошибки заказчика

Копировать ТЗ другого ЦОД. Чужой документ переносит чужую нагрузку, площадку, модель эксплуатации и допустимые риски.

Смешивать требование и решение. Марка оборудования или готовая схема могут закрыть более подходящие варианты до расчёта.

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

Не фиксировать допущения. Неподтверждённая мощность превращается в «исходный факт» и обнаруживается как проблема уже после выпуска документации.

Принимать только по комплектности. Наличие всех томов не гарантирует согласованности нагрузок, интерфейсов и алгоритмов работы систем.

Менять требования без оценки последствий. Каждое изменение IT-нагрузки, этапности или надёжности должно сопровождаться анализом стоимости, срока и уже выпущенных решений.

Какие нормы учитывать

ГОСТ Р 58811-2020 устанавливает стадии создания инженерной инфраструктуры ЦОД, этапы и содержание работ. ГОСТ Р 70627-2023 определяет состав и содержание документации технической концепции. СП 541.1325800.2024 действует для проектирования зданий, сооружений и помещений ЦОД.

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

Чек-лист перед выдачей ТЗ проектировщику

Техническое задание готово к выпуску, если заказчик может ответить «да» на следующие вопросы:

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

Связанный кейс: зачем проверять требования на реальном объекте

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

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

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

Кто должен разрабатывать ТЗ на проектирование ЦОД?

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

Что входит в техническое задание на проектирование ЦОД?

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

Можно ли заказать проектирование без готового ТЗ?

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

Чем ТЗ отличается от технической концепции ЦОД?

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

Материал подготовлен командой ЦОДПРОЕКТ — проектирование и строительство центров обработки данных.