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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другие программы

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

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

Глава 14

«Сколько у нас мушкетов?» Управление мощностями

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

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

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

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

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

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