Perché ospitare una piattaforma on-call?
I sistemi on-call contengono dati operativi sensibili: orari dei dipendenti, dettagli di contatto, carichi di avviso, nomi dei servizi, tempi di incidente e link ai sistemi interni. Alcune squadre preferiscono mantenere queste informazioni all'interno della propria rete e database.
Self-hosting offre anche il controllo dei team sui tempi di distribuzione, le integrazioni, la ritenzione, i backup e i confini di accesso. Il trade-off è semplice: si gestisce la piattaforma e possiede la sua disponibilità. Non c'è nuvola magica, solo un computer che riceve fatture da qualche altra parte.
Cosa? IncidentRelay incluso
- Orari di chiamata, strati di rotazione e sovrascritti temporanei.
- Avviso di instradamento per Alertmanager, Zabbix, Sentry e webhooks generici.
- Politiche di escalation, promemoria e richieste di risposta.
- Servizi, dipendenze, finestre di manutenzione e priorità incidenti.
- Mattermost, Telegram, e-mail, browser push, webhook e notifiche vocali.
- Personal API token e Open API documentazione.
Scelte di distribuzione
IncidentRelay supporta diversi modelli di distribuzione in modo che i team possano utilizzare strumenti operativi familiari.
| Metodo | Uso tipico |
|---|---|
| Docker Compose | Valutazione, ambienti più piccoli e semplici distribuzioni dei container. |
| Pacchetti RPM | I sistemi Linux Red Hat gestiti tramite pacchetti e flussi di lavoro sistemati. |
| Sistema manuale | Distribuzioni basate su sorgenti e ambienti Python personalizzati. |
| Helm Grafico | Kubernetes distribuzioni con web separato, programmatore e lavoratori facoltativi Telegram. |
Scelte di database e scaling
SQLite è disponibile per installazioni a singolo nodo. PostgreSQL è la scelta pratica per ambienti più grandi o più lunghi, volume di allerta più elevato e distribuzioni con più dipendenti web. Il programmatore funziona come un processo separato, quindi i promemoria e le escalation non sono duplicati tra i lavoratori web.
Integrare con lo stack già eseguito
IncidentRelay agisce come uno strato di routing tra i sistemi di monitoraggio, la proprietà dei servizi, gli orari e le destinazioni di notifica. I percorsi hanno i propri gettoni di aspirazione e determinano dove vanno gli avvisi in arrivo. I canali descrivono come viene notificato il rispondente selezionato.
Webhooks generici e Open API endpoints permettono di collegare strumenti interni senza aspettare un'integrazione specifica del fornitore. I fornitori di voce personalizzati possono essere installati per le squadre che operano il proprio flusso di lavoro di telefonia.
Responsabilità operative
Una piattaforma di incidente self-hosted dovrebbe essere trattata come infrastruttura di produzione. Pianificare i backup dei database, monitorare i servizi web e scheduler, testare i canali di notifica e mantenere un percorso di emergenza per incidenti che interessano IncidentRelay stesso.
Le API, la configurazione e lo schema possono evolversi tra le versioni, quindi rivedere le note di rilascio e gli aggiornamenti di prova prima del rollout di produzione.