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

Сама таблица может иметь несколько вариантов. Мы выберем аналог известной RACI[13] – модели, в которой для каждого из участников проставляется роль, которую он играет на данном этапе. Важно отметить, что таблица имеет примерный вид и в каждом конкретном проекте следует внимательно изучать каждую строку матрицы, чтобы избежать конфликтных ситуаций.

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

Классическая модель ПНР строится на пяти шагах (milestones – вехах). Мне довелось несколько раз участвовать в полноценных проектах пусконаладки, и опытным путем мы с коллегами пришли к выводу, что в реальной жизни нужно добавлять еще два: один в начале классической модели и один в конце. Ниже перечислим все эти вехи, при этом я приведу также и их английские наименования. Это может быть полезно при дальнейшем изучении вопроса на англоязычных сайтах.

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

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

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

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

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

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