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

Алексей Жумыкин

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

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

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

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

Глава 1

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

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

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

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

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

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

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

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

Существенные изменения в архитектуре и инженерных системах датацентра реализуются связкой отдела проектирования и проектного отдела (не следует их путать. На английском языке различие в их наименовании более очевидно: это 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 – вехах). Мне довелось несколько раз участвовать в полноценных проектах пусконаладки, и опытным путем мы с коллегами пришли к выводу, что в реальной жизни нужно добавлять еще два: один в начале классической модели и один в конце. Ниже перечислим все эти вехи, при этом я приведу также и их английские наименования. Это может быть полезно при дальнейшем изучении вопроса на англоязычных сайтах.

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

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

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

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