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

Теперь умножим количество залов на десять. Появились вопросы логистики. На каком складе что хранить, чтобы не бегать за каждой запчастью? Как вовремя пополнять запасы, чтобы внеплановый ремонт не застал врасплох? Если оборудования много, держать все технические работы в голове невозможно, а на бумаге – сложно. Тут на помощь приходит MMS, или maintenance management system, – система управления техническим обслуживанием оборудования (ТО). 


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

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

Как мы пришли к собственной MMS


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

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

Какое-то время мы хранили документы так, но потом открыли для себя Excel :)

MMS в Excel. Со временем структура документации перекочевала в Excel. В основе был список оборудования, к нему привязали графики ТО, чек-листы и ссылки на акты выполненных работ: 



В списке оборудования указали основные характеристики и место в ЦОДе:


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



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

Первая «взрослая» система. В 2014 году мы проходили первый аудит Management & Operations по стандартам Operational Sustainability от Uptime Institute. Проходили почти с той самой экселькой, но за год сильно доработали ее: добавили ссылки на инструкции и чек-листы для инженеров. Аудиторы сочли такой формат вполне рабочим. Они смогли отследить все операции с оборудованием и убедились, что информация актуальна, а процессы выстроены. Аудит тогда прошли «на ура», набрав 92 балла из 100 возможных.

Встал вопрос: как жить дальше. Решили, что нужна «серьезная» MMS, посмотрели несколько платных программ, но в итоге решили писать софт сами. Тот самый Excel использовали как развернутое ТЗ. Вот какие задачи мы ставили перед MMS. 

Что мы хотели от MMS


В большинстве случаев MMS – это набор справочников и отчетов. Наша иерархия справочников выглядит примерно так:



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



Дальше идет список инженерного оборудования. Его мы собирали по системам:

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


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

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


Операции «Изменение уставок температуры» и «Замена быстросъемных соединений кабеля» будут общими для чиллеров и систем кондиционирования одного производителя.

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

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

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


Такая история ТО и ремонтов накопилась за 4 года по конкретному кондиционеру.

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

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

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

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


Отдельно ведем справочник контактов. В него заносим данные поставщиков и подрядчиков, которые проводят ТО: 



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


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

Как весь процесс устроен сейчас, на примере расскажет alexddropp

Как проходит ТО в MMS


Когда-то давно выполненные работы документировали уже по факту. Мы просто проводили ТО и после него подписывали акт выполненных работ. Так делают 99% серверных, но, по опыту, этого недостаточно. Чтобы ничего не забыть, сначала формируем наряд-допуск на работы. Это документ с описанием работ и условий их выполнения. Любое ТО и ремонт в нашей системе начинается с него. Как это происходит: 

  1. Смотрим ближайшие запланированные работы в графике ТО:

  2. Создаем новый наряд-допуск. Выбираем подрядчика на ТО, кто руководит процессом с нашей стороны и согласовывает работы у нас. Указываем, где и когда будут работы, выбираем тип оборудования и программу, по которой пойдем: 

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

  4. Указываем конкретное оборудование. В зависимости от типа работ в программе ТО прописаны предварительные мероприятия, например: заказать топливо на площадку, запланировать вводный инструктаж инженеров и оповестить коллег. 

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

  5. Сохраняем наряд, отправляем письмо согласующему и ждем его ответа:
  6. К приезду инженера мы распечатываем наряд прямо из системы.

  7. В наряде есть чек-лист операций для программы ТО. Руководитель работ в ЦОДе контролирует ТО и ставит галочки.


    Какое-то время хватало краткого чек-листа. Потом мы внедрили методические инструкции, или MOP (method of procedure). С помощью такого документа любой сертифицированный инженер может выполнить проверку любого оборудования. 

    Все расписано максимально подробно, вплоть до шаблонов писем-оповещений и погодных условий: 



    Распечатанный документ выглядит вот так:



    По стандартам Uptime Institute такой MOP должен быть на все операции. Это довольно большой объем документации. По опыту, рекомендуем разрабатывать их постепенно, например, по одному MOP в месяц.
  8. После работ инженер выставляет акт выполненных работ. Его сканируем и прикрепляем к карточке вместе со сканами других документов: наряда-допуска и MOP. 

  9. В наряде отмечаем выполненные работы: 

  10. В карточке оборудования сохранилась история ТО:


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

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