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

Существенные изменения в архитектуре и инженерных системах датацентра реализуются связкой отдела проектирования и проектного отдела (не следует их путать. На английском языке различие в их наименовании более очевидно: это Design Team и Project Team соответственно, но в русском может быть путаница).

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

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

Подразделение информационной безопасности чаще взаимодействует с ITOPS и NOC – для разработки, внедрения и контроля выполнения правил подключения к сети компании и ограничений по трафику этой сети.

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

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

Отдел кадров покрывает своей деятельностью всю компанию.

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

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

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

Ответив на вопрос «Где?», давайте разберемся с вопросом «Когда?». Представив жизненный цикл датацентра в виде последовательных прямоугольников, мы получим следующую картину:

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

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

По-настоящему команда эксплуатации берется за дело уже на этапе пусконаладочных работ (ПНР^[6]). Часто для проведения ПНР привлекается сторонний агент, иногда, что хуже, эту роль выполняет представитель проектировщика или подрядчика. На самом деле пусконаладка должна стать исходной точкой для построения качественной эксплуатации в дальнейшем. Поэтому ни одна сторона не справится с задачей лучше, чем собственная служба эксплуатации.

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

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

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

Глава 2
Пусконаладка как часть эксплуатации

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

У такого подхода есть огромное преимущество: кроме минимальных сроков ввода объекта, мы обеспечиваем службу эксплуатации интересной и захватывающей работой по поиску неисправностей и их срочному устранению в работающем датацентре на несколько лет вперед. Для тех же заказчиков, которые могли себе позволить потратить какое-то время на проверку смонтированных систем, сторонние организации, как правило, тестировали взаимодействие систем вентиляции и пожаротушения, а также все или самые основные переключения с города на ДГУ (дизель-генераторную установку)^[7] и т. п.

Между тем зарубежный опыт привел к пониманию, что грамотно проведенная пусконаладка позволяет обнаружить и устранить подавляющее большинство неисправностей еще до подключения полезной нагрузки и следующие годы жить намного спокойнее. В мире существует несколько компаний, которые специализируются только на услугах пусконаладки (такой участник процесса называется Commissioning Agent^[8] – агент ПНР) и делают их на самом высоком уровне. Правда, услуги их совсем недешевы, и это еще одна из причин, почему многие заказчики стремятся сэкономить не только время, но и деньги, стараясь избежать полноценных пусконаладочных работ.

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

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

• За время подготовки и проведения пусконаладки будущие специалисты эксплуатации на своем опыте знакомятся со всеми единицами оборудования, их особенностями и ограничениями. Этот опыт в последующие годы будет просто бесценен, даже при наличии самой лучшей документации от поставщика. Кроме того, такие моменты, как постановка оборудования на учет и заполнение всех его данных в системе CMMS^[9], также будут производиться вдумчиво и последовательно для каждой единицы оборудования.

• Все остальные претенденты на роль агента пусконаладки имеют свои собственные интересы, которые будут противоречить задачам дальнейшей многолетней эксплуатации. Так проектировщики, осо-знанно или нет, при обнаружении проектных ошибок не будут заинтересованы в их признании, говоря, что датацентр должен быть построен точно по их проекту. Подрядчики сделают все возможное, чтобы скрыть огрехи стройки, переложив ответственность либо на проектировщиков, либо на поставщиков, либо даже на заказчиков, которые чересчур строго давят на сроки и экономят бюджет. Формальный технадзор приносит много пользы, но, как правило, не до конца понимает сущность работы всего датацентра как единого целого, поэтому легко допускает ситуацию, когда «к пуговицам претензий нет, но костюм носить невозможно». Даже специально приглашенный агент ПНР чаще всего работает за деньги, поэтому воспринимает свою работу как продажу человеко-часов. Их вовлеченность, как правило, оформлена в виде консультационных услуг, поэтому вряд ли они станут защищать интересы клиентов сверх оговоренных рамок.

Другими словами, если не собственная команда эксплуатации – кто тогда?

Определение матрицы ответственных

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

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

Отличную службу здесь может сослужить… PMBOK^[10] – библия проектного управления, в свежих изданиях которой инструменты управления проектами доведены практически до совершенства. Если проектом строительства датацентра занимается прожженный профи, то он в самом начале составит действующий, а не формальный устав проекта, в котором подробно расскажет о назначении, этапах, сроках и участниках ПНР. Например, скопировав все из этой книги. Но даже начинающий руководитель проекта может сделать необходимый минимум – создать матрицу ответственности специально для этапа пусконаладки.

В идеальном случае эта матрица должна попасть приложением в контракты участников проекта.

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

• перечисление всех этапов ПНР в текущем проекте;

• перечисление всех участников ПНР;

• контакты реальных представителей каждого из участников с учетом этапа ПНР. Например, для проведения FAT^[11] (factory acceptance test) и SAT^[12] (site acceptance test) это могут быть разные люди;

• перечисление ролей внутри каждого из этапов и соответствие ролей и участников.

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

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

Этапы ПНР

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