Алерты мониторинга забивают очередь заявок ИТ-поддержки: каждая четырнадцатая заявка — не заявка

В очереди заявок ИТ-поддержки лежат 92 обращения с одинаковым текстом: «Критическая ошибка обновления вирусных баз на станции NB-048». Все назначены на одного инженера, все закрыты вручную, ни у одного нет оценки — потому что оценивать некому. Заявитель — служебная учётная запись антивирусной консоли.

Это 7,1% потока группы компаний за семь месяцев: каждая четырнадцатая «заявка» — не заявка. Мы нашли их при разборе 1 297 обращений и увидели за ними не одну проблему, а три. Разведём их по отдельности — потому что решаются они по-разному.

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

Откуда 64 часа в год

Считать просто. Инженер первой линии тратит на типовую заявку 24,3 минуты: открыть, посмотреть, что станция обновилась сама, закрыть, написать комментарий. 92 события × 24,3 минуты ≈ 37 часов за семь месяцев. В годовом выражении — около 64 часов, восемь рабочих дней инженера, потраченных на закрытие событий, которые могли закрыться сами.

Второй эффект не в часах. Автоуведомления искажают статистику: они занижают покрытие обратной связью (у робота нет оценок), завышают число закрытых заявок и прячут реальную нагрузку инженера, на которого попадают. В кейсе 70 из 74 антивирусных событий попали на того же инженера, который держал 60% человеческого потока.

Проблема первая: маршрутизация

Событие мониторинга попало в очередь заявок, потому что интеграция была настроена так: любое событие с уровнем «критический» → письмо → заявка. Это самый частый способ подключить мониторинг к HelpDesk, и самый вредный.

Правильная маршрутизация выглядит иначе:

• Событие живёт в контуре мониторинга, а не в очереди заявок. У него есть время возникновения, объект, состояние.
• Событие закрывается само при восстановлении. Станция обновила базы — событие закрыто, инженер его не видел и не должен был.
• События делятся на информационные и требующие действия. Первые фиксируются для истории, вторые создают задачу.
• Заявка создаётся по правилу повторяемости: N сбоев на одной станции за период или однотипный сбой на многих станциях одновременно.

При такой схеме из 92 событий в очереди оказалась бы одна задача — и это подводит ко второй проблеме.

Проблема вторая: корневая причина

74 из 92 событий — одна и та же ошибка обновления на станциях. Формально это 74 инцидента, и каждый закрыт «в срок». Фактически это один дефект в контуре обновления антивируса, который семь месяцев проявлялся на разных станциях.

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

Проблема третья: «волна»

Третья проблема не про роботов, а про людей, и она объясняет, почему службе нужен штат на приёме, а не один дежурный.

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

Регламент «волны» состоит из четырёх шагов:

1. Распознать. На приёме должно быть достаточно людей, чтобы за минуты заметить: обращения однотипны, сервис один, пользователи разные, интервал короткий.
2. Связать. Все обращения привязываются к одному инциденту. Пользователи получают общий статус, а не двадцать персональных ответов.
3. Классифицировать. Класс инцидента определяется числом затронутых пользователей и критичностью сервиса, а не тоном первого письма.
4. Закрыть волну одним действием. После восстановления связанные обращения закрываются с общей причиной и в статистике считаются одним инцидентом.

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

Как настраивать алерты, чтобы они не превращались в заявки

Три правила, которые мы применяем в мониторинге у клиентов на сопровождении:

Порог повторяемости. Одиночное событие, восстановившееся само, не создаёт ничего. Ориентир для заявки — три повтора на одной станции за неделю; для инцидента — однотипный сбой на нескольких станциях в течение часа. Пороги согласуются под инфраструктуру, а не берутся из коробки.

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

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

Итоговый регламент — с порогами, условиями автозакрытия и шагами «волны» — собран в файле «Правила обработки автоалертов мониторинга».

Пример правил для типовых событий

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

Обратите внимание на последнюю строку: у части событий правильный ответ — «не создавать задачу вообще». Без этого правила мониторинг сам становится генератором заявок, которые никто не просил.

Что сделано в кейсе

Автоуведомления антивирусной консоли выведены из очереди заявок в контур мониторинга с автозакрытием при восстановлении; заявка создаётся по правилу повторяемости. Причина серии сбоев обновления разобрана как одна инженерная задача. Эффект — минус 7% потока, чистая статистика обратной связи и около 64 часов в год, возвращённых инженерам первой линии.

Если в вашей очереди есть заявки, у которых заявитель — робот, начните с подсчёта: сколько их, сколько минут на каждую, сколько из них — одна и та же причина. Дальше — правила маршрутизации. И только потом — вопрос о том, хватает ли людей на приёме, чтобы распознать волну, когда она придёт от людей. Как устроить приём заявок так, чтобы это было возможно, — в материале об организации Help Desk.

Мониторинг, в котором событие закрывается само, а заявка появляется только по правилу повторяемости, — это мониторинг ИТ-инфраструктуры 24/7 с настройкой порогов и правил под вашу инфраструктуру.