SavePearlHarbor

IncidentRelay месяц спустя: от маршрутизации алертов к полноценному on-call workflow

—

от автора

admin

Чуть больше месяца назад я впервые рассказал об IncidentRelay, open-source и self-hosted системе для дежурств, маршрутизации алертов и эскалаций.

В первой версии основная цепочка уже работала:

Monitoring -> Route -> On-call -> Notification -> ACK / Resolve

С тех пор проект добрался до v1.0.21-beta. Цепочка стала длиннее, но пользоваться системой стало проще. В отличие от некоторых корпоративных процессов, здесь усложнение действительно пошло на пользу.

Не буду пересказывать весь changelog. Расскажу о нескольких изменениях, которые сильнее всего повлияли на продукт.

Дежурства стали похожи на настоящие

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

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

  • участники и приоритет;

  • временные ограничения;

  • часовой пояс;

  • правила передачи смены.

Поверх расписания работают временные замены. Календарь показывает уже итоговый результат после применения всех слоёв и overrides.

Расписание можно подключить к Google Calendar, Outlook, Apple Calendar и другим клиентам через ICS или read-only CalDAV. Пользователи также могут получать уведомления о предстоящих сменах.

Появился On-call Health. Он заранее ищет пустые слои, неактивных участников, разрывы в расписании, маршруты без получателя и проблемы с каналами уведомлений.

Лучше увидеть красный индикатор днём, чем обнаружить ночью, что единственный дежурный существует только в базе данных.

Двадцать алертов теперь могут стать одним инцидентом

Одна проблема редко присылает одно аккуратное сообщение. Обычно сначала жалуется база, потом API, затем очередь, а через минуту к обсуждению присоединяется всё, у чего есть доступ к Alertmanager.

Теперь IncidentRelay умеет группировать связанные события по сервису, окружению, кластеру, имени алерта и другим labels.

Для группы можно:

  • задержать первое уведомление;

  • настроить периодические обновления;

  • выполнить ACK или Resolve сразу для всей группы;

  • объединить несколько групп вручную;

  • оставить комментарии и сохранить историю расследования.

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

Появилось понимание того, что именно сломалось

Раньше IncidentRelay хорошо отвечал на вопрос «кому отправить алерт», но почти ничего не знал о самом объекте аварии.

Теперь в системе есть каталог сервисов. Для каждого сервиса можно задать владельцев, критичность, окружение, runbooks, ссылки, правила сопоставления с алертами и зависимости от других сервисов.

На основе зависимостей система показывает:

  • возможную первопричину;

  • затронутые сервисы;

  • путь распространения проблемы;

  • общий blast radius.

Также появилась аналитика: сгруппированные инциденты, объём сырых алертов, дедупликация, уровень шума и время реакции.

Это не замена observability-платформе. Задача скромнее: избавить дежурного от традиционного ритуала поиска актуального runbook среди wiki, старого чата и ссылки, которая «точно работала в прошлом квартале».

Инцидент больше не заканчивается на ACK

ACK сообщает, что алерт кто-то увидел. К сожалению, он не ремонтирует базу данных. Мы проверяли.

Поэтому в IncidentRelay появились:

  • приоритеты от P1 до P5;

  • автоматическое повышение приоритета по severity;

  • запрос дополнительных responders;

  • stakeholders и настройки их уведомлений;

  • комментарии и timeline;

  • maintenance windows.

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

Поддерживаются часовые пояса и повторяющиеся правила RFC 5545. Потому что любое простое окно обслуживания рано или поздно превращается в «каждый второй вторник, кроме праздников и последней недели квартала».

Теперь система объясняет свои решения

Самая заметная новая функция называется Alert Explain Trace.

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

В трассе видно:

  1. Был ли принят payload.

  2. Какой route совпал.

  3. Какой service был найден.

  4. В какую группу попал алерт.

  5. Сработали ли silence или maintenance window.

  6. Как выбрали дежурного.

  7. Какие уведомления были отправлены или пропущены.

Интеграция получает trace_id, по которому результат можно открыть в UI или запросить через API.

Для self-hosted продукта прозрачность особенно важна. «Система решила именно так» звучит гораздо убедительнее, когда рядом есть список причин, а не только уверенный зелёный индикатор.

Что получилось

За месяц IncidentRelay вырос из маршрутизатора алертов в более связный workflow:

Alert -> Route -> Service -> Group -> Priority      -> Escalation -> On-call -> Responders      -> Notifications -> Resolution

Проект всё ещё находится в beta и активно развивается. Впереди новые интеграции, улучшение аналитики и более простая установка. Но уже сейчас система умеет не только разбудить дежурного, но и объяснить, почему выбрала именно его. В мире on-call это почти проявление вежливости.

Буду рад обратной связи и примерам реальных расписаний. Чем страннее график, тем полезнее тестовый сценарий.

ссылка на оригинал статьи https://habr.com/ru/articles/1050286/