Мониторинг инфраструктуры, что кроме автоматизации?

На днях закинули в CleverTEST очередной пробный экзамен по ITIL, пока кидали, на глаза попался вопрос:


 

Что из перечисленного лучше всего описывает назначение управления событиями?

 

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

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

В моем понимании, идеальная схема работы с большими объемами информации заложена в процессе управления конфигурациями. А именно:

  • понимаем кто потребитель информации
  • понимаем его требования
  • строим модель данных
  • данные собираем
  • периодически оцениваем полезность данных и пересматриваем модель данных.

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

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

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

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

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Alexander Vanyurikhin

    Сразу думать об организации требований к мониторингу довольно тяжело. Обычно мониторинг берется as-is с аргументацией «так всегда было».

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

    Более того, весь мониторинг идет в одну комманду, и не важно, инфраструктура это или функционал. На мой вопрос «Зачем?» я получил ответь «Так было всегда».

    И вот теперь, задним числом начинаем создавать процедуры по мониторингу. Начиная от процесса принятия, заканчивая RACI для того что имеем уже.

    1. Евгений Шилов Автор

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

      1. Alexander Vanyurikhin

        С учетом этого и создаются.

        Сейчас вообще витает идея «алертинга над алертингом» на основе анализа критических инцидентов и предшествующих им event'ам. Чтобы в случае чего загоралась лампочка и писалось:"Через 30 минут возможно падение системы Х с вероятностью Y".

        1. Евгений Шилов Автор

          Проактивный мониторинг — интересная тема. Хотя конечно выявить предвестники грядущего падения системы не всегда просто. Если конечно это не очевидные: «место вот-вот закончится» и «что-то начало подтормаживать».

  2. Andrey Radoselsky

    Хороший вопрос!

    Занимаясь вот уже 15 лет системами управления\мониторинга я хочу сказать, что в 90% систем которые я видел, которыми пользовался, и которые внедрял, используется модель работы как в следующем анекдоте:

    Пилотирует Василий Иванович (Ч) с Петькой (П) самолет:

    Ч. -Петька, прибор?

    П. — Прибор — 120!

    Ч. — Что «120»?

    П — А что «Прибор»?

    Процессы обработки событий важны.

    Но на мой взгляд основным камнем преткновения на пути создания стабильных и «usefull» систем мониторинга, является как раз отсутствие, «модели данных». Я ее называю «модель объекта управления\модель мониторинга». Вот тут чуть подробнее — anrad13.blogspot.com/2011...log-post_30.html

    По минимуму модель должна содержать состав контролируемых компонентов и параметров (ака источники данных), значения «нормального состояния» и «FAQ» по ненормальным состояниям.

    Но, по моему опыту, об этом начинают задумываться не при разработке-внедрении систем, а уже через 2-3 года траблшутной эксплуатации. Я только у одного заказчика в ТЗ встретил требование на разработку схемы мониторинга и соответствующую статью расходов. Ну может у кого-то опыт получше -)

    Так что «плохие» системы мониторинга, IMHO, в первую очередь заслуга их заказчиков, а потом уже несовершенства процессов управления событиями. Какой бы не был хороший процесс управления событиями — без «правильных» событий ему просто не с чем будет работать.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20