На днях закинули в CleverTEST очередной пробный экзамен по ITIL, пока кидали, на глаза попался вопрос:
Что из перечисленного лучше всего описывает назначение управления событиями?
- Способность обнаруживать события, толковать их и определять подходящий способ реагирования
- Способность внедрять средства мониторинга
- Способность отслеживать и контролировать работу технического персонала
- Способность формировать отчетность об успешном предоставлении услуг на основе данных о времени бесперебойной работы устройств
Вспомнился недавний разговор с одним знакомым, который жаловался на несовершенство используемой им системы мониторинга, "которая заваливает их спамом, а толку никакого".
В моем понимании, идеальная схема работы с большими объемами информации заложена в процессе управления конфигурациями. А именно:
- понимаем кто потребитель информации
- понимаем его требования
- строим модель данных
- данные собираем
- периодически оцениваем полезность данных и пересматриваем модель данных.
По этому же пути можно идти и с мониторингом. Все что собирается и куда-то высылается должно быть в первую очередь востребовано. Все что потенциально может прилететь из системы мониторинга, должно иметь понятного адресата, способ 
реагирования, требования к накоплению и т.д.
Наиболее яркий пример определения таких требований был в проекте по внедрению процесса управления мощностями, где определялись ресурсы (например, сервер) от которых зависел ИТ-сервис, определялись характеристики таких ресурсов (например, объем жесткого диска) и пороговые значения, при которых пора поднимать тревогу.
Интересно то, что когда начинаешь думать сверху вниз, от модели здоровья ИТ-сервиса, к ресурсам, а не наоборот, появляются требования до которых не додуматься в обратном порядке. Иногда бывает полезно отслеживать не событие, а наоборот его отсутствие (не выполнилась синхронизация, не осуществилось резервное копирование). Например, вы же начинаете проверять, все ли в порядке с почтой, если за полдня вам не пришло ни одного письма? Почему бы это беспокойство не заложить в систему мониторинга.
Вывод напрашивается сам собой, помимо системы, если конечно хочется получить результат, нужно сразу думать об организации работ по формированию требований к мониторингу, их реализации, пересмотру, реагированию на события и т.д. Это может быть не обязательно процесс, может быть просто регламент, предусматривающий порядок выполнения этих работ. Однако без этого самая дорогая и навороченная система мониторинга будет скорее спам-машиной, чем полезным инструментом.
Уверенная дорога до ITIL Expert
Достаточно маленькая, но крайне важная деятельность по постоянному управлению требованиями мониторинга ) Без нее процессы управления событиями очень скоро приходят в упадок.
«маленькая, но крайне важная деятельность»
+1
Размер конечно зависит, но начать точно можно с малого.
Сразу думать об организации требований к мониторингу довольно тяжело. Обычно мониторинг берется as-is с аргументацией «так всегда было».
Сейчас мы, у себя в организации, имеем мониторинг из двух организаций, который между собой никак не пересекается.
Более того, весь мониторинг идет в одну комманду, и не важно, инфраструктура это или функционал. На мой вопрос «Зачем?» я получил ответь «Так было всегда».
И вот теперь, задним числом начинаем создавать процедуры по мониторингу. Начиная от процесса принятия, заканчивая RACI для того что имеем уже.
Знакомая картинка. Но зато попробовав работать в режиме «так было всегда» есть основание для проектирования процедур с учетом собственного опыта, «граблей», «костылей» и прочих подручных предметов, с которыми пришлось иметь дело на практике 🙂
С учетом этого и создаются.
Сейчас вообще витает идея «алертинга над алертингом» на основе анализа критических инцидентов и предшествующих им event'ам. Чтобы в случае чего загоралась лампочка и писалось:"Через 30 минут возможно падение системы Х с вероятностью Y".
Проактивный мониторинг — интересная тема. Хотя конечно выявить предвестники грядущего падения системы не всегда просто. Если конечно это не очевидные: «место вот-вот закончится» и «что-то начало подтормаживать».
Ну, на «место вот-вот закончится» и так приходят инциденты. Но обычно падения системы из-за одной файлухи не происходят, чаще из-за комплекса событий. Это и хотим отслеживать.
Хороший вопрос!
Занимаясь вот уже 15 лет системами управления\мониторинга я хочу сказать, что в 90% систем которые я видел, которыми пользовался, и которые внедрял, используется модель работы как в следующем анекдоте:
Пилотирует Василий Иванович (Ч) с Петькой (П) самолет:
Ч. -Петька, прибор?
П. — Прибор — 120!
Ч. — Что «120»?
П — А что «Прибор»?
Процессы обработки событий важны.
Но на мой взгляд основным камнем преткновения на пути создания стабильных и «usefull» систем мониторинга, является как раз отсутствие, «модели данных». Я ее называю «модель объекта управления\модель мониторинга». Вот тут чуть подробнее — anrad13.blogspot.com/2011...log-post_30.html
По минимуму модель должна содержать состав контролируемых компонентов и параметров (ака источники данных), значения «нормального состояния» и «FAQ» по ненормальным состояниям.
Но, по моему опыту, об этом начинают задумываться не при разработке-внедрении систем, а уже через 2-3 года траблшутной эксплуатации. Я только у одного заказчика в ТЗ встретил требование на разработку схемы мониторинга и соответствующую статью расходов. Ну может у кого-то опыт получше -)
Так что «плохие» системы мониторинга, IMHO, в первую очередь заслуга их заказчиков, а потом уже несовершенства процессов управления событиями. Какой бы не был хороший процесс управления событиями — без «правильных» событий ему просто не с чем будет работать.