Мы выпустили начальный стабильный выпуск 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’ы и бизнес-сервисы. А потом всё это ещё надо нормально показать в пользовательский интерфейс. Граф зависимостей тоже не рисуется сам: если дать ему свободу, он быстро превращается в макароны с подписями. Пришлось отдельно думать про 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/