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

1. Откуда берётся шум

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

• Пороги «чтобы точно не пропустить». После крупной аварии порог опускают с запасом. Аварий такого рода больше не случается, а срабатывания остаются - и через год никто уже не помнит, почему загрузка диска в 70% считается поводом для звонка.
• Наблюдение за объектами вместо наблюдения за услугой. Мониторинг заводится по инвентарю: каждый узел, каждый интерфейс, каждый диск. Один отказ коммутатора превращается в несколько десятков сообщений о недоступности всего, что за ним стоит.
• Нет подавления на время работ. Плановое обслуживание, перезагрузка после обновления, переключение на резерв - всё это порождает штатный поток аварийных сообщений, который команда научилась игнорировать. А заодно научилась игнорировать похожие сообщения в остальное время.
• Мерцание (flapping). Канал или служба уходят и возвращаются несколько раз за минуту. Каждый переход - пара сообщений. Реального инцидента может не быть вовсе, а десяток строк в ленте уже есть.
• События без адресата. Сигнал приходит в общий чат или на общий ящик, где за него не отвечает конкретный человек. Такое событие не обрабатывается - оно прочитывается.
• Наследство от ушедших систем и людей. Проверки, заведённые под сервис, которого больше нет; правила, написанные инженером, который уволился три года назад. Отключить их страшно, потому что никто не знает, что сломается.

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

2. Чем измерить долю шума

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

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

3. Событие и правило одного адресата

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

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

4. Семь шагов сокращения потока

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

1. Дедупликация. Повторное сообщение об уже открытом состоянии обновляет существующее событие, а не создаёт новое. Один отказ - одна строка в ленте, со счётчиком повторов.
2. Окна плановых работ. Подавление оповещений на время обслуживания, привязанное к календарю изменений. Побочный эффект важнее основного: подавление невозможно без честного календаря - и календарь появляется.
3. Выдержка времени перед оповещением. Состояние должно продержаться заданное время, прежде чем породить сигнал. Убирает мерцание целиком, не трогая пороги.
4. Удаление сигналов без действия. Берём список правил, отсортированный по числу срабатываний, и по каждому из верхних задаём один вопрос: что человек делает, получив это? Нет ответа - правило переводится в журнал. Не отключается совсем, а перестаёт будить.
5. Пороги по данным, а не по интуиции. Порог ставится от фактического распределения показателя за несколько месяцев, а не от круглого числа. «90% диска» - это круглое число; «уровень, выше которого показатель был 2% времени и каждый раз это заканчивалось инцидентом» - это порог.
6. Корреляция по зависимостям. Если известно, что за коммутатором стоят двадцать узлов, отказ коммутатора порождает одно событие, а не двадцать одно. Требует хотя бы грубой карты зависимостей - и это самый долгий шаг из семи.
7. Регулярный пересмотр. Раз в квартал - полчаса на просмотр верхушки списка по числу срабатываний и списка правил, не срабатывавших ни разу. Первые шумят, вторые, скорее всего, сломаны и молчат не потому, что всё хорошо.

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

5. Приоритет: влияние и срочность

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

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

Ещё одна деталь, которая экономит много ночных споров: потеря резерва - это P2, а не P3. Услуга работает, клиент ничего не замечает, и соблазн отложить до утра велик. Но система в этот момент находится в состоянии, где любой следующий отказ - критический, и запас времени, заложенный резервированием, уже потрачен.

6. Матрица эскалации: кто, когда, за сколько

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

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

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

7. Когда будить руководителя

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

• Затронут клиент или деньги. Услуга, которой пользуются снаружи, недоступна или искажает данные. Не «может быть затронут», а есть признак, что уже затронут.
• Нужно решение, которого у дежурного нет права принимать. Отключить часть функциональности, откатить релиз, переключить площадку, выдать доступ, потратить деньги, привлечь подрядчика вне договора.
• Требуется общение наружу. Клиенты, регулятор, пресса, крупный партнёр. Молчание в этот момент обходится дороже самой аварии, а говорить от лица компании дежурный не должен.
• Прогноз хуже факта. Сейчас работает, но развитие событий ведёт к критическому: заканчивается место, растёт очередь, отказал резерв, авария у поставщика расширяется. Разбудить на этом этапе дешевле, чем через два часа.

К правилу прилагаются две страховки, и без них оно не живёт. «Разбудили зря» не является ошибкой дежурного, если сработал один из критериев: разбирают правило, а не человека. И наоборот, «не разбудили, когда было надо» разбирается обязательно - но как дефект правила, а не как проступок. Обе страховки нужны, чтобы критерии оставались инструментом, а не поводом для претензий: команда, которую отчитали за ночной звонок один раз, больше не позвонит никогда.

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

8. Что из этого видно в данных

Всё описанное выше проверяется по обычной выгрузке за полгода - журналу событий из системы мониторинга и журналу инцидентов из тикет-системы. Не по опросу команды: опрос показывает представления, выгрузка - поведение.

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