Завершая серию про INC...
Раньше у меня была довольно простая схема: есть политика мониторинга, в которой написано, когда и кого будим, в зависимости от уровня критичности.
Но в текущей компании пошли намного глубже — и теперь у каждого алерта есть свой эскалационный план.
Не просто "если алерт случился — бегает слева направо покругу и кричим "ААААА", а четкий, прописанный, проверенный маршрут действий.
И это реально game-changer. Особенно когда ночью, особенно когда прод, особенно когда алерт летит не в одну, а сразу в несколько команд.
🔧 Из чего состоит эскалационный план
1️⃣ Level = Уровень критичности.
Выбирается один из предопределенных:
🟥 Blocker — будим всех, даже в выходной, даже ночью.
🟧 Critical — реагируем немедленно, но в рабочее время.
🟨 Major / Normal / Minor — плановое реагирование, включение в работу через приоритизацию.
Важная фишка — учет выходных: если алерт случается в пятницу или перед длинными выходными — он может перескакивать в более высокий уровень, потому что просто ждать понедельника нельзя!
2️⃣ Event = Формулировка самого алерта
То сообщение и место его публикации, которое запускает всю цепочку.
3️⃣ Event Description & Printscreen
Расширенное описание:
— на что конкретно настроен алерт (обязательно указание сервиса, механизма, направления),
— на что он влияет — влияние на бизнес, мерчантов, пользователей, отчеты, финансы, процессы, и т.д.,
— скриншоты из систем мониторинга (Графана, Кибана и др.), чтобы даже в полусне понять: да, это оно!
Важно учесть, что первыми, кто будут читать и проверять алерт - будет команда мониторинга, а они могут не знать тонкостей и особенностей работы каждого сервиса!
4️⃣ Event Flow — уровни эскалации
Это самое важное — что происходит после алерта, кто включается, и в каком порядке.
Уровень 1: Мониторинг (обязательный)
Коллеги получают сигнал и:
— проверяют ключевые метрики,
— выполняют первичную диагностику (например, “живо/не живо”, “ошибки растут/не растут”),
— принимают решение: нужно ли эскалировать дальше,
— документируют происходящее.
Уровень 2: SRE или команда (вариативный)
Если мониторинг передает эстафету — подключается:
✅ SRE — у них есть доступ к продакшену, и они могут:
— дособрать информацию (логи, текущие состояния, доп. графики),
— выполнить ручные или полуручные стабилизирующие действия,
— передать все это в команду с комментарием "готово к разбору".
✅ Команда — основной владелец сервиса/фичи.
План должен включать:
— четкие шаги: что проверять, куда смотреть, в каком порядке,
— если нужен другой отдел/команда/бизнес — план, как их привлекать,
— стабилизационные действия на случай, если полноценный фикс не может быть выполнен сразу.
5️⃣ Links & Resources
Ссылки на нужные источники: Графана, Кибана, БОФ, админки.
Справочные материалы:
— как работает сервис,
— какие у него зависимости,
— какие проблемы могут вызывать этот алерт.
Примеры прошлых инцидентов:
— с похожими симптомами,
— что помогло тогда,
— что можно применить снова
Почему это важно?
Потому что алерт сам по себе — это просто крик.
Когда у тебя нет плана, включаются хаос и эмоции.
Когда план есть — включается система.
🔄 А что делать, если алерт задевает сразу несколько команд?
Например:
Kafka показывает, что очередь растет.
Но виноват не Kafka, а сервис, который перестал забирать сообщения.
А может, и не один.
А может, вообще проблема в данных, которые не соответствуют контракту.
Алерт один — команд три.
🔺 В таких случаях алерт должен быть вынесен на уровень всей компании, с общекорпоративным маршрутом, как раскидывать ответственность, назначать лидов, собирать группы быстрого реагирования.
📌 Эта практика кажется объемной только в начале. Но потом — просто становится новым стандартом.
Ты не пишешь ночью в три чатика и не собираешь непонятно кого, а открываешь эскалационный план. И делаешь.
💬 А у вас есть такие планы по алертам?
Кто их составляет? Кто обновляет?