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

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

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

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

 

Я был приятно удивлен, что идеи автора весьма созвучны стандарту эксплуатации датацентров 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

 

ПУСКОНАЛАДКА КАК ЧАСТЬ ЭКСПЛУАТАЦИИ

 

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

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

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