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

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

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

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

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

2. Чем измерить шум

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ITIL эскалация бывает двух видов, и смешивать их не стоит. Функциональная: задача переходит к тому, у кого больше знаний или прав - от дежурного к инженеру по направлению, дальше к производителю или подрядчику. Её уровни принято называть линиями поддержки: L1, L2, L3. Иерархическая: вопрос поднимается по управленческой линии, когда нужны решения, деньги, приоритеты или общение с внешним миром. Первая ускоряет починку, вторая снимает препятствия; один инцидент может требовать обеих. Обозначения M1 и M2 в таблице - наши, для краткости.

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

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

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

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

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

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

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

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

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

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