Как составить техническое задание на сервер: что обязательно указать

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

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

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

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

Хорошее ТЗ решает сразу несколько задач

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

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

В-третьих, ТЗ снижает число спорных ситуаций при приемке. Если в документе заранее указаны количество портов, объем ОЗУ, тип дисков, RAID, версия прошивки, условия тестирования и комплект поставки, поставщику сложнее трактовать требования по-своему.

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

Первый раздел ТЗ должен отвечать на простой вопрос: для чего нужен сервер. Нельзя ограничиваться формулировкой "для инфраструктуры компании" или "для работы приложений". Такие описания практически ничего не говорят о фактической нагрузке.

Укажите конкретные сценарии:

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

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

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

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

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

Укажите:

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

Если сервер рассчитан на виртуализацию, процессор следует оценивать вместе с памятью и системой хранения. Большое количество ядер не компенсирует недостаток RAM, а мощный CPU не решает проблему медленной дисковой подсистемы.

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

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

В ТЗ нужно указать не только общий объем RAM, но и условия его дальнейшего расширения.

Минимальный набор требований включает:

• установленный объем оперативной памяти;
• тип памяти;
• наличие ECC, если оно требуется;
• число модулей;
• допустимую емкость одного модуля;
• количество свободных слотов;
• максимальный поддерживаемый объем;
• требования к частоте, если она критична для задачи;
• необходимость резервирования памяти.

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

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

Пример формулировки: "Объем оперативной памяти - не менее 128 ГБ ECC. Конфигурация должна обеспечивать возможность расширения до 512 ГБ без замены установленных модулей". Такая запись намного полезнее, чем просто "RAM 128 ГБ".

Раздел о накопителях должен быть максимально конкретным. Формулировки вроде "быстрые SSD" или "достаточный объем диска" не подходят для технического задания.

Нужно указать:

• тип накопителей: HDD, SATA SSD, SAS SSD, NVMe;
• количество дисков;
• минимальный полезный объем;
• интерфейс подключения;
• форм-фактор;
• наличие горячей замены, если она нужна;
• требования к ресурсу и классу накопителей;
• скорость чтения и записи, если она критична;
• количество дисковых отсеков;
• требования к резервированию.

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

Нужно заранее определить, какой объем должен быть доступен системе после создания RAID. Это принципиальный момент: суммарный номинальный объем всех накопителей и полезная емкость массива - разные показатели.

Если используется RAID, укажите необходимый уровень. RAID 1 подходит для зеркального размещения данных, RAID 5 и RAID 6 позволяют получить баланс емкости и защиты от отказа дисков, RAID 10 ориентирован на высокую производительность и резервирование. Выбор зависит от нагрузки и допустимого времени восстановления.

Не стоит писать "RAID обязательно" без дополнительных требований. В ТЗ лучше зафиксировать требуемый уровень, количество дисков, тип контроллера и необходимость кэширования, если это важно для задачи.

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

В документе укажите:

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

Например, если сервер должен передавать большие объемы данных в СХД по сети, одного гигабитного интерфейса может быть недостаточно. Для современной инфраструктуры может потребоваться 10, 25 или 40 Гбит/с, но конкретная скорость должна быть обоснована нагрузкой и возможностями всей сети.

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

Не забудьте про сетевой интерфейс управления. Для удаленного администрирования требуется отдельный контроллер и доступ к нему по установленному протоколу. В ТЗ можно указать поддержку удаленного включения, перезагрузки, консоли, мониторинга температуры, состояния вентиляторов и накопителей.

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

В ТЗ указывают:

• требуемую ОС;
• редакцию и версию;
• гипервизор, если используется виртуализация;
• необходимость предустановки;
• лицензии;
• драйверы;
• средства удаленного управления;
• необходимое ПО для мониторинга;
• требования к совместимости.

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

Полезно прописать, кто отвечает за установку и первоначальную настройку. Один поставщик может передать только физический сервер, другой - полностью готовую платформу с обновленной прошивкой, гипервизором и базовой настройкой.

Требования к безопасности желательно разделить на аппаратные, программные и организационные.

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

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

В ТЗ полезно прописать:

• поддержку Secure Boot;
• наличие TPM или соответствующего механизма, если он необходим;
• требования к учетным записям;
• смену паролей по умолчанию;
• шифрование каналов управления;
• журналирование;
• требования к прошивкам;
• порядок установки обновлений.

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

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

Возможные требования:

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

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

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

Сервер покупается не на один месяц. Поэтому в ТЗ важно предусмотреть возможность расширения.

Проверьте, предусмотрены ли:

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

Лучше указать не только "должна быть возможность расширения", а конкретный целевой сценарий. Например: "после закупки должно оставаться не менее 50% свободных слотов памяти" или "корпус должен иметь минимум четыре свободных отсека для накопителей".

Такой подход превращает абстрактное требование в проверяемый критерий.

Одна из распространенных ошибок - считать, что все необходимые компоненты автоматически входят в цену сервера.

В ТЗ отдельным разделом перечислите комплект:

• сам сервер;
• процессоры;
• модули RAM;
• накопители;
• RAID-контроллер;
• сетевые карты;
• блоки питания;
• кабели питания;
• направляющие;
• крепеж;
• дополнительные адаптеры;
• трансиверы;
• лицензии;
• документацию;
• носители восстановления, если они предусмотрены.

Для каждого пункта желательно указать количество и статус: "обязательно", "опционально" или "не требуется".

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

Требование "поставить как можно быстрее" не является рабочим критерием. Сроки должны быть измеримыми.

В ТЗ можно разделить проект на этапы:

1. согласование конфигурации;
2. поставка оборудования;
3. входной контроль;
4. монтаж;
5. обновление прошивок;
6. установка ПО;
7. настройка;
8. тестирование;
9. передача документации;
10. приемка.

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

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

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

Заранее составьте перечень проверок:

• соответствует ли процессор заявленным параметрам;
• установлен ли требуемый объем RAM;
• все ли диски определяются системой;
• корректно ли создан RAID;
• работают ли сетевые порты;
• видит ли система все блоки питания и вентиляторы;
• работает ли удаленное управление;
• соответствует ли версия прошивки требованиям;
• запускается ли указанная ОС или гипервизор;
• выполняются ли контрольные тесты производительности.

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

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

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

Хороший критерий имеет измеримый результат.

Например:

Такой формат делает приемку прозрачной и помогает избежать споров.

Первая ошибка - отсутствие назначения сервера. Без сценария использования невозможно корректно обосновать конфигурацию.

Вторая ошибка - чрезмерно общие формулировки. Слова "современный", "мощный", "надежный", "быстрый" не подходят в качестве основного технического требования.

Третья ошибка - отсутствие количественных значений. Если объем памяти, количество портов или емкость дисков не указаны, каждый участник закупки будет трактовать задачу по-своему.

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

Пятая ошибка - отсутствие требований к совместимости. Даже хороший сервер может оказаться неудобным для существующей сети, СХД, стойки или системы мониторинга.

Шестая ошибка - отсутствие критериев приемки. Тогда документ определяет только намерение, но не способ доказать результат.

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

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

Перед публикацией или отправкой документа полезно провести финальную проверку.

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

Проверьте совместимость с инфраструктурой: сетью, СХД, гипервизором, резервным копированием и мониторингом.

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

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

И последний этап - приемка. Для каждого критичного требования должен существовать способ проверки.

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

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

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

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