Чуть больше месяца назад я впервые рассказал об 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 записывает этапы обработки входящего события.
В трассе видно:
Был ли принят payload.
Какой route совпал.
Какой service был найден.
В какую группу попал алерт.
Сработали ли silence или maintenance window.
Как выбрали дежурного.
Какие уведомления были отправлены или пропущены.
Интеграция получает trace_id, по которому результат можно открыть в UI или запросить через API.
Для self-hosted продукта прозрачность особенно важна. «Система решила именно так» звучит гораздо убедительнее, когда рядом есть список причин, а не только уверенный зелёный индикатор.
Что получилось
За месяц IncidentRelay вырос из маршрутизатора алертов в более связный workflow:
Alert -> Route -> Service -> Group -> Priority
-> Escalation -> On-call -> Responders
-> Notifications -> Resolution
Проект всё ещё находится в beta и активно развивается. Впереди новые интеграции, улучшение аналитики и более простая установка. Но уже сейчас система умеет не только разбудить дежурного, но и объяснить, почему выбрала именно его. В мире on-call это почти проявление вежливости.
Буду рад обратной связи и примерам реальных расписаний. Чем страннее график, тем полезнее тестовый сценарий.