Полноценный зонтичный мониторинг, по ощущениям, сегодня есть у считанных единиц: я бы оценил долю таких компаний примерно в 1–2%. И обычно путь к внедрению у всех выглядит примерно одинаково: что‑нибудь падает, ЦОД останавливается, бизнес несет многомиллионные убытки, после чего собственник логично задает вопрос: «Что нужно сделать, чтобы это больше не повторилось?» Так и возникает тема с внедрением мониторинга.
В этом кейсе все было скучнее — в хорошем смысле. Никакого «пожара» не случилось. Просто однажды в компании поняли, что хотят в любой момент времени видеть полную картину всего происходящего в ЦОД. Это, можно сказать, уникальная история: за 15 лет в промышленной автоматизации и мониторинге с таким я столкнулся впервые.
Что было на входе
Название компании раскрывать не могу. Скажу только, что она из финансового сектора.
Из инфраструктуры у них имелось два ЦОД. Мониторинг уже был внедрен, причем его было достаточно много: инженеры смотрели за работой систем кондиционирования и энергоснабжения, сисадмины наблюдали за серверами и виртуалками, сетевики — за сетью, инфобез — за своими системами. То есть формально все было хорошо: за каждым участком уже кто‑то следил.
При этом полной картины всего происходящего ни у кого не было. И чтобы понять, каково состояние двух ЦОД целиком, нужно было в буквальном смысле созвать консилиум специалистов из разных направлений. Это сильно не нравилось техническому директору.
Как пришли к зонтичному мониторингу
Изначально термин зонтичный мониторинг компания вообще не использовала. Просто была поставлена задача объединить все системы в одном окне, и специалисты начали разбираться, как такое можно реализовать и каким образом это называется..
В итоге в компании довольно сильно заморочились и написали верхнеуровневую систему самостоятельно. Исторически у них вообще многое делалось под себя, поэтому такой путь никого не испугал.
Затем в эту самописную систему начали собирать данные из разных источников:
системы мониторинга инженерной инфраструктуры DATCHECK,
гипервизоров ESXi,
систем информационной безопасности,
серверного оборудования по IPMI,
системы видеонаблюдения через стандартные RTSP потоки.
С камерами, кстати, получилось очень интересное решение. Допустим, происходит авария в конкретной зоне ЦОД, оператор фиксирует событие, тут же открывает камеру и видит, что там происходит физически.
«Слепые зоны»
Далее начинается менее приятная часть. Не все оборудование в итоге удалось подключить к «зонтику».
Дело в том, что один из двух ЦОД компании был довольно старый. И часть инженерного оборудования там устанавливалась в те времена, когда еще не было возможности нормальной диспетчеризации.
Таким образом, можно было контролировать состояние таких систем только по косвенным признакам. Например, если ИБП нам ничего про себя не рассказывает, но мы видим, что на выходе исчезло питание, то мы понимаем, что источник питания перестал выполнять свою функцию. Неидеальная наблюдаемость, но лучше, чем ничего.
При этом менять исправное оборудование ради того, чтобы внедрить его в мониторинг, в компании не стали. Там решили, что обновлять старые устройства будут постепенно, в рамках планового технического перевооружения, что, на мой взгляд, вполне здраво.
Вообще, по своему опыту могу сказать, что старое оборудование — одна из наиболее частых технических проблем в подобных проектах. И в данном случае в компании еще легко отделались. В моей практике были случаи и посерьезнее. Например, представители другой организации на одном из своих объектов захотели реализовать похожую схему, но их старая система могла интегрироваться фактически только через протокол OPC DA. Он активно использовался ещё 10–15 лет назад, а сегодня поддержка протокола ограничена, в первую очередь из‑за архитектурных проблем и проблем с безопасностью. Мы сделали для заказчика промежуточный конвертер. И технически все заработало. Тем не менее в перспективе руководство компании запланировало техническое перевооружение оборудования.
Главная проблема — не техническая
Но главная проблема в реализации проекта, как ни странно, оказалась вовсе не технической, а организационной. Представьте компанию, где четыре руководителя:
тот, кто отвечает за мониторинг инженерного оборудования,
системный администратор,
сетевой администратор,
специалист по информационной безопасности.
У каждого своя зона ответственности. И каждый в каком‑то смысле «охраняет свою норку». Вдруг приходит технический директор и говорит: «А давайте вынесем самые важные данные из всех ваших систем на один общий экран».
С технической точки зрения все логично. С человеческой — руководство сталкивается с сопротивлением. Раньше специалист был единственным человеком, который понимал, что происходит внутри его участка. После интеграции часть этой информации становится прозрачной для других служб, технического директора и даже руководства компании. У специалисты возникает вполне естественный вопрос: а что теперь становится с моей ролью? Плюс добавьте к этому классическое: «Все же работает. Зачем лезть туда, где все хорошо, и что‑то интегрировать? А если мы все сломаем?»
Поэтому в таких проектах очень нужен человек, которому внедрение зонтичного мониторинга очень сильно нужно. Обычно это технический директор (как в нашем случае) или ИТ‑директор.
Если такого человека нет, такие проекты обычно даже не начинаются. Это, пожалуй, одна из главных причин, почему зонтичный мониторинг все еще не распространен.
Сначала — пилот, потом полномасштабное развертывание
У зонтичного мониторинга есть и еще одна неприятная особенность. Его, как ремонт, можно делать бесконечно. Можно даже довести реализацию до 99%, но полностью закончить — сложно.
Поэтому я бы не начинал сразу с глобального проекта. Лучше придерживаться следующего подхода: основной костяк проекта реализуем за несколько месяцев (до полугода — для крупной инфраструктуры), а затем постепенно разворачиваем систему.
Стартуем с пилота: интегрируем, например несколько ИБП, один гипервизор, несколько единиц серверного оборудования и одну инженерную систему. На технический эксперимент такого масштаба обычно уходит около недели. Когда поняли, что все стыкуется, идем дальше.
Именно так и поступили представители компании из нашего кейса. На уровне пилота в систему добавили несколько элементов разных типов инфраструктуры. Показали руководству, получили одобрение проекта и бюджета, включая дозакупку необходимого оборудования. И уже после этого начали масштабировать решение.
А теперь главное: для чего все это было
Можно подумать, что зонтичный мониторинг — это просто удобный дашборд, на который вывели данные с нескольких систем. Но на самом деле это намного больше и важнее. Его главная ценность в другом: он становится инструментом ситуативного управления ЦОДом, то есть позволяет не просто зафиксировать аварию, но и увидеть полную картину состояния оборудования, и на основании этой информации осознанно предпринимать необходимые действия. При этом четко понимать, как твои действия влияют на работу систем.
У нашего клиента, к счастью, никакого серьезного инцидента не случилось, поэтому приведу пример из практики другой компании.
Представим ситуацию. Значительная часть специалистов эксплуатации уезжает на корпоратив. Место выбирают удачно: там нет ни связи, ни интернета. И ровно в этот момент в ходе строительных работ экскаватор повреждает сразу два кабеля — и основной, и резервный. Объект остается без внешнего электроснабжения. В городе при этом не оказывается человека, который мог бы сразу начать корректно останавливать виртуальные машины. Пришлось выигрывать время.
Одним из решений стало отключение части оборудования, в том числе систем кондиционирования. Нагрузка на ИБП уменьшилась, время автономной работы увеличилось. За выигранные минуты удалось найти человека с доступом к виртуальной инфраструктуре и начать останавливать и переносить системы.
В такой ситуации особенно хорошо понятно, зачем нужен зонтичный мониторинг. Если бы система была внедрена, то оператор на одном экране видел бы всю цепочку событий. В том числе ему было бы понятно, на сколько прямо сейчас хватает автономии и как изменится ситуация в случае принятия тех или иных решений. А значит, оператор смог бы выиграть максимальное количество времени для специалистов и нивелировать, насколько это возможно, неприятные последствия для компании.
Мне кажется, уже в скором будущем рынок начнет понимать ценность таких решений и постепенно внедрять их на объектах критической инфраструктуры.
