Мы выпустили первый стабильный релиз IncidentRelay 1.1

Если коротко, IncidentRelay — это open-source self-hosted система для on-call дежурств, маршрутизации алертов и incident response. То есть штука, которая отвечает на вечный вопрос: “Кому сейчас прилетел алерт, почему именно ему, и почему он уже третий раз сегодня смотрит в телефон с лицом человека, который всё понял”.

Проект нужен командам, которые хотят держать on-call процесс у себя: в своей инфраструктуре, со своей базой, своими правилами маршрутизации и без обязательной привязки к большой SaaS-платформе. Monitoring system отправляет событие в IncidentRelay, дальше оно проходит через route intake token, матчится с сервисом, командой, ротацией, текущим дежурным и уходит в нужные каналы: Mattermost, Slack, Telegram, email, browser push, webhook, voice call и так далее.

Почему мы это сделали? Потому что в реальной эксплуатации часто нужна не “большая платформа для управления цифровой трансформацией инцидентного опыта”, а понятная цепочка:

alert -> route -> team -> rotation -> human -> ACK / Resolve

И желательно, чтобы эту цепочку можно было объяснить утром после ночного инцидента, не открывая три вкладки документации, два SaaS-аккаунта и один философский трактат.

С первой версии IncidentRelay сильно вырос. В 1.1 появились:

многоуровневые on-call ротации;

календарь дежурств, CalDAV и ICS-подписки;

escalation policies;

alert groups и группировка событий;

maintenance windows, silences и комментарии;

приоритеты P1-P5;

сервисный каталог;

зависимости сервисов;

Service Impact, blast radius и root cause context;

SLI/SLO;

Business Services;

Explain Trace;

Heartbeats/dead-man-switch проверки;

multi-instance heartbeats;

интеграции с Alertmanager, Grafana, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch и generic webhook.

Самой интересной и местами самой вредной частью оказалась логика Service Impact. На бумаге всё просто: есть сервисы, есть зависимости, есть алерты, надо понять, что реально сломалось, что пострадало рядом, а что просто шумит в углу. На практике быстро выясняется, что dependency graph не любит оптимистов.

Нужно было продумать, как считать влияние upstream/downstream сервисов, как не превратить каждый красный алерт в “у нас всё сломалось”, как учитывать criticality, severity, priority, maintenance windows, ручные override’ы и бизнес-сервисы. А потом всё это ещё надо нормально показать в UI. Граф зависимостей тоже не рисуется сам: если дать ему свободу, он быстро превращается в макароны с подписями. Пришлось отдельно думать про layout, уровни, читаемость, подсветку root cause и downstream impact.

Отдельная боль — Explain Trace. Мы хотели, чтобы было видно не только “алерт пришёл”, но и почему он попал именно в эту команду, почему сгруппировался, почему был подавлен или почему уведомление ушло таким способом. Это сильно помогает при разборе инцидентов, но заставляет аккуратно логировать решения системы, а не просто радостно писать “processed=true”.

В 1.1 также появились Heartbeats. Это dead-man-switch проверки для случаев, когда проблема не в том, что что-то прислало ошибку, а в том, что оно подозрительно молчит. Например, backup job, ETL, watchdog, агент на сервере. Если ожидаемый ping не пришёл, IncidentRelay создаёт обычный routed alert. Для fleet-сценариев есть multi-instance режим: один здоровый сервер больше не может прикрывать остальных, которые давно ушли пить чай без предупреждения.

Разворачивать IncidentRelay можно через Docker Compose, RPM для Red Hat-like систем, systemd или Helm chart. Для небольших установок подойдёт SQLite, для production лучше PostgreSQL.

Код открыт под MIT.

GitHub: https://github.com/roxy-wi/IncidentRelay

Сайт и документация: https://incidentrelay.io/