Open-source DevOps on-call

Open-source on-call management per DevOps team.

DevOps i team possono collegare monitoraggio, orari, matcher di route, politiche di escalation e canali di notifica in un flusso di lavoro self-hosted.

Esempi funzionanti per IncidentRelay v2.3.1, verificati il ​​. I nomi, gli identificatori e i tempi riportati di seguito sono illustrativi; convalidarli in una distribuzione di prova prima di utilizzare le credenziali di produzione.

Esempio aziendale · Configurazione · Esempio pratico · Controlli di accettazione · Limiti e modalità di errore

Esempio aziendale: un backup notturno non termina mai

Scenario illustrativo, non case study del cliente. Le metriche riportate di seguito sono suggerimenti per il tuo progetto pilota, non risparmi misurati o un'affermazione secondo cui l'IR include ogni dashboard di reporting.

Situazione e rischio. Un'azienda esegue il backup del database degli ordini su due server prima dell'inizio della giornata lavorativa. Un lavoro si interrompe silenziosamente; l'altro ci riesce. Un unico segnale di successo condiviso nasconderebbe il divario. Il rischio aziendale è quello di scoprire un punto di ripristino vecchio o mancante solo quando è necessario un ripristino.

Flusso di lavoro con IR. Definisci una scadenza per il completamento e monitora separatamente ciascun server previsto. Un host invia il proprio heartbeat solo al termine delle verifiche del lavoro e dell'esito positivo. Un completamento mancante crea un avviso di ritardo instradato al risponditore della piattaforma, con un percorso di escalation di backup. L'ingegnere indaga o riesegue il lavoro e registra il risultato.

Vantaggio operativo da convalidare. Trasforma un errore silenzioso di un processo pianificato in un'attività posseduta prima del successivo turno aziendale. Lo stesso modello può riguardare un'esportazione pianificata o un lavoro batch, a condizione che il segnale di completamento rappresenti realmente il successo.

Che cosa misurare. Tieni traccia delle scadenze non rispettate per server, del tempo trascorso dalla scadenza alla conferma e dell'età dell'ultimo backup verificato. Conservare la verifica del backup e i risultati delle esercitazioni di ripristino nel sistema di backup o nel report delle operazioni; non dedurli da un battito cardiaco verde.

Confine. Un battito cardiaco dimostra che è arrivato un segnale, non che i dati possono essere ripristinati. Non garantisce un punto di ripristino o un tempo di ripristino. Testare i ripristini in modo indipendente e monitorare l'IR stesso dall'esterno dello stesso dominio di errore.

Tratta il sistema di cercapersone come un servizio che gestisci

Considera un team della piattaforma che possiede un cluster di produzione e backup notturni del database. Vuole l'IR vicino al suo stack di monitoraggio, ma ciò rende anche il team responsabile del sistema che lo riattiva. Assegnare un proprietario per il servizio Web, lo scheduler, il database, i segreti e la procedura di ripristino.

La configurazione della versione Docker esegue i servizi Web e di pianificazione separatamente. Dopo aver seguito la guida alla distribuzione in un ambiente di test, esaminali dal checkout del rilascio:

docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-scheduler

Il processo web accetta avvisi in arrivo; lo programmatore gestisce promemoria, escalation e lavori periodici. Non avviare uno scheduler all'interno di ogni web worker. Una pagina di accesso funzionante non dimostra che sia in corso un'escalation temporizzata.

Rileva un backup mancante su un host

Crea un heartbeat di completamento programmato con scadenza giornaliera alle 03:00 UTC, collegato a un percorso la cui origine è heartbeat. Abilita il monitoraggio delle istanze; per un parco istanze fisse, utilizzare istanze previste statiche come db-1 e db-2. Allega la rotazione o la policy della piattaforma e testa i canali.

Al termine del backup di un host e dei relativi controlli di esito positivo, invia questo corpo a POST /api/heartbeats/ping/HEARTBEAT_TOKEN con tipo di contenuto JSON. Utilizza l'URL segreto di quell'heartbeat, non un token di instradamento o un token API amministrativo.

{
  "status": "completed",
  "instance": "db-1",
  "payload": {
    "job": "nightly-database-backup"
  }
}

Invia un valore di istanza distinto da ciascun host. Senza il monitoraggio delle istanze, un ping riuscito da un server può nascondere il backup mancante di un altro server. Non inviare incondizionatamente un ping di successo da un gestore di pulizia della shell dopo un lavoro non riuscito. Oscura gli URL ping segreti dal proxy e dai registri dei lavori.

Fallimento del test, non solo avvio

  1. Effettua il ping di entrambe le istanze previste, quindi omettine deliberatamente una in un breve programma di test. È previsto un avviso di ritardo per quell'istanza mentre l'istanza integra rimane OK.
  2. Riprendi l'istanza mancante. Se la risoluzione automatica è abilitata, verifica che l'avviso di ritardo si risolva senza risolvere l'errore di un'altra istanza.
  3. Arrestare lo scheduler solo nella distribuzione di prova. Osservare l'effetto sul lavoro a tempo e dimostrare che un monitor indipendente lo nota; quindi ripristinarlo e verificare l'elaborazione.
  4. Ripristina il database, la configurazione e i segreti richiesti in un ambiente isolato con le notifiche in uscita bloccate. Esaminare i vecchi gruppi di attivazione prima di consentire la consegna, in modo che un'esercitazione di ripristino non possa richiamare i risponditori di produzione.

Un ping di successo non è un test di ripristino

I battiti cardiaci rilevano i segnali mancanti; non sono sonde HTTP/TCP attive e non possono dimostrare che un backup sia utilizzabile. Inoltre, IR non può avvisarti in modo affidabile della propria interruzione totale. Mantenere un controllo della disponibilità esterna e un percorso di contatto separato all'esterno dello stesso dominio di errore.

L'hosting autonomo non rimuove le dipendenze da chat, e-mail, voce o rete. Decidi quale database e modello di distribuzione si adattano al carico di lavoro, blocca la versione testata e prova gli aggiornamenti e il rollback. Questi esempi non stabiliscono una disponibilità elevata o una garanzia di velocità effettiva.

Imposta deliberatamente la conservazione: la cronologia degli avvisi risolti viene conservata a tempo indeterminato per impostazione predefinita. La pulizia può anche rimuovere commenti collegati e record di consegna e non necessariamente riduce il file di database. La conservazione non sostituisce i backup.