Dopo cinque mesi di sviluppo, è stata pubblicata la versione 1.1 del progetto IncidentRelay, che sviluppa un sistema open source per l'organizzazione dei turni, la gestione degli avvisi e il supporto agli incidenti, da eseguire su un server proprio (self-hosted). IncidentRelay 1.1 è stato contrassegnato come il primo rilascio stabile (il ramo 1.0 aveva lo stato di versione beta). Il progetto è destinato a team SRE, DevOps e infrastrutture che necessitano di un'alternativa locale ai servizi SaaS per la gestione dei turni, l'applicazione di politiche di escalation e la risposta agli incidenti. Il codice del progetto è scritto in Python e distribuito con licenza MIT.
IncidentRelay riceve eventi dai sistemi di monitoraggio, li associa a un servizio, un team e una rotazione, dopo di che invia notifiche ai turnisti responsabili o ai team. Il sistema implementa pianificazioni dei turni, rotazioni, ridefinizioni dei turni, conferma della ricezione di un incidente, stati ACK/Resolve, promemoria, escalation, sostituzioni temporanee dei turnisti, definizione dei tempi per le operazioni programmate e soppressione degli avvisi eccessivi.
Il principale vantaggio del progetto è il pieno controllo sull'infrastruttura e sulla logica di routing. IncidentRelay viene distribuito nel proprio ambiente, utilizza il proprio database e consente di separare chiaramente i percorsi in arrivo, i comandi, le rotazioni e i canali di consegna. I token in arrivo appartengono ai percorsi, e non ai canali, rendendo più semplice capire quale fonte esterna ha il diritto di inviare eventi a un particolare comando.
IncidentRelay supporta la ricezione di eventi da Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch e webhook personalizzati. I canali per l'invio di notifiche includono Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, notifiche push per browser/PWA e fornitori di chiamate vocali. In Mattermost e Telegram, le notifiche possono contenere azioni per confermare e risolvere il problema, permettendo di gestire l'incidente senza dover passare a un'interfaccia separata.
Il progetto può essere avviato tramite Docker Compose, un pacchetto RPM per distribuzioni simili a Red Hat, manualmente tramite systemd, e anche in Kubernetes utilizzando un Helm chart. Per installazioni di piccole dimensioni è possibile utilizzare SQLite, mentre per sistemi di lavoro e carichi maggiori si raccomanda PostgreSQL.
Nella nuova versione sono state proposte le seguenti modifiche:
- Sono state aggiunte rotazioni on-call multi-livello con limitazioni di tempo, priorità dei livelli e considerazione delle sostituzioni temporanee;
- È stato introdotto un calendario di turni, con sottoscrizioni CalDAV e ICS per calendari esterni;
- Sono state implementate politiche di escalation degli incidenti con catene di elevazione a più fasi;
- Sono stati aggiunti gruppi di avviso, raggruppamento di eventi, notifiche ritardate e unione manuale di avvisi correlati;
- Sono state introdotte finestre per effettuare lavori programmati e avvisi 'silenziosi';
- È stata aggiunta la possibilità di aggiungere commenti agli avvisi;
- Sono state introdotte priorità per gli incidenti (P1-P5) e l'innalzamento automatico della priorità in base al livello di importanza;
- Sono stati realizzati un catalogo dei servizi, dipendenze dei servizi, SLI/SLO, storia dell'impatto sui sistemi (Service Impact History) e servizi aziendali (Business Services);
- È stata implementata la funzione Explain Trace per analizzare il routing: perché l'avviso è stato incluso o meno nel team, è stato raggruppato, silenziato o inviato a un canale specifico;
- Sono stati aggiunti controlli (Heartbeats/dead-man-switch) per watchdog, backup, ETL e altre attività in cui il problema è l'assenza del segnale atteso.
Fonte: opennet.ru
