Если коротко, 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/
ссылка на оригинал статьи https://habr.com/ru/articles/1058410/