ТЗ на ИТ-инфраструктуру: как не ошибиться в требованиях

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

1. Что понадобится (требования)

Хорошее ТЗ рождается не в тендерном отделе, а после инвентаризации и замеров. Вам нужно собрать четыре блока фактов, прежде чем писать «требуется 1 сервер»:

• Инвентаризация. Список оборудования: модели, ядра, RAM, диски, тип хранилища. Чем точнее, тем меньше вопросов у поставщика.
• Профиль нагрузки. Утилизация CPU, RAM, IOPS и сеть за неделю пиков. Это цифры, а не «10 пользователей».
• Требования доступности. Допустимый простой и нужное число «девяток» — от этого зависит состав оборудования и резервирование.
• Условия закупки. 44-ФЗ или 223-ФЗ, требование реестра Минпромторга, сроки поставки, специфика бюджета.

Смотреть на реальные конфигурации и наличие удобнее по каталогам: серверы, хранилища, сеть.

2. Шаг 1 — Зафиксировать цели и границы

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

Пример формулировки вместо «замена серверов»:

Серверный комплекс должен круглосуточно обслуживать систему учёта на 400 рабочих мест с пиковой загрузкой 60% CPU и 8 ч непрерывного простоя в год не более.

Именно так из желания получается измеримое требование, по которому потом можно проверить исполнение.

3. Шаг 2 — Снять профиль нагрузки (цифры, не слова)

Требования к железу должны опираться на метрики, а не на «у нас принято». Соберите за неделю пиковых наблюдений:

• утилизацию CPU и RAM по каждому хосту (пик, а не среднее);
• IOPS и задержку дисков — определяет класс СХД и число дисков;
• объём и скорость роста баз данных и файловых хранилищ;
• сетевой трафик и число одновременных соединений;
• дефицит ресурсов под пиком (что «тормозит» на самом деле).

Плановые цифры по ёмкости и IOPS закладывайте на 3 года вперёд, чтобы не переписывать ТЗ через год. Готовые ориентиры есть в статье расчёт ёмкости СХД.

4. Шаг 3 — Рассчитать ёмкость СХД и хранилища

Расчёт ёмкости СХД в ТЗ — то место, где чаще всего хоронят бюджет или, наоборот, создают будущий дефицит. Формула на 3 года:

• Чистый объём = текущий объём × коэффициент роста на каждый год.
• Рабочий объём = чистый объём × (1 + 0,3–0,5) на снапшоты и резервные копии.
• Итог в массиве = рабочий объём / полезная ёмкость RAID (для RAID 6 на 12 дисках полезно ≈ 10 из 12).

Пример: база 2 ТБ, рост 40% в год. К 3 году: 2×1,4×1,4×1,4 ≈ 5,5 ТБ. Плюс 40% на копии и снапшоты ≈ 7,7 ТБ. В RAID 6 на 12 дисках значит около 9–10 ТБ брутто. Эти числа и пишем в ТЗ — и не «минимум 5 ТБ».

5. Шаг 4 — Описать сеть и резервирование

Сеть в ТЗ нередко сводят к строке «коммутатор на 24 порта». Уточните реальную топологию:

• аплинк серверов и канал к СХД (10GbE и выше);
• ядро L3 для маршрутизации между сегментами и резервирования;
• PoE для камер, IP-телефонии и точек доступа;
• сегментация (VLAN) и изоляция сетей;
• резервирование аплинка и наличие второго контура.

Если нужен практически непрерывный контур, пропишите в ТЗ резервирование: пару узлов в отказоустойчивом кластере и распределённую СХД. Разбор уровней доступности — в статье доступность «N 9s».

6. Шаг 5 — Прописать требования к реестру и закупке

Для госзаказчика и компаний с госдолей в ТЗ обязательно заложить требования по 44-ФЗ/223-ФЗ:

• оборудование из реестра Минпромторга (запись реестровой позиции);
• паспорт реестровой записи в комплекте поставки;
• сертификаты соответствия и гарантийные обязательства;
• срок поставки и условия монтажа;
• способ закупки и критерии оценки — НМЦК, сроки, технические требования.

Правильно написанное ТЗ экономит месяцы согласований и снимает риски оспаривания закупки. Компания «ПОЛЕЗНЫЕ ЦИФРЫ» работает по 44-ФЗ и 223-ФЗ, помогает с перечнем документов и типовых регламентов.

7. Шаг 6 — Добавить приёмку и проверку

ТЗ без критериев приёмки — это документ «на бумаге». Пропишите, как будете проверять результат:

• нагрузочный тест (что считается «система работает» под пиком);
• проверка IOPS и задержки в реальных задачах;
• проверка резервирования (аварийное отключение одного узла);
• передача документации, ЗИП и гарантийных обязательств.

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

8. Типовые ошибки и как их избежать

8.1 Мини-шаблон структуры ТЗ

Если готового бланка нет, соберите документ из восьми блоков. Такой каркас покрывает и закупку, и приёмку.

1. Общие сведения — заказчик, объект, сроки, основание для закупки.
2. Цели и задачи — что должна делать система, измеримые требования.
3. Текущее состояние — инвентаризация оборудования, нагрузки, точки роста.
4. Требования к системе — серверы, СХД, сеть с цифрами.
5. Требования к доступности — число «девяток», резервирование, допустимый простой.
6. Требования к реестру — реестровая запись Минпромторга, документы, соответствие 44-ФЗ/223-ФЗ.
7. Условия поставки — сроки, монтаж, гарантия, ЗИП, обучение.
8. Порядок приёмки — нагрузочный тест, проверка резервирования, передача документации.

Наличие всех восьми блоков заметно снижает риск, что на этапе приёмки всплывёт то, о чём «не договорились». Это же экономит время на согласовании с поставщиком и на площадке.

9. Чек-лист

• Цели сформулированы и измеримы (что делает, с кем, с каким простоем)
• Профиль нагрузки снят за неделю пиков (CPU, RAM, IOPS, сеть)
• Ёмкость СХД рассчитана на 3 года с запасом на копии
• Требования к резервированию и числу «девяток» прописаны
• Сеть описана топологией (аплинк, L3, PoE, VLAN)
• Требования к реестру Минпромторга и 44-ФЗ/223-ФЗ заложены
• Критерии приёмки и нагрузочный тест включены
• ЗИП, гарантия и срок поставки зафиксированы

10. Вопросы и ответы

Что важнее в ТЗ — объём СХД или IOPS? Обе метрики, но для разных задач. Базы и 1С требуют IOPS, файлы и бэкапы — ёмкость и пропускную способность. Прописывайте обе.

Как прописать «аналог западного сервера» без названия? Не указывайте модель. Пишите характеристики: количество ядер, частоту, RAM, тип дисков, сетевые интерфейсы. Так закупка станет корректной и сравнимой.

Можно ли в ТЗ указать конкретного вендора? В госзакупках жёсткая привязка к бренду рискованна — её оспаривают. Указывайте характеристики и требования реестра, а бренд — как ориентир.

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