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

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

Разбираем проектную документацию

Сопутствующие документы создаются с конкретной целью и «расписывают» всю логическую цепочку сотрудничества Заказчика и Исполнителя. Каким образом? Смотрите сами.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Это документ, в котором Заказчик ставит задание перед Исполнителем – что, когда и в каком объеме он хочет получить.

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

ПЛАН И РЕЗУЛЬТАТЫ АУДИТА

Эти документы связанны с визуализацией, анализом и планированием будущей системы. В первом указывают запланированный объем проверки, во втором – итоговый результат проверки.

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

HLD

Высокоуровневый дизайн — это рабочий концепт архитектуры будущей IT-системы, о котором мы уже писали ранее.

СПЕЦИФИКАЦИИ

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

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

LLD

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

ПЛАН ВЫПОЛНЕНИЯ РАБОТ

Здесь все понятно – Исполнитель согласовывает с Заказчиком, что, как и когда будет делать. Все это и фиксируется в документе.

ПЛАН ТЕСТИРОВАНИЯ

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

Важно: документ должен на 100% соответствовать исходному ТЗ. Только так Исполнитель сможет доказать, что выполнил все условия Заказчика.

ДОКУМЕНТЫ ПО ЭКСПЛУАТАЦИИ

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

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

ПЛАН АВАРИЙНОГО ВОССТАНОВЛЕНИЯ

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

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

ИНТЕГРАЦИЯ СО СМЕЖНЫМИ СИСТЕМАМИ

Цель этого документа – описать, как интегрировать новую систему с уже существующими.

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

Мы описали 10 основных документов, которые используются при проектировании IT-инфраструктуры. Они логичны, последовательны и полезны как для эффективного управления проектом и снижения рисков, так и для оценки качества выполненных работ. А значит, имеют практический смысл и для Заказчика и для Исполнителя.