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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда эксплуатации датацентров (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]). Часто для проведения ПНР привлекается сторонний агент, иногда, что хуже, эту роль выполняет представитель проектировщика или подрядчика. На самом деле пусконаладка должна стать исходной точкой для построения качественной эксплуатации в дальнейшем. Поэтому ни одна сторона не справится с задачей лучше, чем собственная служба эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On-the-job Training – OJT[21]. Часть рекомендуемого обучения, представляющая собой лекции специалистов по эксплуатации систем, установленных в датацентрах, правилам поведения и т. п. Хорошо, когда такие лекции читают опытные сотрудники датацентров, рассказывая о работе на основании своих знаний и опыта. На этих лекциях особое внимание нужно уделить объяснению принципов работы оборудования, его основных характеристик, режимов работы, подходов к техническому обслуживанию и базовых правил устранения неисправностей. Разумеется, на каждой площадке перечень таких обучений будет уникальным. В качестве примера можно упомянуть следующие:

• высоковольтная подстанция;

• оборудование среднего напряжения;

• оборудование низкого напряжения и однолинейная схема площадки;

• дизель-генераторные установки;

• топливная система;

• источники бесперебойного питания;

• системы заземления и молниезащиты;

• классические кондиционеры;

• приточные и вытяжные вентиляционные установки;

• системы водоснабжения, водоочистки, канализации;

• лифты, подъемные механизмы;

• системы пожарной сигнализации, пожаротушения и пожарного оповещения;

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

• система мониторинга;

• хранение в датацентре и работа со складом;

• работа с IT-инструментами;

• работа по процессам компании.

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

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

Дополнительное. Сюда относятся курсы по темам, не связанным напрямую с профессиональной деятельностью сотрудника. Это хорошая возможность усовершенствовать свои навыки в другой, не профессиональной сфере. Примеров такого обучения можно привести огромное множество, начиная от курсов Excel и C++ и заканчивая подготовкой презентаций и основ управления строительными проектами. Одобрение оплаты такого обучения рассматривается руководителем. По умолчанию это обучение добровольное, поэтому проводится в личное время сотрудника и не считается выходом на работу.

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

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

О – обязательное

Д – дополнительное

П – полезное

Р – рекомендуемое

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

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

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

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

В заключение этой главы можно процитировать Джека Уэлча (CEO General Electric). На вопрос: «Вы не боитесь, что вы их обучите, а они уйдут?» – он ответил: «Боюсь, конечно. Но я еще больше боюсь, что я их не обучу, а они останутся».

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

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

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

Какой-то инструмент был учтен и приписан к определенным сотрудникам, а другой просто лежал где попало и находился с трудом.

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

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

Приобретаемый инструмент делится на четыре большие группы:

• персональный инструмент;

• инструмент общего назначения;

• инструмент специального назначения по подсистеме;

• инструмент специального назначения по оборудованию.

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

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

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

Как показала практика, классический бумажный журнал учета инструмента значительно проигрывает электронному, так как из-за длительности заполнения сотрудники начинают лениться и не заносят в него то, что они «возьмут на минуточку». Совсем скоро отслеживать наличие станет уже затруднительно.

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

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

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

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

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

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

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

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

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

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

Постановка на учет оборудования – вопрос совсем не простой и имеющий несколько аспектов. Поэтому разберем его подробно и обстоятельно.

Итак, начнем с того, что при проектировании датацентра мы закладываем в его функциональные схемы некоторые узлы: «черные ящики», выполняющие вполне понятную конечную функцию. Например, источник бесперебойного питания. На этом этапе нам достаточно знать его проектное наименование, а для того чтобы в этом была какая-то логика, разрабатывают отдельный документ о правилах наименования (naming convention), позволяющий разобраться в замысловатом коде проектировщиков. Впрочем, проектное наименование не будет нас сильно волновать: в последующие годы команда эксплуатации будет использовать его очень редко.

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

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

– Добрый день, мне нужны транзисторы.

– Очень хорошо, какие именно?

Женщина достает сложенный листок бумаги, сверяется с ним и говорит:

– VT1 и VT2.

Справедливости ради отметим, что в проектной документации стадии РД[22] все поставляемые подрядчиком блоки должны иметь проектные коды, поэтому отличие проекта от реальной поставки в части количества единиц должно быть невелико.

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

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

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

Те покупки, которые не соответствуют выбранным критериям, финансисты называют пренебрежительно «нематериальное» или «малоценка» и сразу же списывают, уменьшая налогооблагаемую базу и не ставя на учет. Финансистов дальнейшая судьба этих приобретений не интересует. А команду эксплуатации даже очень! Помните: «не было подковы – лошадь захромала…»? Мы говорим о запасных частях и расходных материалах. Хотя они и не интересны бухгалтерии, учитывать их нужно так называемым количественным учетом. То есть выбрать для каждой разновидности запчастей некое название (будем называть его «номенклатурный код»), надписать это название на коробке, так как оно будет общим для всех единиц в этой коробке, и считать, сколько их там осталось. В основном задача учета перекладывается на ответственных за хранение: кладовщиков, логистов и т. д.

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

Итак, мы получили три созданные нами базы данных:

• база инвентарных номеров;

• база инженерных кодов;

• база номенклатурных кодов.

И два справочных списка, которые в базы данных объединять не обязательно:

• список проектных наименований;

• список артикулов производителя.

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

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

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

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

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

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

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

В чем могут быть достоинства такой схемы?

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

2. Увеличивается гибкость в случае, если необходимо реорганизовать структуру оборудования, например в CMMS. Это вызвано тем, что поставленное на бухгалтерский учет почти навсегда «прибито гвоздями», и в случае ошибки или излишнего дробления системы исправить что-то будет почти невозможно.

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

Однако все эти достоинства как минимум уравновешиваются контраргументами, а именно:

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Первым делом для определения предполагаемого срока полезного использования (СПИ[24]) следует обратиться к документации производителя. Часто, особенно для типового оборудования, этот срок прямо указан в инструкции по эксплуатации. Однако следует обратить внимание на условия эксплуатации, указанные производителем. Например, обычный кондиционер может иметь срок полезного использования 10 лет, определенный производителем при ежедневной работе не более восьми часов, что вполне резонно для офисного применения. Если же мы установим этот кондиционер для круглосуточной работы в маленький машинный зал, ожидать от него десятилетней службы наивно. В этом случае можно перейти к пункту 3 ниже.

2. Если в переданной документации нет никакого упоминания о сроках использования, можно написать вежливое письмо производителю с запросом рекомендуемого СПИ, объяснив ситуацию. Такой способ помогает редко, но все же иногда помогает.

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

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

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

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

Теперь давайте разберем способы списания оборудования с учета.

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

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

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

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

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

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

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

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

Какая информация может содержаться в карточке?

• Краткое наименование запчасти.

• Номенклатурный код.

• Название производителя (или продавца) и артикул.

• Альтернативные производители и артикулы.

• Фотография детали.

• Список оборудования, для которого деталь применима.

• Габариты и вес детали (опционально).

• Последняя стоимость приобретения детали (опционально).

Как видно, все поля не нуждаются в комментариях. При возможности интеграции СУЗ с программой складского учета можно импортировать следующие поля:

• наличие и количество на складе;

• место хранения;

• минимально допустимый остаток;

• рекомендуемый размер партии для приобретения;

• количество единиц в упаковке (опционально).

Если такой интеграции нет, то пользователь СУЗ должен по меньшей мере иметь доступ к программе складского учета, откуда он сможет получить эти данные.

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

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

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

Анализируя все закупки за прошедшие периоды, мы получаем точные данные о потреблении запчастей и расходников и можем сделать вывод, например, об актуальной переменной части общей стоимости владения (Total Cost of Ownership – TCO) и о распределении затрат уже по подсистемам, а не из маркетинговых расчетов, поняв таким образом, во что обходится эксплуатация того или иного оборудования датацентра. Именно так интересно сравнить реальную стоимость обслуживания разных типов ИБП.

Следующим шагом может стать долгосрочное планирование потребления запчастей и расходных материалов. Для этого в каждом наряде на техническое обслуживание в CMMS должны быть указаны используемые запчасти и нормы их расхода. Очевидно, что при составлении плана ТО[25] на следующий год можно будет без особого труда составить график потребления «расходки» как по датам, так и по требуемому количеству. Наложив такой прогноз на отчет по состоянию склада, мы сможем точнее планировать закупку и поставку запчастей. А также, что немаловажно, проверять перед началом ТО, есть ли необходимое количество запчастей в наличии. А это, знаете ли, уже готовая ERP-система[26]!

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

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

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

У такого подхода есть, пожалуй, только один недостаток. Часто бюджет строительства начинает «перетрачиваться» уже с самого начала, и проектная команда может использовать средства, зарезервированные на закупку ЗИП, для латания дыр бюджета проекта, подразумевая, что команда эксплуатации все равно потом купит то, что ей будет необходимо. Это правда. Только, скажем так, это некрасиво – перекладывать свои «перетраты» на коллег. Чтобы подобной ситуации не происходило, можно выделять в тендере стоимость расходников и ЗИП в отдельную сумму и при первой же возможности учитывать ее при пересмотре бюджета эксплуатации.

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

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

• построение плановой работы по обслуживанию оборудования;

• отработка инцидентов;

• аудиты и работа с проектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для календарного обслуживания нужно сосредоточиться на ежедневном техническом обслуживании, еженедельном, ежемесячном и т. д. Наиболее удобным наименованием таких видов контроля мне кажется указание дней между соседними ТО – и коротко, и наглядно. Например: ТО1, ТО7, ТО30, ТО120 и т. д. Для ТО по состоянию теоретически можно использовать тот же формат, но в нем будет легче запутаться, так как в примере выше это всегда дни, а в случае оценки состояния это могут быть моточасы, киловатт-часы, тонны и т. п.

Второй способ разделения – по квалификации. Это разделение также будет разбираться ниже, в главе, посвященной ответу на вопрос «Делать самим или позвать подрядчика?». Три основные группы работ: выполнение силами дежурных (например, очистка от пыли), выполнение силами собственной группы ТО и выполнение силами подрядчика. С точки зрения календарного планирования второй способ разделения не имеет большого значения, за исключением денежного вопроса, о котором чуть ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заполнить оперативный отчет об инциденте. В отличие от предыдущего способа коммуникации, когда важно максимально быстро передать минимальное количество информации, необходимое коллегам из других отделов для их работы, следующим шагом дежурный должен собрать как можно больше информации о текущем состоянии объекта и системы, на которой произошла неисправность. Эта информация понадобится для дальнейшего разбора случившегося. Проще всего такой сбор осуществлять с помощью заранее подготовленной формы с вопросами, на которые дежурный должен ответить, приложив релевантную информацию. Такая форма, например, может сразу направляться письмом на рассылку всех вовлеченных специалистов, а также создавать тикет для разбора всех подробностей инцидента – то, что обычно в мире называют Root Cause Analysis (RCA[28]).

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

• Из-за чего произошел инцидент?

• Что было сделано / нужно сделать, чтобы устранить последствия этого инцидента?

• Что нужно сделать, чтобы подобный инцидент не повторялся в дальнейшем?

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

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

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

Кроме уже перечисленных отчетов по каждому RCA отмечу следующий статистический уровень: сколько инцидентов случилось в период, на каких площадках и на каких системах. Такая статистика может, например, показать, что у нас подавляющее число проблем происходит с ИБП. В таком случае можно поставить вопрос о замене ИБП на более надежную модель либо, если замена не вариант, о наращивании компетенции в обслуживании и ремонте.

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

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

Причины, по которым следует что-то менять, почти всегда появляются из какого-то уже заранее известного источника. Например, такими источниками могут быть:

• регулярный эксплуатационный аудит (внутренний или внешний);

• аудит состояния сооружений и территории (строительный);

• аудит пожарной безопасности объекта;

• аудит физической безопасности;

• внешние аудиты заказчиков и специальные (PCI DSS[29] и т. п.);

• инвентаризация;

• реестр инцидентов за прошедший период;

• окончание срока полезного использования оборудования;

• запросы на развитие (например, переход на новые типы ИБП);

• введение нового процесса в отделе.

Наладить сбор информации довольно просто: для начала достаточно составить регулярный календарь по каждому из аудитов и определить окна поступления информации по другим источникам, если это возможно. За аудит должен быть назначен ответственный, который готовит программу и координирует организационную часть. Важно понять, что после каждого аудита обязательно необходима итоговая встреча, на которой не только обсуждается перечень несоответствий и замечаний (для которых есть такой интересный термин, как near-miss[30]), но и обязательно утверждается план дальнейших действий с указанием ответственных и сроков. Вот этот отчет с пларом действий и становится входным документом для проектов.

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

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

• стадия, на которой сейчас находится проект;

• возникшие новые обстоятельства (опционально);

• план по срокам (укладываемся в прогноз или меняем что-то);

• план по бюджету (включая распределение затрат по кварталам);

• следующий шаг и контрольная точка – для синхронизации на следующих встречах.

Для поддержания исторических данных выполненные проекты удалять не следует – лучше переводить их в состояние «завершен» и скрывать для регулярного обозрения.

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

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

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

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

Итого, в общем случае процесс управления проектами может быть описан так:

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

Этапы:

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

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

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

• Проектирование. Если для достижения результата требуется привлечение проектной команды.

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

• Реализация. Основная часть проекта.

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

• Закрытие. Перевод проекта в архив.

Параметры:

• дата создания;

• источник изменения;

• принадлежность к подсистеме;

• локация (если процесс работает на несколько площадок);

• ответственный;

• бюджетная оценка по периодам и фактические данные;

• плановый (первоначальный) срок завершения;

• текущая оценка срока завершения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторое время назад весь спектр таких инструментов широко обсуждался под аббревиатурой DCIM – Data Center Infrastructure Management[31], и большинство ведущих игроков рынка попыталось представить свою концепцию единого информационного поля. Однако общего понимания того, что имеется в виду под DCIM, нет до сих пор, поэтому все концепции расползлись по разным углам, в разных продуктах акцент сделан на ту область, которая именно этим производителем считается ключевой. Где-то это кабельный журнал, у кого-то круговые диаграммы с PUE[32], кто-то лучше других управляет нарядами на работы, а где-то учитываются в трехмерных графиках токи с каждого автомата. Поэтому решения получились несравнимые по функционалу, и выбрать что-то одно просто невозможно.

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

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

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

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

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

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

Для простоты восприятия давайте определим, что система мониторинга – это светофор, имеющий три сигнала:

• красный – необходимо встать со стула и что-то предпринять;

• желтый – установлено пристальное наблюдение;

• зеленый – все работает штатно.

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

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

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

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

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

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

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

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

Таким образом, структурная схема решения может выглядеть примерно так:

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

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

Наиболее плодотворной для использования в датацентре концепцией является применение компьютеризированной системы управления обслуживанием (Computerized Maintenance Management System – CMMS). На самом деле эта система применима для любого другого объекта, и не обязательно промышленного. Например, гостиницы и даже некоторые жилые дома управляются с помощью такого же программного обеспечения. Любознательный специалист по эксплуатации может даже собрать из подручных электронных таблиц и календаря домашнюю версию для квартиры или загородного хозяйства, чтобы лучше разобраться в тонкостях работы.

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

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

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

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

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

Существует два взгляда на учет: финансовый и эксплуатационный.

Как правило, финансовый более подробный, но пользоваться им в реальной жизни неудобно. Поэтому при построении базы данных в CMMS необходимо импортировать из ERP-системы (или карточек учета ОС-6) информацию только о тех единицах оборудования, которые можно рассматривать как обслуживаемую единицу.

Для некоторых систем, например освещения, есть смысл принимать на учет не каждый светильник по отдельности, а завести «система освещения – 1 штука». Это никак не повредит задаче анализа затрат как денежных, так и трудовых ресурсов.

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

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

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

• номенклатурная позиция (из системы финансового учета);

• инженерный код (как оборудование поименовано в проекте);

• серийный номер;

• расположение (в каком помещении установлено);

• принадлежность к системе и подсистеме;

• ответственный за эксплуатацию;

• статус оборудования (в работе, в ремонте и т. д.);

• ссылки на документы по пусконаладке;

• ссылки на исполнительную документацию;

• ссылки на эксплуатационную документацию (инструкции, чек-листы, процессы);

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

• основные даты жизненного цикла оборудования;

• дата окончания гарантии;

• дата вывода из эксплуатации (срок полезного использования);

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

• ссылки на зарегистрированные инциденты с оборудованием;

• ссылки на запланированные в будущем наряды;

• перечень тренингов, необходимых для работы на оборудовании.

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

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

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

Для выполнения работ по оборудованию, несомненно, понадобятся запасные части и расходные материалы, которые необходимо также указывать в наряде. Базу данных по этим запчастям предпочтительно интегрировать с программой управления складом (WMS – Warehouse Management System), чтобы автоматически отслеживать количество на складе и чтобы в случае достижения неснижаемого остатка система могла автоматически отправлять в закупки запрос на приобретение требуемого количества запчастей. Используя совместно план производства работ на следующий год и исторические данные о потребленном количестве запчастей, мы можем достаточно точно спрогнозировать потребление и расходы для бюджета.

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

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

Собственно проведение всех работ в датацентре строится на процессе планирования и примыкающему к нему календарному плану проведения регламентных работ.

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

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

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

Очень часто проводить работы по техническому обслуживанию основных систем датацентра следует с оглядкой на влияние оборудования на IT-нагрузку. Если такое влияние есть, работы придется согласовывать. Алгоритм согласования работ может быть разным в зависимости от компании, и в нашем примере он скрывается в процессе «управление изменениями». Из-за своей важности этот процесс, как правило, тщательно алгоритмизирован. Поэтому со стороны эксплуатации может понадобиться подключение процедуры LOTO (Lock Out Tag Out), которую также можно отразить в CMMS.

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

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

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

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

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

Суммируя все сказанное выше, видно, что основной, стержневой сущностью CMMS является наряд на работы (Work Order).

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

• идентификатор наряда;

• заголовок наряда;

• описание работы, которую требуется выполнить;

• инициатор наряда, исполнитель и наблюдатели;

• ссылки на инженерное оборудование, на котором планируется проводить работы;

• влияние работ в наряде на IT-оборудование;

• статус одобрения наряда;

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

• исходные шаблоны чек-листов, форм отчетов и т. п.;

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

• перечень необходимых для выполнения работ инструментов;

• запасные части и расходные материалы, требуемые в процессе работ;

• дополнительная документация, связанная с выполнением работ, например сделанные фотографии;

• время, затраченное на выполнение работ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Определить ограничивающие факторы.

2. Выяснить причины ограничений и определить максимально доступные значения каждого фактора.

3. Выяснить реальные значения потреблений.

4. Разработать схемы нормальной работы всего датацентра в целом.

5. Установить пристальное наблюдение.

6. Договориться о частоте и глубине пересмотра выбранных значений и планов.

7. Разработать план действий для каждой нестандартной ситуации.

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

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

Количество стойко-мест может быть самым простым для анализа, однако не стоит забывать об особенностях каждой стойки. Стойки могут быть шириной 80 или 60 см, и поэтому на одной и той же площади можно поставить как 30, так и 40 стоек (и даже любое промежуточное число). Для такого случая нужно делать расчет доступной площади в узких, 60-сантиметровых стойках, а одну широкую считать как 1⅓ от базовой. Такая абстракция дает хорошее приближение, единственное, стоит помнить о наличии соответствующего количества блоков на шинопроводе.

Для определения ограничений по электрической мощности необходимо будет рассмотреть однолинейную схему и понять совокупность всех ее ограничений. Например, рассмотрим схему, состоящую из одного трансформатора, трех ИБП, включенных по схеме N+1, распределительного щита, от которого отходит четыре шинопровода, на каждый из них можно установить 25 отводных блоков с допустимым током 32 А на каждый.

Если смотреть на схему с точки зрения отводных блоков, то кажется, что можно подключить суммарную нагрузку током 32 х 25 = 800 А, что дает нам 3200 А на серверную. Однако, посмотрев на номинал автоматов ГРЩ, мы увидим, что ток через каждый шинопровод ограничен величиной 600 А (например, потому, что мы выбрали стандартные шинопроводы номиналом в 630 А). Таким образом, мы уже уменьшаем доступный ток до 2400 А. Наш трансформатор может быть выбран с небольшим запасом и спокойно держать нагрузку только в 2000 А, так что это станет следующей итерацией ограничений. Но окончательный лимит мы узнаем, поняв, что каждый из ИБП способен держать только 600 А, что дает нам ограничение по максимально доступной мощности в 1800 А. Эта величина и будет для нас определяющим фактором при расчете допустимого электрического тока на серверную.

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

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

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

Как отмечалось выше, стойка шириной 60 см будет занимать одно стойко-место шириной 60 см, а стойка шириной 80 см – 1⅓ такого места. Выдумывать что-либо хитрее, наверное, бессмысленно. Давайте представим выдуманный график, на котором совместим планы строительства датацентра и план его заполнения с точки зрения стойко-мест.

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

В августе в эксплуатацию вводится еще 300 стойко-мест (следующий скачок красной линии – теперь доступна 1000) и продолжается заполнение серверной стойками заказчиков. К концу года все доступные серверные площади датацентра заполнены на 90 %.

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

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

Чтобы построить такой же баланс по электрической мощности, прежде всего необходимо понять, сколько на самом деле потребляет сервер или стойка, в зависимости от того, что является минимальным квантом. Допустим, что над стойками проложен трехфазный шинопровод, на котором установлены отводные блоки с автоматами на 32 А. Это дает нам 22 кВт мощности на стойку, если все фазы сбалансированы. Если стойка высотой в 52 юнита, то на каждый из них получается около 424 Вт.

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

Есть еще один способ, более выгодный экономически, но несущий в себе дополнительные риски. Он заключается в том, что за конкретным типом стойки или сервера устанавливается пристальное наблюдение и его энергопотребление постоянно фиксируется. Затем мы фиксируем пиковое значение энергопотребления, скажем за месяц или за полугодие, и принимаем его за максимальное потребление сервера в реальных условиях. Понятно, что сервер может полгода находиться в режиме stand-by, а затем внезапно включиться в режиме высокой загрузки ЦПУ, тем самым превысив статистический максимум. Поэтому принятие решения о применении такого способа расчета должно быть несколько раз обдумано и, по возможности, согласовано с заказчиком. Такой расчет крайне не рекомендуется в гомогенной среде, где, например, весь машинный зал заполнен одинаковыми серверами одного заказчика.

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

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

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

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

На таком графике имеет смысл выделить следующие линии:

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

Значение ресурса с резервированием. Линия оранжевого цвета показывает, сколько у нас есть электричества, обеспечивающего проектный уровень резервирования. В этом месте стоит упомянуть о двусмысленности термина «резерв», что часто приводит к путанице в обсуждении. Нужно четко понимать, что выключение всех резервных единиц инженерного оборудования фактически превратит эту линию в «максимальное значение ресурса». Таким образом, линию можно равноценно назвать как работой с резервированием, так и работой без резервирования – смотря с какой стороны подойти. Чтобы избежать этой двусмысленности, лучше назвать эту линию целевой, так как приближение к ней показывает наиболее эффективное использование ресурсов при сохранении требуемой надежности. Или использовать английский термин warning, так как пересечение этой линии не сразу сказывается на работе IT-оборудования, но повышает риск при любом отказе инженерии.

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

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

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

Теперь пора понять, как определить уровень резервирования (или целевую линию). Для примера вернемся к уже рассмотренной схеме распределения электроэнергии.

Как мы описали выше, максимальный ток для расчета допустимой мощности определяется током через сборку ИБП и составляет 1800 А или примерно 1,25 МВт. На графике это значение будет обозначено красной линией. В случае если мы захотим вывести из эксплуатации один блок сборки ИБП для ремонта или технического обслуживания, то мы будем способны поддерживать ток в 1200 А или примерно 830 кВт – это и будет оранжевая линия на графике.

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

1. Погрешность установки автоматов.

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

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

Достаточная величина такого резервирования может находиться уже в пределах 95 % от максимального значения, что гораздо лучше, чем 33 %, определенные по предыдущему методу.

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Зеленая линия выше оранжевой (аллокация мощностей выше целевого значения). Такая ситуация может случаться сплошь и рядом и на самом деле не является по-настоящему критической.

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

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

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

3. Голубая линия выше оранжевой (реальное потребление выше целевого значения). Ситуация, очень похожая на предыдущую, с одним отличием: в прошлый раз работа без резервирования могла произойти, а теперь точно произошла. В таком случае обязателен запрет на проведение любых манипуляций с оборудованием, которые могут привести к снижению резервирования, а также незамедлительное информирование IT-специалистов для срочного планирования разгрузки мощностей.

4. На следующем примере зеленая линия находится выше красной (планируемое потребление выше максимальной возможности датацентра).

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

5. Голубая линия выше красной (реальное потребление выше максимальной возможности датацентра). Из всех представленных случаев этот – самый катастрофический.

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

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

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

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

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

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

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

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

Для большей наглядности давайте разберем пример. Допустим, у нас есть датацентр с выделенной электрической мощностью 1100 кВт, из которых 1000 кВт отдается IT-оборудованию, а 100 кВт – системе охлаждения (на вентиляторах). Проектная стойка, устанавливаемая в этот датацентр, имела потребление воздуха в 2500 м³/ч, что в сумме на весь модуль дает 250 000 м³/ч. То есть в проекте вентустановки производительностью 250 000 м³/ч будут потреблять по проекту 100 кВт·ч. При реальном заполнении зала были установлены 99 стоек с максимальным потреблением каждой 10 кВт·ч и 2000 м³/ч. Таким образом, максимальное потребление воздуха не превысит 198 000 м³/ч. Это будет выглядеть на графике управления ресурсами следующим образом (для простоты объяснения мы уберем из рассмотрения концепцию целевого значения и не будем показывать реальные значения):

Этот график показывает, что ресурсы системы охлаждения у нас загружены лишь на 80 %, в то время как ресурсы электроснабжения используются полностью. Но, зная, что установленное количество стоек не будет потреблять больше чем 200 000 м/ч, мы можем сознательно снизить максимальное потребление воздуха в зале, например на 80 % – до 210 000 м³/ч.

В этом случае производительность вентиляторов составит (210/250) × 100 % = 84 %, а электропотребление вентустановок не будет превышать (84 %)³= 59,2 %. Таким образом, из зарезервированных 100 кВт мощности мы со спокойной душой можем отдать 40,8 кВт на другие цели. Например, на питание тех же стоек. В этом случае итоговое заполнение по воздуху составит 198/210 = 94 %, а по электричеству – 990/1041 = 95 %. Согласитесь, намного лучше, чем исходные 80 и 99 %. К тому же в результате такого перераспределения у нас появилась возможность поставить дополнительные четыре стойки.

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

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

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

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

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

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

Следующим шагом можно спрогнозировать температуру воздуха в холодном коридоре на протяжении года. Например, в зимнее время условимся подавать воздух температурой +20 ℃ в режиме рециркуляции, а в летнее – ориентироваться на среднее значение за месяц ±5 ℃. Из такого прогноза и полученных экспериментальных кривых можно завести в систему управления ресурсами то, как будет изменяться аллокация в зависимости от времени года. Так мы получим дополнительные мощности как по электричеству, так и по воздуху в более холодное время года. Практическая польза в этом зимнем запасе может быть в случае, когда как раз в зимнее время не будет хватать мощностей для размещения десятка-другого стоек из-за неготовности следующего датацентра, запуск которого назначен только на март.

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

Еще один интересный способ автоматизации, к тому же сравнительно легко реализуемый, состоит в объединении функционала нескольких информационных систем службы эксплуатации в единый инструмент. А именно мы говорим о двух случаях. Во-первых, можно синхронизировать состояние оборудования в CMMS с максимальным и целевым значениями ресурсов. Например, если мы планируем долгосрочное выведение из эксплуатации одного из пяти ДРИБП[34], скажем для проведения капитального ремонта, мы создаем в CMMS наряд, где будет указано плановое время отключения (недоступности) этой единицы оборудования, что приведет к снижению линии максимально доступной и целевой электрической мощности. Понятно, что для кратковременных, выполняемых в течение дня-двух нарядов это может быть излишним, но для работ длительностью от недели такая корректировка может оказаться полезной.

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

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

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

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

Чаще всего в компаниях применяют два подхода к бюджетированию: «сверху вниз» и «снизу вверх».

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

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

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

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

В бюджете «снизу вверх» стоит использовать признак обязательности для каждой строки, например устоявшиеся английские слова must-have (обязательно) и nice-to-have (желательно). Это поможет в ситуации, когда держатель бюджета обоснованно попросит уменьшить общую сумму, скажем на 5 %, и можно будет, быстро отфильтровав строки «желательно», посмотреть, от каких расходов можно сравнительно безболезненно отказаться.

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

Самым эффективным подходом к бюджетированию я считаю третий. Условно я назвал его ABC, от английского activity-based costing, хотя изначально такой метод применяется в других условиях.

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

Для обычного технического специалиста погружение в тонкости перераспределения затрат к капитальным (CapEx[35]) или операционным (OpEx[36]) сродни приобщению к религиозному течению: понять невозможно, нужно просто поверить и заучить.

Абсолютно строгих критериев отнесения затрат к капитальным не существует. Но среди важных можно назвать следующие параметры.

• Имеют ли расходы разовый характер или регулярный.

• Стоимостная характеристика (в российском учете).

• Направлены ли затраты на получение прибыли.

• Срок использования более одного года.

• Расходы улучшают качественные характеристики активов и т. д.

Окончательный вердикт о правилах отнесения затрат следует получить от финансистов. Это как раз тот случай, когда лучше лишний раз переспросить.

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

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

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

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

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

Энергоресурсы. Это самая главная часть бюджета современного датацентра. Для некоторых площадок она может составлять до 80 % от всего бюджета и даже более, поэтому требует внимания и аккуратности при планировании. При таком соотношении погрешность в 1 % при оценке энергопотребления равнозначна 4 % от остального бюджета. То есть, ошибившись на 1 % в потреблении, мы можем полностью лишить себя зарезервированных денег, например на спецодежду и обучение.

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

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

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

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

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

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

Физическая безопасность. Я вынес эти затраты в отдельную группу, потому что выглядит логичным передать их из отдела эксплуатации в службу безопасности компании. Таким образом и бюджетирование будет производиться там. Если все же за безопасностью следит эксплуатация, эти затраты можно оставить отдельной группой, а можно распределить по другим, например поместив договор с охранным предприятием в «Договоры», а запасные считыватели СКУД – в ЗИП.

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

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

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

• площадь датацентра (для простоты возьмем площадь машинных залов);

• количество стоек;

• энергопотребление всех стоек;

• количество единиц инженерного оборудования в штуках;

• количество дежурных инженеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте представим получившиеся у нас примеры связок в виде таблицы.

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

На следующем шаге мы введем в рассмотрение стоимость каждого фактора и ее изменение, тем самым завершив построение АВС-модели.

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

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

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

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

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

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

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

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

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

Последним шагом для получения бюджета нужно объединить все данные в общую таблицу – и бюджет готов!

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

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

• наблюдение за системой мониторинга;

• обходы;

• организация работ подрядчиков;

• выполнение простого технического обслуживания;

• участие в пусконаладочных работах;

• административные задачи;

• обучение;

• прочие задачи.

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

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

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

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

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

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

Например, определив, что стоимость проекта по обновению помещения для хранения документации будет состоять из покраски стен, перекладки потолка и замены стеллажей и на весь проект должно хватить 1 000 000 руб., можно оценить соотношение CapEx и OpEx как 40/60 и на капитальные затраты заложить 400 000 руб., а на операционные расходы – 600 000 руб.

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

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

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

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

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

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

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

• внешний периметр (от забора до стен);

• гости (общие помещения);

• эксплуатация здания и инженерных систем;

• эксплуатация серверных помещений;

• склады.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Система видеонаблюдения, как правило, получается совсем не дешевой, особенно при желании службы безопасности обеспечить 200 %-е покрытие каждой точки помещения. Лучше в очередной раз спросить себя, какая именно задача решается каждой из камер. Тут имеет смысл не изобретать одну формулу на весь объект, а последовательно рассмотреть помещение за помещением. На складах важно тщательно наблюдать за тем, чтó сотрудник вносит и выносит, но не отслеживать перемещения внутри склада. А вот в случае IT-оборудования имеет смысл внимательно смотреть за любыми действиями посетителей и сотрудников в непосредственной близости от стоек.

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

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

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

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

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

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

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

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

Имеет смысл показать на примере, на какие принципы разделения тем стоит обратить внимание.

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

Итак, рассмотрим пример.

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

Какую платформу выбрать для хранения электронных копий документов? Для ответа на этот вопрос стоит задуматься над следующими вещами.

1. Большая часть информации, скорее всего, будет использоваться в режиме только для чтения с редкими случаями обновления документов. И лишь к некоторым файлам, таким как бюджеты и отчеты, будет требоваться одновременный доступ на редактирование. Поэтому можно задуматься о хранении основной массы файлов на простом FTP-сервере или в подобной сетевой папке, а некоторые документы разместить в инструменты наподобие Microsoft Teams или Google Docs, позволяющие совместное редактирование. Однако стоит заранее тщательно изучить особенности выбранной платформы, так как может оказаться, что практическая реализация будет иметь такие недостатки, что пользователи просто не захотят в ней работать. В качестве примера расскажу, что одна из подобных платформ при доступе к файлу загружалась более трех минут. Конечно, раз в год можно и потерпеть, но очевидно, что регулярно пользоваться такой системой никто не захочет.

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

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

4. Что касается резервирования – тут я целиком доверяюсь IT-специалистам. Они точно смогут выбрать метод дублирования серверов лучше инженеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, за что же можно награждать премией. Приведем несколько примеров.

1. За тщательное документирование работ в нарядах CMMS.

2. За выполнение SLA по тикетам соседних отделов.

3. За выполнение дополнительных поручений руководителя.

4. За повышенное внимание к состоянию площадки и оборудования, выражающееся в обнаружении проблем, мимо которых остальные все время проходили.

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

6. За достойное поведение при устранении инцидента, если таковой случился.

С другой стороны, стоит упомянуть, за что не нужно награждать персональной премией.

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

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

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

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

1. Поддержание уровня обученности специалистов.

2. Выявление областей, в которых требуется образовательная работа от руководителей.

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

4. Сравнительно справедливый механизм распределения премий и повышений категории дежурных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует устойчивое мнение, что серверное оборудование должно эксплуатироваться в строго определенных границах температуры и влажности. Каждый человек, знакомый с датацентрами, хоть раз видел таблицу американского сообщества ASHRAE[37]. Но так ли она нужна на самом деле? Давайте рассмотрим формулу теплопроводности из курса термодинамики:

где

• Qt = Q × t – количество тепла, переносимое за единицу времени;

• G – объем воздуха;

• С – теплоемкость воздуха;

• ΔT – разница температур охлаждаемого тела и охлаждающего воздуха.

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

Во-вторых, вентиляторы в канале охлаждения есть всегда (очевидно, что при G = 0 охлаждения не будет), а увеличение скорости их вращения будет стоить значительно меньше капитальных и операционных затрат на построение громоздкой системы охлаждения.

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

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

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

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

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

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

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

Для определения верхней границы нужно понимать, что серверы в стойке могут нагревать воздух на 15–20 ℃, и таким образом температура в горячем коридоре может достигать значений, при которых строительные конструкции начнут терять свои свойства. В реалиях нашей страны уличная температура может превышать 40 ℃, что приведет к температуре в горячем коридоре до 60 ℃. В принципе, если северная построена с устойчивостью к таким температурам, то практического ограничения сверху у нас нет.

Описанная схема доказала свою практическую эффективность и запатентована в России (патент RU 269 20 46), но большинство инженеров российских датацентров по-прежнему ориентируются на графики ASHRAE. Когда соблюдения условий, рекомендуемых какой-то ассоциацией из Америки, требуют клиенты и переубедить их не представляется возможным, наверное, остается только развести руками и выполнять. Также можно прописать, чтобы все сотрудники датацентра ходили в балетных пачках – если клиент готов за это платить, то почему бы и нет. Но для своих собственных датацентров или тех, где клиентам предоставляются мощности под облачные решения, стоит серьезно задуматься: зачем делать дорого и громоздко, если можно сделать просто, дешево и надежно?

Еще одним мифом, возникшим из-за чтения спецификаций без понимания физической сути процессов, является «поддержание требуемой влажности в датацентре». Давайте разберем, что стоит за этим мифом.

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

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

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

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

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

Но самым впечатляющим было то, что Микка вообще не заботился о фильтрации воздуха для своей стойки. Вы можете сами в этом убедиться, найдя в Сети видео с названием Snow is not a problem for servers in Finland. По словам экспериментатора, проект длился полтора года, после чего в серверах стали выходить из строя вентиляторы, а производитель отказался их заменять, и Микка в условиях ограниченного финансирования был вынужден свернуть стойку. Я собственными глазами видел этот сервер и даже получил в подарок один из выросших перчиков.

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

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

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

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

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

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

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

• своевременное обнаружение возгорания;

• эффективное оповещение персонала;

• достаточное количество коротких путей эвакуации из любой точки.

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

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

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

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

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

Пандемия 2020 года показала, насколько все-таки критичным может быть человеческий фактор для датацентров. Решения о защите здоровья сотрудников, принятые на государственном уровне, были способны обезоружить команду эксплуатации. Не будем описывать тут, какие меры и ухищрения принимались для обеспечения продолжения беспрерывной работы. Суть в том, что очевидным стало преимущество тех датацентров, в которых постоянное присутствие команды не обязательно. Эта идея развилась в направление «бесчеловечного» датацентра – размышления о том, как поменять процессы таким образом, чтобы человеческий фактор на них не влиял. Идея, конечно, не нова. В одной зарубежной компании я видел сеть из более чем 50 (!) маленьких датацентров, большинство из которых не имеет постоянного персонала. Некоторые российские компании – владельцы контейнерных датацентров уже имеют неплохой опыт такой работы. Я уже не говорю об огромной сети базовых станций возле вышек операторов мобильной связи. Но нас будет интересовать то, как «обезлюдить» большой многомегаваттный датацентр. Перечислим несколько идей.

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

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

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

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

Мы уже рассматривали варианты сокращения времени обходов в главе про техническое обслуживание. Если поставить задачу отказаться от обходов совсем, кажется, что она решается только внедрением достаточного количества датчиков на основные факторы, ведущие к выходу датацентра из строя. Более экзотические способы вроде запуска роботизированных собак (или других роботварей) с ИК-сенсором для контроля перегрева и датчиком для контроля протечек на лапах выглядят как чересчур усложненный вариант установки локальных датчиков. Даже если в дальнейшем таких собак будут продавать «три на десяточку» и удастся справиться с задачей их программирования, нужно будет существенным образом переосмыслить архитектуру датацентров для беспрепятственного перемещения роботов с учетом требования пожарной и физической безопасности зданий.

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

Еще одно направление – дробление количества единиц оборудования. Например, если нам нужно установить ИБП для расчетной нагрузки в 600 кВт с резервированием, мы можем сделать это установкой четырех блоков по 200 кВт, пяти по 150 кВт или семи по 100 кВт. Понятно, что наименьший реальный эффект окажет отключение в последнем случае. Также, если сравнивать первый и последний варианты, для той же установленной мощности можно будет реализовать резервирование N+2 вместо N+1, что существенно увеличит выживаемость датацентра в случае долгого прибытия команды ТО на площадку. И снова такое решение недешево. Стоит семь раз подумать, может быть проще все же нанять больше дежурных. Скажем, с трехкратным запасом?

Иногда на собеседованиях, да и просто в разговорах с коллегами по отрасли я задаю вопрос: «С каким отказом в датацентрах приходится сталкиваться чаще всего?» Принимая во внимание то, что я занимаюсь обслуживанием инженерного оборудования, большинство старается угадать и более-менее верно называет ИБП. Другие называют те системы, с которыми они нахлебались на своих площадках, не принимая во внимание, что это их собственный частный случай, а не общая ситуация. К сожалению, только единицы сразу отвечают, что подавляющее большинство отказов в датацентрах приходится на HDD-диски. В по-настоящему больших датацентрах их такое количество, что ежедневно может потребоваться несколько человек, которые будут заниматься только заменой этих компонентов (а заодно и планок памяти). Переход с HDD[39] на SSD[40] немного улучшает картину, но не меняет ее. Все равно, диски нужно менять значительно чаще, чем выполнять какие-то другие задачи.

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

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

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

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

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

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

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

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

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

Среди вариантов использования тепла могут быть:

• отопление собственных помещений, например складских или офисных;

• продажа тепловой энергии соседним предприятиям как для промышленного использования, так и для обогрева ближайших жилых комплексов;

• организация тепличных хозяйств на прилегающей территории;

• организация рыбохозяйств в непосредственной близости от датацентра.

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

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

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

Автором еще одного взгляда на перспективы развития датацентров является мой коллега Андрей Воробьев.

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

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

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

1. Фонд оплаты труда и все сопутствующие затраты, связанные с работой человека на объекте, составляют существенную долю всех операционных расходов, достигающую часто 30 %. Снижение этих затрат на протяжении всего жизненного цикла позволит снизить совокупную стоимость владения датацентра до 10–15 % за десять лет эксплуатации.

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

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

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

Эти факторы полностью подтверждаются статистикой опроса IT-директоров крупнейших датацентров[41], в 2020 году трудности с подбором персонала испытали 50 % респондентов (38 % в 2018 году), возможности удаленной работы рассматривают 77 % (33 % в 2018-м), внедрение DCIM планируют 39 % (двумя годами ранее – 11 %), недостаточность текущей системы мониторинга подтвердили 90 % (73 % – в 2018-м). Также 43 % респондентов отметили возрастающую роль ИИ в течение пяти лет.

Однако у модели датацентра «без людей» есть определенные ограничения.

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

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

Кто будет первым? Думаю, начнется все с небольших объектов распределенной инфраструктуры (модульные быстровозводимые датацентры для периферийных вычислений). На таких объектах держать службу эксплуатации крайне неэффективно, однако оставить объекты без контроля тоже нельзя. Именно поэтому на них должна появиться наивысшая степень автоматизации. Это мы наблюдаем уже сейчас.

Крупные коммерческие датацентры будут против исключения человека из процессов эксплуатации, так как они связаны определенными обязательствами со своими заказчиками в виде SLA-договоров (Service Level Agreement) часто с довольно высокими штрафными санкциями. В сегменте XL-датацентров именно корпоративные заказчики и провайдеры облачных услуг первыми начнут прорабатывать и внедрять «темные» датацентры.

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

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

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

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

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

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

Эти работы могут занимать до 25–30 % рабочего времени технического состава, и до сих пор они являются обязательными или крайне рекомендуемыми для основного оборудования датацентра. Однако и здесь происходят существенные изменения.

Рассмотрим для примера ИБП. Если еще десять лет назад в ИБП нужно было регулярно проверять состояние и менять конденсаторы постоянного и переменного тока, фильтры, вентиляторы, батареи, то в последних моделях ИБП для регулярной замены остались только вентиляторы. С появлением Li-Ion-технологий накопления энергии (а также находящихся на подходе Na-Ion, графеновых батарей и пр.) регулярные замены свинцово-кислотных батарей уходят в прошлое. Помимо этого происходит развитие инверторных технологий (многоуровневые инверторы, использование транзисторов на основе GaN, повышение рабочих частот и пр.), что приводит к уменьшению размеров оборудования и увеличению КПД. Снижение потерь до 1 % в перспективе будет означать выделение ИБП мощностью 500 кВт всего 5 кВт тепла, которое можно будет отводить через корпус, убрав последний компонент, требующий регулярной замены, – вентиляторы. ИБП превращается в устройство, не требующее обслуживания в течение всего срока жизни.

Интересны последние разработки ИБП, где функцию обоих преобразований (как AC-DC, так и DC-AC) выполняет BMS (Battery Management System). Это снижает тепловыделение систем и делает их более простыми в эксплуатации.

С системой охлаждения ситуация несколько другая. В настоящий момент большинство коммерческих датацентров использует рекомендуемый диапазон рабочих температур и влажности ASHRAE 18–27 ℃ / 60 %. Для его поддержания в наших широтах необходимо использовать холодильный цикл. По этой причине в датацентрах появляются чиллеры и фреоновые кондиционеры, требующие регулярного обслуживания.

В перспективе температурный диапазон работы IT-оборудования будет расширен, уже сейчас некоторые крупные объекты работают в режимах до +35 ℃. Электрооборудование, включая ИБП и Li-Ion-батареи, уже гарантированно работает при температуре +40 ℃, не снижая своих рабочих характеристик.

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

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

Я не буду затрагивать все инженерные системы, скажу только, что технологически мы уже способны создать оборудование для датацентров, не требующее обслуживания в течение довольно длительного времени. Примером может служить эксперимент компании Microsoft Natic[42]. Уже два раза, в 2015 и 2018 годах, производилось погружение герметичных капсул, содержащих 860 серверов в 12 стойках в прибрежной зоне океана. Как показал этот опыт, такой мини-датацентр может работать до пяти лет без вмешательства человека. За счет использования инертных газов в капсуле количество отказов оборудования было снижено в восемь раз.

Насколько быстро этот подход начнет применяться в больших датацентрах – вопрос времени.

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

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

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

• С точки зрения отдельных компонентов нужно уйти от централизованных систем к распределенным (то есть вместо десяти ИБП по 1500 кВт нужно использовать 1500 ИБП по 10 кВт). В этом случае отказ одного компонента будет незначительно сказываться на работоспособности системы, а деградация характеристик датацентра будет происходить линейно с потерей отдельных компонентов.

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

Одним из интересных проектов, демонстрирующих рассмотренный выше подход, является OCP[43] (Open Compute Project). Он предполагает высокий уровень стандартизации, возможность использования распределенной системы бесперебойного питания в каждой стойке, переход на питание нагрузки постоянным током, широкий диапазон рабочих температур с отказом от холодильного цикла, горячую замену компонентов и многое другое. Основными локомотивами OCP изначально были крупные компании, имеющие у себя крайне высокую концентрацию IT-мощностей, однако постепенно проектом заинтересовались и другие участники рынка.

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

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

При отсутствии людей в датацентре кардинально меняются требования к устройству и функционированию объекта.

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

• Размещение IT-оборудования. Работа на высоте уже не будет осложняющим фактором, поэтому возможно использование IT-стоек любой высоты, что позволит более эффективно использовать объем помещения.

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

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

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

• Используемые площади. Сокращение площадей для размещения персонала позволит оптимизировать расходы.

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

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

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

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

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

ДРИБП – динамические роторные источники бесперебойного питания. Используют в качестве накопителя энергии вращающиеся металлические болванки. Чем больше масса и скорость болванки, тем больше энергии накоплено.

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

ИБП – источник бесперебойного питания. При кратковременном отсутствии электропитания от сети или ДГУ подключает собственное резервное хранение энергии. Чаще всего использует аккумуляторные батареи или кинетические накопители (см. ДРИБП). И у тех и у других есть свои плюсы и минусы.

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

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

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

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

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

ЦОД – центр обработки данных. Специализированный объект, представляющий собой связанную систему IT-инфраструктуры и инженерной инфраструктуры, оборудование и части которых размещены в здании или помещении, подключенном к внешним сетям, как инженерным, так и телекоммуникационным.

ABC – Activity-based Costing. Метод определения стоимости тех или иных расходов в зависимости от соотношения их составляющих, различающихся по цене.

ASHRAE – American Society of Heating, Refrigerating and Air-Conditioning Engineers. Американская ассоциация инженеров-холодильщиков. Группа профессионалов, предложившая стандартизировать климатические условия в датацентрах. Некоторые считают этот стандарт самым авторитетным источником информации о том, до какой температуры нагреваются серверы.

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

BMS – 1. Building Management System. Система управления зданием. Под этой аббревиатурой может скрываться просто другое название CMMS, но с большим акцентом на возможности диспетчеризации. Также аббревиатура BMS чаще применяется по отношению к офисным и жилым зданиям, тогда как CMMS более уместна для промышленных. 2. Battery Management System. Аппаратная система наблюдения за состоянием аккумуляторных батарей. Предупреждает, когда с одной или несколькими ячейками не все в порядке.

CapEx – Capital Expenses. Часть бюджета, учитывающая постоянные, капитальные затраты.

CCTV – Closed Circuit Television. Система видеоконтроля. Часть системы безопасности объекта.

CMMS – Computerized Maintenance Management System. Единая система, хранящая все аспекты эксплуатации объекта. Производители программного обеспечения с разным успехом приближаются к идеальному продукту, но окончательно достичь этой цели, по-видимому, невозможно.

Commissioning Agent – агент пусконаладки. Команда, берущая на себя бремя лидерства в процессе ПНР.

CT – Component Test. Покомпонентное тестирование частей оборудования.

DC-AC – процесс преобразования электрического тока из постоянного в переменный. Direct Current – Alternating Current.

DCC – Design Compliance Check. Начальный этап пусконаладки, на котором проверяют, насколько проектные решения годятся для реальной эксплуатации в дальнейшем и соответствуют требованиям технического задания.

DCIM – Data Center Infrastructure Management. Концепция некоего информационного поля, в котором собираются и обрабатываются все данные о работе датацентра. В связи с неоднозначностью толкования многие компании позиционируют свои продукты как часть этой системы или даже целую систему. В реальной жизни я не встречал никого, кто мог бы рассказать, что это такое. Термин можно использовать, если хочется поумничать, наряду, например, с «конвергентностью».

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

ERP – Enterprize Resource Planning. Планирование ресурсов предприятия. В повседневной речи под этим сокращением понимают ERP-систему – программное обеспечение, связывающее в единый информационный поток различные процессы в компании. Например, бухгалтерию, кадры, склад, производственные отделы и т. д.

FAT – Factory Acceptance Test. Производственная проверка оборудования перед отправкой заказчику.

FMR – Fiber Management Room. Помещение, в которое приходят внешние оптические кабели датацентра. Может быть частью NOC, но чаще всего выполняется отдельно для спокойствия.

FTP – File Transport Protocol. До недавних пришествий разнообразных облачных сервисов именно по этому протоколу происходило перемещение электронной документации на серверы для хранения и общего доступа.

FWT – Factory Witness Test. Разновидность FAT, при котором заказчики посещают завод производителя и присутствуют при выполнении теста.

HDD – Hard Disk Drive. Традиционная технология хранения данных в серверах на дисках с вращающимися шпинделями. Основным недостатком технологии является то, что, если на работающий диск громко накричать, он выдаст ошибку записи/считывания.

HO (handover) – заключительный этап пусконаладки. Передача результатов проекта от строителей в эксплуатацию.

IA – Installation Acceptance – то же, что IAT.

IAT – Installation Acceptance Test. Приемка смонтированного оборудования.

ISAT – Integrated Site Acceptance Test. Функциональный тест всего объекта как целого (в отличие от SAT, проводящегося только для части объекта).

ITOPS – IT Operations. Как и DCOPS, выдуманный термин, описывающий специалистов по серверному и сетевому оборудованию.

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

NOC – Network Operations Center. Центр сетевой связности объекта. В отрасли существуют и другие термины, по сути обозначающие то же самое: meet-me room, коммутационный центр и т. п. Может отличаться от FMR.

OCP – Open Compute Project. Инициатива по созданию стандартной и свободной вычислительной системы.

OJT – On-the-job Training. Обучение непосредственно на рабочем месте.

OpEx – Operational Expenses. Часть бюджета, учитывающая операционные, текущие затраты.

PMBOK – Project Management Body of Knowledge. Культовая книга руководителей проектов из любой отрасли, наподобие той, которую вы сейчас держите в руках. Рассказывает о всех тонкостях профессии.

PCI DSS – Payment Card Industry Data Security Standard. Стандарт безопасности индустрии платежных карт – набор требований по хранению данных пользователей, не позволяющий злоумышленнику получить к ним доступ ни физически, ни через сетевые соединения.

PUE – Power Utilisation Efficiency. Метрика, позволяющая соседним датацентрам мериться своей эффективностью. К сожалению, не существует абсолютно принятого стандарта ее измерения, поэтому полагаться на ее значение нельзя. К тому же для конечного пользователя эффект может быть неочевидно противоположным. Эффективные датацентры имеют меньше «лишнего» оборудования для резервирования. То есть более энергоэффективный датацентр может оказаться менее надежен.

RACI – Responsible, Accountable, Consulted, Informed. Популярный вид отображения ролей в проекте, где для каждой задачи определяются исполнители, ответственные, консультанты и «те, кто стоит в копии», – пользователи информации.

RCA – Root Cause Analysys. Процесс поиска причины инцидента, ответа на вопрос «Как же так вышло?». Очень желательно, чтобы процесс этот был хорошо документирован.

SAT – Site Acceptance Test. Функциональные испытания отдельно взятой системы или оборудования.

SLA – Service Level Agreement. В нашем случае обещание поставщика оказать услуги в течение определенного срока. Например, при инциденте на инженерном оборудовании ответить на телефонный звонок не позже чем через четыре часа.

SSD – Solid State Drive. Чуть более современная технология хранения данных в серверах. В таких дисках ничего не вращается, но срок жизни их чуть меньше, и выходят из строя они внезапно и сразу.

Storage Class Memory – новая энергонезависимая разновидность SSD.

Заставьте данные говорить: Как сделать бизнес-дашборд в Excel. Руководство по визуализации данных

Алексей Колоколов

Ценность ваших данных

Сергей Кузнецов, Александр Константинов, Николай Скворцов

Мама, я тимлид! Практические советы по руководству IT-командой

Марина Перескокова

Датацентр, или дата-центр, – единого официального написания нет, даже американцы напишут data center, тогда как британцы – data centre. В книге мы будем использовать вариант написания «датацентр».

Федеральная сеть дата центров, учредитель Координационного совета по ЦОДам и облачным технологиям (АНО КС ЦОД), член Ассоциации участников отрасли ЦОД.

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

IT Operations. Как и DCOPS, выдуманный термин, описывающий специалистов по серверному и сетевому оборудованию.

Network Operations Center. Центр сетевой связности объекта. В отрасли существуют и другие термины, по сути обозначающие то же самое: meet-me room, коммутационный центр и т. п. Может отличаться от FMR.

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

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

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

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

Project Management Body of Knowledge. Культовая книга руководителей проектов из любой отрасли, наподобие той, которую вы сейчас держите в руках. Рассказывает о всех тонкостях профессии.

Factory Acceptance Test. Производственная проверка оборудования перед отправкой заказчику.

Site Acceptance Test. Функцональные испытания отдельно взятой системы или оборудования.

Responsible, Accountable, Consulted, Informed. Популярный вид отображения ролей в проекте, где для каждой задачи определяются исполнители, ответственные, консультанты и «те, кто стоит в копии», – пользователи информации.

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

Factory Witness Test. Разновидность FAT, при котором заказчики посещают завод производителя и присутствуют при выполнении теста.

Integrated Site Acceptance Test. Функциональный тест всего объекта как целого (в отличие от SAT, проводящегося только для части объекта).

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

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

Источник бесперебойного питания. При кратковременном отсутствии электропитания от сети или ДГУ (дизель-генераторной установки) подключает собственное резервное хранение энергии. Чаще всего использует аккумуляторные батареи или кинетические накопители (см. ДРИБП в списке аббревиатур в конце книги). И у тех и у других есть свои плюсы и минусы.

File Transport Protocol. До недавних пришествий разнообразных облачных сервисов именно по этому протоколу происходило перемещение электронной документации на серверы для хранения и общего доступа.

On-the-job Training. Обучение непосредственно силами старших товарищей.

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

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

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

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

Enterprize Resource Planning. Планирование ресурсов предприятия. В повседневной речи под этим сокращением понимают ERP-систему – программное обеспечение, связывающее в единый информационный поток различные процессы в компании. Например, бухгалтерию, кадры, склад, производственные отделы и т. д.

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

Root Cause Analysys. Процесс поиска причины инцидента, ответа на вопрос «Как же так вышло?». Очень желательно, чтобы процесс этот был хорошо документирован.

Payment Card Industry Data Security Standard. Стандарт безопасности индустрии платежных карт – набор требований по хранению данных пользователей, не позволяющий злоумышленнику получить к ним доступ ни физически, ни через сетевые соединения.

«Почти пропало» – ситуация, при которой инцидент не произошел, так как потенциальную неисправность удалось обнаружить и устранить заранее.

Data Center Infrastructure Management. Концепция некоего информационного поля, в котором собираются и обрабатываются все данные о работе датацентра. В связи с неоднозначностью толкования многие компании позиционируют свои продукты как часть этой системы или даже целую систему. В реальной жизни я не встречал никого, кто мог бы рассказать, что это такое. Термин можно использовать, если хочется поумничать, наряду, например, с «конвергентностью».

Power Utilisation Efficiency. Метрика, позволяющая соседним датацентрам мериться своей эффективностью.

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

Service Level Agreement. В нашем случае – обещание поставщика оказать услуги в течение определенного срока. Например, при инциденте на инженерном оборудовании ответить на телефонный звонок не позже чем через четыре часа.

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

Capital Expenses. Часть бюджета, учитывающая постоянные капитальные затраты.

Operational Expenses. Часть бюджета, учитывающая операционные, текущие затраты.

American Society of Heating, Refrigerating and Air-Conditioning Engineers – американская ассоциация инженеров-холодильщиков. Группа профессионалов, предложившая стандартизировать климатические условия в датацентрах. Некоторые считают этот стандарт самым авторитетным источником информации о том, до какой температуры нагреваются серверы.

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

Hard Disk Drive. Традиционная технология хранения данных в серверах на дисках с вращающимися шпинделями. Основным недостатком технологии является то, что, если на работающий диск громко накричать, он выдаст ошибку записи/считывания.

Solid State Drive. Чуть более современная технология хранения данных в серверах. В таких дисках ничего не вращается, но срок жизни их чуть меньше, и выходят из строя они внезапно и сразу.

Uptime Institute, Intelligence Report 42

https://natick.research.microsoft.com

Open Compute Project. Инициатива по созданию стандартной и свободной вычислительной системы.