Портал №1 по управлению цифровыми
и информационными технологиями

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

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


 

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

 

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

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

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

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

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

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 8

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

    • “маленькая, но крайне важная деятельность”
      +1

      Размер конечно зависит, но начать точно можно с малого.

  • Сразу думать об организации требований к мониторингу довольно тяжело. Обычно мониторинг берется as-is с аргументацией “так всегда было”.
    Сейчас мы, у себя в организации, имеем мониторинг из двух организаций, который между собой никак не пересекается.
    Более того, весь мониторинг идет в одну комманду, и не важно, инфраструктура это или функционал. На мой вопрос “Зачем?” я получил ответь “Так было всегда”.
    И вот теперь, задним числом начинаем создавать процедуры по мониторингу. Начиная от процесса принятия, заканчивая RACI для того что имеем уже.

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

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

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

          • Ну, на “место вот-вот закончится” и так приходят инциденты. Но обычно падения системы из-за одной файлухи не происходят, чаще из-за комплекса событий. Это и хотим отслеживать.

  • Andrey Radoselsky

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

    Занимаясь вот уже 15 лет системами управления\мониторинга я хочу сказать, что в 90% систем которые я видел, которыми пользовался, и которые внедрял, используется модель работы как в следующем анекдоте:
    Пилотирует Василий Иванович (Ч) с Петькой (П) самолет:
    Ч.-Петька, прибор?
    П. – Прибор – 120!
    Ч. – Что “120”?
    П – А что “Прибор”?

    Процессы обработки событий важны.
    Но на мой взгляд основным камнем преткновения на пути создания стабильных и “usefull” систем мониторинга, является как раз отсутствие, “модели данных”. Я ее называю “модель объекта управления\модель мониторинга”. Вот тут чуть подробнее – http://anrad13.blogspot.com/2011/12/blog-post_30.html
    По минимуму модель должна содержать состав контролируемых компонентов и параметров (ака источники данных), значения “нормального состояния” и “FAQ” по ненормальным состояниям.

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;