Инцидент-менеджмент: как автоматизировать цепочку «обнаружение → инцидент → уведомления»

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

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

Для построения автоматизированного процесса важно разделять несколько сущностей.
Событие фиксирует изменение состояния объекта: интерфейс перешел в Down, загрузка процессора превысила порог, перестал отвечать сервер, изменилась доступность приложения.
Аварийное сообщение означает, что система интерпретировала событие как потенциально требующее внимания.

Инцидент появляется тогда, когда нарушение становится объектом эксплуатационного процесса: ему назначается приоритет, ответственный, статус, нормативное время обработки и история действий.

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

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

Обычно автоматизацию инцидентов связывают с Service Desk: автоматически создать карточку, назначить исполнителя и запустить SLA. Но качество такой автоматизации определяется гораздо раньше — на уровне обработки телеметрии и событий.

Перед созданием инцидента необходимо решить как минимум четыре задачи:
нормализовать данные → убрать повторы → найти взаимосвязанные события → определить их эксплуатационную значимость.

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

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

Более сложная задача — корреляция. Она позволяет рассматривать не отдельный сигнал, а совокупность событий и искать между ними причинно-следственные связи.

Упрощенно: отказ питания → недоступность коммутатора → недоступность серверов → недоступность приложения.

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

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

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

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

• что произошло;
• с каким объектом;
• какие связанные события зафиксированы;
• что могло стать первопричиной;
• какие сервисы затронуты;
• насколько ситуация критична.

Это меняет роль мониторинга: от регистрации отдельных отклонений система переходит к формированию эксплуатационной картины.

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

Для этого системе нужен контекст зависимостей:
оборудование → инфраструктурные компоненты → приложения → сервисы → бизнес-процессы.

Ресурсно-сервисная модель позволяет отвечать на вопросы, которые невозможно решить только по метрике устройства:

• какие сервисы используют отказавший объект;
• есть ли резервный элемент;
• какие другие компоненты зависят от него;
• кто отвечает за соответствующий сервис;
• какой уровень критичности должен получить инцидент.

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

Только после фильтрации и контекстуализации события имеет смысл переводить его в систему управления обращениями.

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

Задача автоматизации здесь не просто заменить ручное нажатие кнопки «Создать заявку». Гораздо больший эффект дает устранение промежуточной ручной обработки.
При классической схеме оператор видит проблему, копирует ее описание в Service Desk, выбирает категорию, определяет группу и передает заявку дальше. Каждая операция занимает относительно немного времени, но при большом потоке событий суммарная задержка становится значимой. При автоматизированной схеме событие уже приходит в эксплуатационный процесс классифицированным и обогащенным контекстом.

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

Автоматическая маршрутизация позволяет использовать известный системе контекст:
тип события + объект + сервис + площадка + критичность → ответственная группа.

Чем точнее ресурсная модель и правила ответственности, тем меньше требуется ручных переадресаций.

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

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

Еще одна распространенная ошибка — считать отправку сообщения завершением автоматизации.

На практике полезная цепочка выглядит сложнее:
определить ответственного → уведомить → дождаться реакции → проконтролировать нормативное время → при необходимости эскалировать.

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

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

SLA полезен не только для итоговой статистики. При корректной автоматизации нормативы должны влиять на работу с инцидентом непосредственно во время его обработки.

Для разных категорий можно определить:

• допустимое время до принятия в работу;
• время восстановления;
• правила изменения приоритета;
• количество уровней эскалации;
• ответственных на каждом уровне.

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

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

Полезнее разделять жизненный цикл инцидента на интервалы.
MTTD — Mean Time to Detect. Сколько времени проходит между возникновением проблемы и ее обнаружением.
MTTA — Mean Time to Acknowledge. Сколько проходит до того момента, когда инцидент принят в работу.
MTTR — Mean Time to Repair / Recovery / Resolve. В зависимости от принятой методики — время ремонта, восстановления или полного решения. Определение необходимо зафиксировать заранее, иначе сравнение показателей теряет смысл.

Кроме них полезно отслеживать:

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

Так можно определить реальное узкое место. Если MTTD составляет секунды, а инженер начинает диагностику через двадцать минут, дальнейшее ускорение сбора метрик почти ничего не изменит. Оптимизировать необходимо процесс между мониторингом и человеком.

Рост интереса к AIOps создает впечатление, что следующее поколение инцидент менеджмента обязательно должно строиться вокруг искусственного интеллекта. На практике ИИ имеет смысл рассматривать как дополнительный уровень автоматизации уже структурированного процесса.

Алгоритмы могут быть полезны для:

• поиска аномалий;
• группировки похожих событий;
• классификации инцидентов;
• анализа исторических случаев;
• подготовки краткой сводки;
• поиска подходящих инструкций;
• рекомендаций по маршрутизации.

Но если в инфраструктуре нет качественной ресурсной модели, единых правил классификации и накопленной истории, интеллектуальному алгоритму также будет сложно правильно определить контекст.

Поэтому последовательность зрелости скорее выглядит так:
централизованный мониторинг → нормализация → корреляция → сервисная модель → автоматический инцидент → маршрутизация → уведомление и эскалация → аналитика → AIOps.

Искусственный интеллект может усиливать эту цепочку, но не заменяет ее основу.

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

В продуктовом портфеле «Теком» этим задачам соответствуют разные решения.

ЦИСУСС «NB XT EM» — зонтичная система мониторинга и управления сетями связи и ИТ-инфраструктурой. Она предназначена для централизованного контроля оборудования, сервисов и инфраструктуры и может стать источником первостепенной технической информации о состоянии контролируемых объектов. Система поддерживает работу с сетевыми и несетевыми интерфейсами, а также централизованное управление инфраструктурой.

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

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

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

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

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