Управление событиями. Процесс или система?

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

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

• Обнаружение события. Самый первый шаг, гарантирующий, что средства мониторинга настроены в соответствии с требованиями, которые мы закладываем, и способны обнаруживать интересующие нас события. Здесь должны быть определены типы объектов мониторинга, метрики производительности и стандартные пороговые значения по этим метрикам, типовые сбои и информационные события.
• Фильтрация. Основная задача на данном этапе состоит в избавлении от «мусора» — событий, которые не требуют реакции.
• Приоритизация. Цель данного шага — выделить важные события из общего потока, используя различные атрибуты событий. Как правило, расчет важности производится на основе критичности события и степени влияния элемента ИТ-инфраструктуры, связанного с событием, на функционирование сервиса.
• Корреляция. Задача данного этапа — поиск событий, связанных с обрабатываемым. Типичный пример — корреляция типа fault-resolution или обработка повторяющихся сообщений, однако с усложнением архитектуры сервисов возникает потребность в более совершенных механизмах корреляции. В первую очередь это поиск корневой причины, выделение сообщений, являющихся первоначальной причиной сбоя. Все чаще возникает необходимость в использовании кросс-доменной корреляции — определении зависимости между событиями, зарегистрированными разными средствами мониторинга.
• Определение способа реагирования. На данном шаге определяется действие, которое должно быть выполнено в качестве реакции на событие. Некоторые события достаточно сохранить в архиве, а некоторые требуют незамедлительных корректирующих воздействий, которые должны предотвратить сбой в работе бизнес-сервиса.

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

Типовая архитектура системы обработки событий

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

От теории к практике

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

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

Конечно, создать единую систему можно и на основе уже существующих средств мониторинга (функциональность большинства из них позволяет обрабатывать события из разных источников и выполнять простейшую корреляцию), однако такая реализация не решает основных задач, диктуемых сервисным подходом: определение степени влияния на сервисы (impact analysis) и выявление первопричины события (root cause analysis). Решение данных задач невозможно без использования сервисно-ресурсных моделей, содержащих данные об элементах ИТ-инфраструктуры, системах поддержки бизнес-сервисов и их взаимосвязях. Действительно, как определить важность события, не обладая информацией о том, каким образом отдельный ИТ-объект, породивший событие, влияет на функционирование сервиса в целом? По сути, сервисно-ресурсные модели представляют собой модели данных в базе данных управления конфигурациями (CMDB).

Представим сервис, работа которого обеспечивается кластером высокой доступности, состоящим из двух узлов. Приложение функционирует на одном из узлов кластера, а второй узел включается в случае проблем с основным. Если на неактивном узле вышел из строя один из дисков RAID-массива, то это не повлияет на предоставление сервиса — основной по-прежнему продолжает выполнять свои функции, а сервис предоставляется без ухудшения основных характеристик. Можно считать такое событие важным? Безусловно, ведь выход из строя второго диска RAID-массива резервного узла приведет к отказу резервного сервера, что снизит отказоустойчивость системы в целом и может привести к нарушению соглашения об уровне обслуживания (Service Level Agreement, SLA). Однако для сотрудника, ответственного за аппаратное обеспечение, такое событие ничем не будет отличаться от массы других подобных малозначительных сообщений — необходимо правильно расставить приоритеты событий, чтобы потенциальные проблемы с важными сервисами не терялись на общем фоне.

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

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

О модели

Идея использовать модели для описания сервисов не нова, однако до сих пор нет единого мнения по поводу того, как должна выглядеть модель сервиса: типы объектов, глубина детализации, характер и направление связей. Более того, модели, создаваемые для разных типов задач, должны строиться по различным принципам и удовлетворять различным требованиям — например, модели для мониторинга не подойдут для управления финансовыми затратами на сервис. В случае мониторинга и управления событиями модели должны отвечать следующим требованиям:

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

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

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

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

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

Рекомендации

Может сложиться впечатление, что построить реально работающую систему управления событиями практически невозможно, однако все не так плохо, если следовать простым рекомендациям.

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

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

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

Современное ПО для обработки событий (HP Omi, IBM Tivoli/Netcool OMNIbus и т. п.) не только позволяет автоматизировать активности в рамках процесса управления событиями, но уже в базовой конфигурации содержит набор лучших практик по управлению событиями (наборы фильтров событий, правила корреляции и т. п.). Это позволит облегчить проектирование процесса управления событиями, а главное — получить процесс, который гарантированно поддается реализации. Учитывая, что системы управления событиями в том виде, как они описаны (см. рис.), актуальны в основном для крупных предприятий (распределенная архитектура, предусматривающая минимум пять серверов, занимающихся только мониторингом событий, не подходит для небольших компаний), то и выбор их возможной реализации будет заключаться в анализе продуктов двух-трех компаний, которые выпускают решения для построения подобных систем. При выборе конкретного решения необходимо учесть следующие важные моменты:

• наличие функционала фильтрации, корреляции событий и использования моделей сервисов для определения влияния событий на работу бизнес-процессов;
• возможность масштабирования для повышения скорости обработки событий;
• наличие возможности интеграции с CMDB с целью реализации единого места ведения базы моделей ИТ-сервисов.

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

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

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

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

***

Редко когда большой проект реализуется в окончательном варианте с первой итерации, но у любого проекта есть первый шаг. Так почему бы его не сделать прямо сегодня, сформулировав свои запросы к процессу управления событиями?

Андрей Смольянинов (public@compulink.ru) — системный архитектор отдела систем мониторинга и управления департамента системных инженеров группы компаний «Компьюлинк» (Москва).