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

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

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

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

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

CMMS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование работ произрастает из перечня