Kitobni o'qish: «Настольная книга эксплуататора. Всё, что вы хотели знать о повседневной жизни датацентров, но боялись спросить»

Редакторы: Никита Киселев, Людмила Васильева

Дизайн Антон Лойбо

Корректоры Саша Нойвельт, Наталья Ерохина

Верстка Саша Нойвельт

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

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

© Жумыкин А., 2022

© ООО «Альпина ПРО», 2022

* * *

Книга издана при поддержке АНО «Координационный совет по ЦОДам и облачным технологиям» (АНО КС ЦОД)

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

Я был приятно удивлен, что идеи автора весьма созвучны стандарту эксплуатации датацентров Tier Standard: Operational Sustainability от Uptime Institute. Эта книга является его расширенным дополнением. В отличие от более чем лаконичного текста стандарта, здесь все изложено в деталях и подробностях с массой практических рекомендаций.

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

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

Алексей Солодовников,

управляющий директор Uptime Institute в России и странах СНГ

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

Стихотворение, приписываемое Бенджамину Франклину, 1758 г.

Перевод Самуила Маршака

Предисловие от компании 3data

Компания 3data² решила издать эту книгу, потому что мы не понаслышке знаем, насколько важна роль эксплуататоров в функционировании ЦОДов. Наша сеть насчитывает десятки центров обработки данных по всей России. Опыт Алексея Жумыкина, которым он делится в книге, позволит нашим специалистам и всем инженерам ЦОДов свежим взглядом посмотреть на собственные рабочие процессы, оценить и улучшить их. Мы рассчитываем, что книга станет настольной для профессионалов отрасли.

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

Оборудование датацентров работает 24/7 365 дней в году. И люди тоже. Инженерные системы ЦОДов способны противостоять инцидентам и непредвиденным ситуациям. И люди тоже. Чем надежнее техника, тем незаметнее для пользователей ее труд. И вклад людей тоже.

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

Илья Хала,

генеральный директор сети датацентров 3data

Введение

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

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

Эта невидимая армия заслуживает своего описания – именно службе эксплуатации будут посвящены страницы данной книги.

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

Когда, спустя несколько лет, я вновь сел за свой старый, но все еще быстрый Lenovo Х220, то вдруг по-настоящему понял признак истинного профессионала эксплуатации. Выбирать надежное оборудование, следить за его исправностью и использовать так долго, пока окружающие не начнут спрашивать: «Где ты откопал такой раритет?» За более чем десяток лет я продолжаю ежедневно сталкиваться с проблемами, решений для которых еще нет, и придумать их необходимо здесь, сейчас и конкретно для этого случая. И теперь мне больше всего хочется не научить, а рассказать. Однако работа единомышленников в больших компаниях помогла сформировать некие общие принципы, подходы к процессу эксплуатации, придерживаясь которых справляться с проблемами стало значительно проще. Именно этими принципами я и хочу поделиться.

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

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

Немного о терминологии. В российской тусовке принято сокращать центры обработки данных как ЦОД. Это, конечно, правильно, но звучание такой аббревиатуры лично меня коробит. Сразу представляются ряды электронно-вычислительных машин (ЭВМ), заполняющие эти ЦОДы, и среднего возраста научные работники в очках и белых халатах с пачкой перфокарт в руках. Лично мне, как и всей команде, с которой я работал, больше по душе сокращение ДЦ – датацентр.

Остальные разъяснения будут появляться по мере необходимости непосредственно в тексте. Итак, приступаем…

Глава 1
Зоны ответственности команды эксплуатации

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

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

Команда эксплуатации датацентров (Data Center Operations = DCOPS³) в нашем примере обеспечивает функционирование всех трех ипостасей датацентра. Основная задача – обеспечение беспрерывного снабжения серверного оборудования ресурсами, то есть электричеством и охлажденным воздухом. Формальная граница между командой DCOPS и командой эксплуатации серверного оборудования может проходить по разъемам коробок отбора мощности на шинопроводах или разъемам кабелей питания, отходящих от главного распределительного щита.

Другие функции DCOPS: поддержание исправности инженерного оборудования, а также разнообразных процессов жизнедеятельности площадки – от функций генерального директора до заказа обедов для посетителей датацентра.

Команда эксплуатации серверного оборудования (IT Operations = ITOPS⁴) отвечает за работоспособность серверов, стоек и вспомогательного оборудования в стойках, кроссировку и т. п. Эта команда является точкой входа для заказчиков, поэтому именно в составе ITOPS имеет смысл организовать круглосуточную службу поддержки, которая будет принимать на себя все вопросы извне, связанные с работой датацентра, и координировать потоки информации внутри датацентра.

Команда сетевых подключений (Network Operations Center = NOC⁵). Этот отдел может как быть частью команды внутри конкретного датацентра, так и ориентироваться на решение задач внешней связности. Обычно участие его сотрудников в ежедневной жизни датацентра ограничивается написанием правил, по которым заказчики подключаются к сети, и размещением собственного оборудования в специально выделенных помещениях и стойках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этапы ПНР

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

1. DCC¹⁴ (Design Compliance Check) – проверка соответствия проекту

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

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

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

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

2. FAT, FWT¹⁵ (Factory Acceptance Test, Factory Witness Test) – заводские испытания оборудования

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

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

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

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

Другой повод для визита находится где-то посередине между упомянутыми DCC и FAT. Когда оборудование изготавливается впервые, например по ТЗ заказчика, то имеет смысл приехать на так называемый pre-FAT, чтобы убедиться, что мелочи, которые невозможно было сразу разглядеть в документации на новое изделие, не помешают качественно эксплуатировать оборудование. Для примера приведу случай, когда изготовитель установил контрольный прибор на высоте около 2,5 м, и для снятия показаний была нужна лесенка. Или рама вент-установки, на которой крепились фильтры, имела недостаточную жесткость и при работе вентиляторов прогибалась бы под напором воздуха. Такие мелочи рано или поздно были бы обнаружены, но устранить их, пока оборудование еще на заводе, – гораздо быстрее, дешевле, да и правильнее.

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

3. IA (Installation Acceptance) – приемка монтажа

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

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

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

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

4. CT (Component Test) – компонентное тестирование (индивидуальные испытания)

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

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

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

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

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

5. SAT (Site Acceptance Test) – приемо-сдаточные испытания

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

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

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

6. ISAT¹⁶ (Integrated Site Acceptance Test) – интегральный тест

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

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

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

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

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

Главное, на что стоит обратить внимание во время ISAT, – это то, как датацентр функционирует при своей максимальной загрузке. Например, стойки потребляют 100 % отведенного им электричества, вентиляция работает на всю катушку, а за стенами датацентра жара в 35 градусов и влажность в 80 %. При таких условиях нужно провести переключения между всеми режимами, убедившись, что характеристики датацентра не ухудшаются ни в одном из их. В каждом режиме необходимо проработать достаточное время (как минимум несколько часов) и за это время снять все температурные характеристики электрических соединений.

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

Еще пример: в одном проекте мы перебрасывали 100 % мощности на резервный источник питания, соединенный по шинопроводу. Через короткое время удлинение шинопровода от нагрева составило 8 см (!), даже несмотря на то, что стояло несколько компенсаторов. Естественно, геометрическая фигура, в которую был завернут шинопровод, немного исказилась, а если бы места прохода через стены были заштукатурены, ремонт пришлось бы переделывать. Понятно, что при снятии нагрузки шинопровод охладился и все вернулось на исходную позицию. Как вы думаете, сколько таких циклов выдержат болтовые соединения узлов шинопровода?

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

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

Очевидно, что программу интегрального теста писать, кроме агента пусконаладки, некому. А вот проводить все тестирование должна именно команда эксплуатации под пристальным наблюдением агента ПНР. Однако могут возникнуть ситуации, при которых потребуется участие представителей монтажников или производителей. Поэтому еще на момент тендера нужно запросить стоимость такого участия, честно предупредив, что, возможно, делать ничего не понадобится, но нужно просто быть рядом. В коммерческом предложении заказчик может ориентировочно оценить время участия (например, 3 дня), а подрядчик может указать стоимость человеко-часа таких работ. Этого будет достаточно.

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

7. HO (handover) – передача в эксплуатацию

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

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

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

Итак, в этом заключительном этапе пусконаладки мы должны убедиться в том, что:

• передана последняя актуальная версия проектной документации;

• передана вся исполнительная документация;

• как часть ИД собрана вся документация от поставщиков оборудования;

• структурирована и передана вся документация по ПНР;

• приобретен комплект ЗИП для оборудования минимум на первый год эксплуатации;

• заключены контракты на обслуживание;

• написаны эксплуатационные инструкции для оборудования;

• в соответствии с инструкциями закуплен инструмент;

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

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

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

Запросить, что входит в стандартный комплект ЗИП¹⁷ для оборудования, и оценить его стоимость нужно еще во время тендера. Это станет дополнительным фактором для осознанного выбора, и новый блестящий датацентр будет сразу же укомплектован всем необходимым. Важно достичь по этому вопросу полного понимания с проектной командой, потому что, в случае нехватки денег в бюджете проекта, они будут склонны экономить на закупке запасных частей – ведь все равно эксплуатация их потом купит. Можно и так, но тогда эти затраты должны быть заранее учтены в бюджете отдела эксплуатации.

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

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

Собираем план вместе

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

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

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

Ресурсы ограниченны. Одна команда специалистов может выполнять только один тест в единицу времени, как в примере, описанном выше. Если требуется ускорение, то такие команды следует распараллелить. Очевидно также, что одна и та же команда не может одновременно выполнять IAT одного оборудования совместно с CT или SAT другого. Поэтому после составления графика нужно убедиться, что подобных конфликтов нет.

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

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

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

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

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

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

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

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

Особенности подготовки документов

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

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

• Не просто формальной, а очень важной частью программы является описание предварительных условий, куда входит процедура перевода оборудования в состояние готовности к тестированию (например, выполнение процедуры LOTO¹⁸), перечисление всех необходимых инструментов (не забывая СИЗ (средства индивидуальной защиты), рации, блокноты, фото, видеокамеры и т. д.), проверка необходимых квалификаций персонала, проводящего испытания.

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

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

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

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

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

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

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

Перепусконаладка

Recommissioning – повторное проведение ISAT-тестов через несколько лет для того, чтобы уточнить, насколько ухудшились характеристики всех систем, а также выявить компоненты, которые находятся уже в пограничном состоянии, и заменить их. Это очень полезное мероприятие, но понятно, что его проведение сопряжено с рядом сложностей. Во-первых, желательно, чтобы тестируемый модуль не использовался рабочими стойками, то есть такое тестирование можно провести, например, когда предыдущий заказчик закончил аренду, а новый еще не въехал. Во-вторых, нужно быть готовым, что в результате такого теста может потребоваться замена какого-то дорогостоящего оборудования, например ИБП¹⁹ (источник бесперебойного питания). С другой стороны, лучше потерять сомнительное оборудование во время тестирования, чем при работе с уже установленными стойками заказчика.

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

Глава 3
Построение команды эксплуатации

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

Для того чтобы эта информация была доступна всем заинтересованным лицам, таблицу контактов можно оформить на внутреннем ресурсе компании (если таковой есть) или положить на FTP-сервер²⁰ отдела и при необходимости отправлять коллегам ссылку на эту матрицу. Приведу простейший пример такой матрицы:

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

Определение состава

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

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

2. Специалист по охране труда и экологии. Является правой рукой генерального директора, так как бóльшую часть вопросов по ежедневной деятельности юридического лица делят между собой налоговая бухгалтерия и как раз отдел по ОТ.

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

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

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

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

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

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

9. Группа технического обслуживания систем электроснабжения. Количество и состав группы полностью зависят от разнообразия видов оборудования на площадке. Например, эта группа должна обеспечивать техническое обслуживание и ремонт ИБП, дизельных генераторов, распределительных щитов.

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

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

12. Технический директор по IT. Обеспечивает руководство всеми IT-специалистами на площадке, составляет планы, управляет мощностями и т. п.

13. Команда поддержки IT первой линии. По численности почти не уступает дежурным и занимается решением рутинных, хорошо документированных задач, таких как замена вышедших из строя дисков, модулей памяти, коммутациями, перезагрузкой серверов и т. п. В некоторых коммерческих датацентрах эта услуга продается под названием remote hands.

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

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

16. Специалисты систем мониторинга и автоматизации. В современном датацентре инженерное оборудование работает достаточно надежно, по сравнению с ним системы контроля и управления отказывают гораздо чаще. Чтобы налаживать эти системы, а также постоянно оптимизировать набор наблюдаемых данных, многие компании нанимают отдельных специалистов. Также иногда роль таких специалистов достается наиболее талантливым дежурным.

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

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

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

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

Сменность и контроль

Не самым простым вопросом в организации деятельности команды эксплуатации является график сменной работы. При его рассмотрении нужно внимательно учитывать интересы как работодателя, так и работника. Какой режим работы лучше использовать? Сутки через трое (или четверо) или более сложный график сменами по 12 часов?

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

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

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

Что же хорошего в 24-часовой смене? Оказывается, если составить график дежурств на год для десяти человек, основываясь на всех нормативных ограничениях по длительности беспрерывного отдыха, количеству рабочих часов в неделю и т. п., а затем одного за другим выводить сотрудников из табеля (по болезни, в отпуск и т. д.), то мы выясним, что полная комплектация штата сотрудниками возможна при одновременной работе всего шести человек (или, при долгосрочном отсутствии, четырех). Да, придется платить за переработки, но не нужно будет нанимать «запасных» сотрудников на случай массовых отпусков. Но при 12-часовой смене придется держать в штате как минимум восьмерых дежурных. Минувшая пандемия показала, насколько чувствителен может быть датацентр к помещению персонала в карантин, поэтому приведенный вопрос становится совсем не праздным. Практически приемлемым решением могут быть 12-часовые смены по умолчанию и переход на 24-часовые смены при введении в компании каких-либо ограничений наподобие пандемийных. При таком переходе также уменьшится количество контактов при передаче смен, что снизит риски помещения в карантин контактирующих коллег.

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

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

Проверка службой безопасности

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

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

Медицинское освидетельствование

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

При организации датацентра как юридического лица и наполнении его штатного расписания проводится специализированная оценка условий труда (СОУТ), в результате которой определяются вредные и опасные факторы, воздействующие на сотрудников на рабочем месте.

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

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

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

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

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

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

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

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