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