Когда, спустя несколько лет, я вновь сел за свой старый, но все еще быстрый Lenovo Х220, то вдруг по-настоящему понял признак истинного профессионала эксплуатации. Выбирать надежное оборудование, следить за его исправностью и использовать так долго, пока окружающие не начнут спрашивать: «Где ты откопал такой раритет?» За более чем десяток лет я продолжаю ежедневно сталкиваться с проблемами, решений для которых еще нет, и придумать их необходимо здесь, сейчас и конкретно для этого случая. И теперь мне больше всего хочется не научить, а рассказать. Однако работа единомышленников в больших компаниях помогла сформировать некие общие принципы, подходы к процессу эксплуатации, придерживаясь которых справляться с проблемами стало значительно проще. Именно этими принципами я и хочу поделиться.
Так получилось, что большую часть времени я провел в командах, где были приняты неформальное общение, нестрогое отношение к одежде и внешнему виду. Это не могло не сказаться на живом общении и переписке. Надеюсь, мой стиль не покоробит никого из специалистов отрасли, кроме яростных поборников чистоты русского языка. С другой стороны, некоторая небрежность в одежде никак не коррелирует с жесткой, почти военной требовательностью и скрупулезностью в отношении оборудования.
Управление датацентрами отчасти напоминает промышленные предприятия, где существует большое количество соприкосновений с другими отделами и, несмотря на то что все работают в одной компании, интересы соседних подразделений могут быть противоположны. И как поступать в спорных ситуациях, в общем случае предсказать невозможно. Я постараюсь придерживаться мнения, что команда эксплуатации права, когда ее позиция основана на ее ключевых интересах. Например, если при закупке оборудования выбор стоит между «быстро», «дешево» и «надежно», очевидно, что первое и второе эксплуатацию должно волновать гораздо меньше, чем третье. Другими словами, финансистам, проектному отделу или даже юристам какие-то решения эксплуатации могут не нравиться, но я буду говорить только за своих.
Немного о терминологии. В российской тусовке принято сокращать центры обработки данных как ЦОД. Это, конечно, правильно, но звучание такой аббревиатуры лично меня коробит. Сразу представляются ряды электронно-вычислительных машин (ЭВМ), заполняющие эти ЦОДы, и среднего возраста научные работники в очках и белых халатах с пачкой перфокарт в руках. Лично мне, как и всей команде, с которой я работал, больше по душе сокращение ДЦ – датацентр.
Остальные разъяснения будут появляться по мере необходимости непосредственно в тексте. Итак, приступаем…
Глава 1
Зоны ответственности команды эксплуатации
Прежде чем рассказывать о тонкостях эксплуатации датацентра, нужно ответить на два вопроса: когда и где начинается и заканчивается эксплуатация. Давайте разберем эти вопросы. Мы будем рассматривать пример абстрактной компании. В каждом конкретном случае имеет смысл составить такую же схему, чтобы визуально представлять, какие ресурсы и ограничения есть в работе и как их правильно использовать.
В повседневной жизни понятие «датацентр» может быть многозначным. Например, говоря о датацентре, ктото может иметь в виду юридическое лицо, оказывающее услуги по хранению и обработке данных. Другие могут представлять находящуюся в поле огороженную площадку, на которой расположены разнообразные здания. Третьи под датацентром понимают совокупность серверного и инженерного оборудования. Поэтому нужно хорошо понимать, в какой ситуации каким термином лучше оперировать. Например, в зависимости от того, идет речь о площадке или о юридическом лице, контактными лицами могут быть технический директор или генеральный директор компании.
Команда эксплуатации датацентров (Data Center Operations = DCOPS[3 - Data Center Operations.Выдуманный жаргонный термин, обозначающий команду эксплуатации инженерных систем датацентра. Как правило, эта же команда следит и за зданиями и сооружениями на площадке.]) в нашем примере обеспечивает функционирование всех трех ипостасей датацентра. Основная задача – обеспечение беспрерывного снабжения серверного оборудования ресурсами, то есть электричеством и охлажденным воздухом. Формальная граница между командой DCOPS и командой эксплуатации серверного оборудования может проходить по разъемам коробок отбора мощности на шинопроводах или разъемам кабелей питания, отходящих от главного распределительного щита.
Другие функции DCOPS: поддержание исправности инженерного оборудования, а также разнообразных процессов жизнедеятельности площадки – от функций генерального директора до заказа обедов для посетителей датацентра.
Команда эксплуатации серверного оборудования (IT Operations = ITOPS[4 - IT Operations. Как и DCOPS, выдуманный термин, описывающий специалистов по серверному и сетевому оборудованию.]) отвечает за работоспособность серверов, стоек и вспомогательного оборудования в стойках, кроссировку и т. п. Эта команда является точкой входа для заказчиков, поэтому именно в составе ITOPS имеет смысл организовать круглосуточную службу поддержки, которая будет принимать на себя все вопросы извне, связанные с работой датацентра, и координировать потоки информации внутри датацентра.
Команда сетевых подключений (Network Operations Center = NOC[5 - Network Operations Center. Центр сетевой связности объекта. В отрасли существуют и другие термины, по сути обозначающие то же самое: meet-me room, коммутационный центр и т. п. Может отличаться от FMR.]). Этот отдел может как быть частью команды внутри конкретного датацентра, так и ориентироваться на решение задач внешней связности. Обычно участие его сотрудников в ежедневной жизни датацентра ограничивается написанием правил, по которым заказчики подключаются к сети, и размещением собственного оборудования в специально выделенных помещениях и стойках.
Заказчики – могут быть как внешними, работа с которыми регламентируется контрактными обязательствами, так и внутренними, с которыми, с одной стороны, легче договориться, но с другой – их требования и пожелания часто превышают границы, которые внешний заказчик вряд ли бы перешел.
Существенные изменения в архитектуре и инженерных системах датацентра реализуются связкой отдела проектирования и проектного отдела (не следует их путать. На английском языке различие в их наименовании более очевидно: это Design Team и Project Team соответственно, но в русском может быть путаница).
Задача первых – разрабатывать решения, которые будут применяться в датацентре, а задача вторых – реализовать эти решения путем, непосредственно строительства объекта, а также его дальнейшей модернизации. Иногда, если проект не слишком большой, эта задача может быть решена и силами команды эксплуатации на площадке.
Отдел обеспечения безопасности имеет два направления: физическую безопасность и информационную. Физическая безопасность фокусируется на вопросах контроля доступа, видеонаблюдения и предотвращения физического убытка и в основном работает с командой DCOPS.
Подразделение информационной безопасности чаще взаимодействует с ITOPS и NOC – для разработки, внедрения и контроля выполнения правил подключения к сети компании и ограничений по трафику этой сети.
Финансовый отдел занимается бюджетированием и закупками необходимого оборудования для датацентров и работает в тесном контакте от начала проекта и после наладки готового объекта.
Логистика – команда, организующая прием, учет, хранение и перемещение материальных ценностей в датацентре, на складах и между ними.
Отдел кадров покрывает своей деятельностью всю компанию.
С точки зрения работы датацентра нас будут интересовать функции подразделений по подбору персонала, HR-аналитиков и административного управления.
Могут быть и есть другие отделы – продаж и технической поддержки продаж, маркетинга и др., которые также взаимодействуют с персоналом датацентра.
Разобравшись со структурой компании с точки зрения датацентра, нужно определить, кто из команды эксплуатации будет взаимодействовать с перечисленными коллегами. Эти роли нужно будет учесть при построении команды.
Ответив на вопрос «Где?», давайте разберемся с вопросом «Когда?». Представив жизненный цикл датацентра в виде последовательных прямоугольников, мы получим следующую картину:
Сначала компания, собирающаяся построить датацентр, составляет и анализирует бизнес-план проекта и производит поиск подходящей площадки.
Затем наступает долгий и мучительный (но интересный) период проектирования, по окончании которого заключаются контракты и производится закупка оборудования, после чего начинается строительство. Каждый из перечисленных этапов важен по-своему и требует вовлечения разного типа специалистов, но участие команды эксплуатации в этот период вряд ли принесет осязаемую выгоду.
По-настоящему команда эксплуатации берется за дело уже на этапе пусконаладочных работ (ПНР[6 - Пусконаладочные работы. Ответственный этап в строительстве датацентра, во время которого по частям и полностью проверяется пригодность построенного объекта к дальнейшей эксплуатации.]). Часто для проведения ПНР привлекается сторонний агент, иногда, что хуже, эту роль выполняет представитель проектировщика или подрядчика. На самом деле пусконаладка должна стать исходной точкой для построения качественной эксплуатации в дальнейшем. Поэтому ни одна сторона не справится с задачей лучше, чем собственная служба эксплуатации.
После завершения пусконаладки наступает самый длительный этап в жизни датацентра, в течение которого контролируется его работа и проводится регулярное техническое обслуживание.
Если произошел инцидент, при котором какой-либо компонент инженерных систем или здания вышел из строя, служба эксплуатации организует ремонтные работы. Если оборудование не подлежит ремонту, его демонтируют, списывают и заменяют. Когда объем заменяемого оборудования становится значительным, разумнее провести полную модернизацию. После ремонта или модернизации имеет смысл повторить пусконаладочные проверки, если есть такая возможность.
И наконец, при достижении датацентром срока его полезного использования проводится полный демонтаж оборудования и закрытие площадки. Практика показывает, что для этого также имеет смысл выделять специальную команду, что позволит провести разукомплектацию и разборку максимально безболезненно и быстро по возможности с сохранением какой-то остаточной стоимости разобранного оборудования.
Глава 2
Пусконаладка как часть эксплуатации
Всего несколько лет назад пусконаладка считалась кратковременным, проходным этапом в процессе строительства, а зачастую и вовсе игнорировалась. А как же иначе, если монтаж оборудования задерживается, стойки заказчика уже ждут, контракт горит? Давайте пока запустим как есть, потом доустановим недостающее и будем надеяться, что проектировщики нигде не ошиблись и все будет работать как надо.
У такого подхода есть огромное преимущество: кроме минимальных сроков ввода объекта, мы обеспечиваем службу эксплуатации интересной и захватывающей работой по поиску неисправностей и их срочному устранению в работающем датацентре на несколько лет вперед. Для тех же заказчиков, которые могли себе позволить потратить какое-то время на проверку смонтированных систем, сторонние организации, как правило, тестировали взаимодействие систем вентиляции и пожаротушения, а также все или самые основные переключения с города на ДГУ (дизель-генераторную установку)[7 - Большая, шумная и дымящая машина, предназначенная для генерации электричества из топлива в том случае, если электроэнергия по проводам больше не приходит.] и т. п.
Между тем зарубежный опыт привел к пониманию, что грамотно проведенная пусконаладка позволяет обнаружить и устранить подавляющее большинство неисправностей еще до подключения полезной нагрузки и следующие годы жить намного спокойнее. В мире существует несколько компаний, которые специализируются только на услугах пусконаладки (такой участник процесса называется Commissioning Agent[8 - Агент пусконаладки. Команда, берущая на себя бремя лидерства в процессе пусконаладочных работ.] – агент ПНР) и делают их на самом высоком уровне. Правда, услуги их совсем недешевы, и это еще одна из причин, почему многие заказчики стремятся сэкономить не только время, но и деньги, стараясь избежать полноценных пусконаладочных работ.
В то же время теоретические принципы проведения ПНР уже достаточно хорошо документированы и распространены, по крайней мере на Западе, и при осознании важности этого этапа и выделении ресурсов пусконаладку вполне возможно провести самостоятельно.
Есть несколько аргументов за то, чтобы ПНР проводилась собственной службой эксплуатации. Самыми главными я бы назвал два.
• За время подготовки и проведения пусконаладки будущие специалисты эксплуатации на своем опыте знакомятся со всеми единицами оборудования, их особенностями и ограничениями. Этот опыт в последующие годы будет просто бесценен, даже при наличии самой лучшей документации от поставщика. Кроме того, такие моменты, как постановка оборудования на учет и заполнение всех его данных в системе CMMS[9 - Computerized Maintenance Management System. Единая система, хранящая все аспекты эксплуатации объекта. Производители программного обеспечения с разным успехом приближаются к идеальному продукту, но окончательно достичь этой цели, по-видимому, невозможно.], также будут производиться вдумчиво и последовательно для каждой единицы оборудования.
• Все остальные претенденты на роль агента пусконаладки имеют свои собственные интересы, которые будут противоречить задачам дальнейшей многолетней эксплуатации. Так проектировщики, осо-знанно или нет, при обнаружении проектных ошибок не будут заинтересованы в их признании, говоря, что датацентр должен быть построен точно по их проекту. Подрядчики сделают все возможное, чтобы скрыть огрехи стройки, переложив ответственность либо на проектировщиков, либо на поставщиков, либо даже на заказчиков, которые чересчур строго давят на сроки и экономят бюджет. Формальный технадзор приносит много пользы, но, как правило, не до конца понимает сущность работы всего датацентра как единого целого, поэтому легко допускает ситуацию, когда «к пуговицам претензий нет, но костюм носить невозможно». Даже специально приглашенный агент ПНР чаще всего работает за деньги, поэтому воспринимает свою работу как продажу человеко-часов. Их вовлеченность, как правило, оформлена в виде консультационных услуг, поэтому вряд ли они станут защищать интересы клиентов сверх оговоренных рамок.
Другими словами, если не собственная команда эксплуатации – кто тогда?
Определение матрицы ответственных
Итак, никто не сможет провести пусконаладочные работы лучше специально подготовленного агента ПНР, которым эффективнее всего назначить команду эксплуатации этого датацентра, проведя специализированное обучение.
Наличие в проекте выделенного координатора для ПНР может привести к неожиданным отрицательным эффектам. Например, генеральный проектировщик может «обидеться» и начать слишком рьяно защищать идеи, заложенные им в проект, даже если это будет противоречить реальным интересам заказчика. Поставщики отдельных систем, наоборот, постараются самоустраниться из всех активностей по тестированию. В каждом конкретном случае рецепты решения таких ситуаций будут свои. Однако с самого начала имеет смысл не забывать упоминать на встречах и в контрактах об этапе пусконаладки, чтобы подрядчики сразу поняли важность и неизбежность этого этапа строительства.
Отличную службу здесь может сослужить… PMBOK[10 - Project Management Body of Knowledge. Культовая книга руководителей проектов из любой отрасли, наподобие той, которую вы сейчас держите в руках. Рассказывает о всех тонкостях профессии.] – библия проектного управления, в свежих изданиях которой инструменты управления проектами доведены практически до совершенства. Если проектом строительства датацентра занимается прожженный профи, то он в самом начале составит действующий, а не формальный устав проекта, в котором подробно расскажет о назначении, этапах, сроках и участниках ПНР. Например, скопировав все из этой книги. Но даже начинающий руководитель проекта может сделать необходимый минимум – создать матрицу ответственности специально для этапа пусконаладки.
В идеальном случае эта матрица должна попасть приложением в контракты участников проекта.
Ниже я приведу пример такой матрицы в немного упрощенном виде, насколько позволяет формат книги. На практике лучше распечатать ее на большом листе. Такая матрица должна содержать:
• перечисление всех этапов ПНР в текущем проекте;
• перечисление всех участников ПНР;
• контакты реальных представителей каждого из участников с учетом этапа ПНР. Например, для проведения FAT[11 - Factory Acceptance Test. Производственная проверка оборудования перед отправкой заказчику.] (factory acceptance test) и SAT[12 - Site Acceptance Test. Функцональные испытания отдельно взятой системы или оборудования.] (site acceptance test) это могут быть разные люди;
