Dopo cinque mesi di sviluppo è stato pubblicato il rilascio del progetto IncidentRelay 1.1, che sviluppa un sistema aperto per organizzare turni, instradare avvisi e gestire incidenti, avviato su un server proprio (self-hosted). IncidentRelay 1.1 è contrassegnato come il primo rilascio stabile (il ramo 1.0 aveva lo stato di versione beta). Il progetto è rivolto a team SRE, DevOps e infrastrutture che necessitano di un'alternativa localmente implementabile ai servizi SaaS per la gestione dei turni (on-call management), l’applicazione di politiche di escalation e la risposta agli incidenti. Il codice del progetto è scritto in Python e distribuito con licenza MIT.
IncidentRelay raccoglie eventi dai sistemi di monitoraggio, li associa al servizio, al team e alla rotazione, per poi consegnare notifiche ai turnisti o ai team responsabili. Il sistema implementa orari dei turni, rotazioni, ridefinizioni dei turni, conferma ricezione dell'incidente, stati ACK/Resolve, promemoria, escalation, sostituzioni temporanee dei turnisti, determinazione del tempo di operazioni programmate e soppressione di allerta moleste.
Il principale vantaggio del progetto è il completo controllo sull'infrastruttura e sulla logica di instradamento. IncidentRelay si implementa nel proprio ambiente, utilizza il proprio database e consente di distinguere chiaramente i percorsi in entrata, i team, le rotazioni e i canali di consegna. I token in ingresso appartengono ai percorsi, e non ai canali, quindi è più semplice capire quale sorgente esterna ha il diritto di inviare eventi a un team specifico.
IncidentRelay supporta la ricezione di eventi da Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch e webhook arbitrari. Per l'invio di notifiche sono disponibili canali come Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, notifiche push browser/PWA e fornitori di chiamate vocali. In Mattermost e Telegram, le notifiche possono contenere azioni per confermare e risolvere il problema, consentendo di gestire l'incidente senza dover passare a un'interfaccia separata.
Il progetto può essere avviato tramite Docker Compose, pacchetto RPM per distribuzioni simili a Red Hat, manualmente tramite systemd, e anche in Kubernetes usando un Helm chart. Per installazioni più piccole è possibile utilizzare SQLite, mentre per sistemi di lavoro e carichi maggiori si consiglia PostgreSQL.
Nella nuova versione sono state proposte le seguenti modifiche:
- Sono state aggiunte rotazioni on-call multi-livello con limitazioni temporali, priorità dei livelli e considerazione dei cambi temporanei;
- È stato introdotto un calendario delle turnazioni, con abbonamenti CalDAV e ICS per calendari esterni;
- Sono state implementate politiche di escalation degli incidenti con catene di elevazione multilivello;
- Sono stati aggiunti gruppi di avviso, raggruppamento eventi, notifiche ritardate e unione manuale di allerte correlate;
- Sono state introdotte finestre per le manutenzioni programmate e allerte 'silenziose';
- È stata aggiunta la possibilità di aggiungere commenti agli avvisi;
- Sono state aggiunte priorità degli incidenti (P1-P5) e un'auto-elevazione della priorità in base all'importanza;
- È stato implementato un catalogo dei servizi, le dipendenze dei servizi, SLI/SLO, la storia dell'impatto sui sistemi (Service Impact History) e i servizi aziendali (Business Services);
- È stato introdotto Explain Trace per analizzare la routinizzazione: perché un avviso è stato assegnato o meno a un team, è stato raggruppato, sopresso o inviato a un canale specifico;
- Sono stati aggiunti controlli (Heartbeats/dead-man-switch) per watchdog, backup, ETL e altri compiti, dove il problema è l'assenza del segnale atteso.
Fonte: opennet.ru
