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: il checkout fallisce dopo la chiusura dell'ufficio
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 negozio online ha quattro ingegneri. Alle 22:40, il suo monitoraggio rileva le richieste di pagamento non riuscite mentre i clienti stanno ancora effettuando il pagamento. Un messaggio nella chat generale non dice al supporto chi sta gestendo il problema. Gli acquisti non completati e una coda di supporto crescente sono il rischio aziendale; l'avviso stesso è solo il segnale.
Flusso di lavoro con IR. Invia l'avviso di fatturazione al risponditore principale corrente. Se nessuno lo riconosce, la policy si sposta sul backup denominato. L'ingegnere incaricato riconosce il gruppo e indaga; il supporto può utilizzare il processo di incidente concordato per trovare il proprietario e ottenere un aggiornamento. Testare questa catena con la coppia di errore e ripristino di seguito.
Vantaggio operativo da convalidare. Sostituisci la ricerca manuale di un tecnico disponibile con una catena di proprietà predefinita. Mantieni visibile la responsabilità attraverso il trasferimento anziché dare per scontato che un messaggio di chat consegnato significhi che qualcuno ci sta lavorando.
Che cosa misurare. Registra il tempo trascorso dal primo avviso utilizzabile al ACK, la condivisione riconosciuta all'interno del tuo target interno e il numero di riassegnazioni manuali. Tieni traccia separatamente dei checkout non riusciti e del tempo trascorso fino alla ripresa dei pagamenti riusciti nel monitoraggio del commercio.
Boundary. IR non ripara il checkout o un fornitore di servizi di pagamento. Un ACK non dimostra che i clienti possono pagare di nuovo e una politica di escalation non può essere d'aiuto se nessuno dei due ingegneri è raggiungibile. Conserva il percorso di contatto di riserva e un controllo reale del recupero del pagamento.
Quattro ingegneri, un servizio di fatturazione, una catena di proprietà
Supponiamo che quattro ingegneri condividano il supporto per una fatturazione API. Inizia con una squadra e una rotazione primaria settimanale. Assegna al percorso un servizio predefinito e un canale di consegna testato. Aggiungere esplicitamente una persona di backup; una chat room condivisa non è una politica di escalation.
| Oggetto | Impostazione di esempio nell'interfaccia utente |
|---|---|
| Proprietario | Squadra payments; servizio billing-api; rotazione payments-primary con quattro membri attivi e copertura 24/7. |
| Assunzione | Origine webhook, servizio predefinito billing-api, modalità di escalation dei criteri e canali di notifica allegati. |
| Escalation | Regola 1: rotazione primaria, ritardo 300 secondi. Regola 2: un utente di backup denominato, ritarda 600 secondi. Imposta repeat_count=0 per questo pilota. |
Configura i canali e i contatti del risponditore prima di inviare un avviso. Apri la Diagnostica salute di guardia completa: il riepilogo della tabella verde da solo non analizza la copertura futura né prova che un messaggio raggiunga un telefono.
Invia un errore, quindi il suo ripristino
Invia questi JSON corpi separatamente a POST /api/integrations/webhook con Content-Type: application/json e Authorization: Bearer ROUTE_TOKEN. Sostituisci il segnaposto con il token del percorso di prova dall'interfaccia utente; tenerlo fuori dal controllo del codice sorgente e dai registri condivisi. Questo è il formato webhook generico, non un evento simulatore normalizzato.
{
"status": "firing",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}{
"status": "resolved",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}Mantieni lo stesso percorso, impronta digitale ed etichette di raggruppamento per il ripristino. L'impronta digitale identifica il child alert; modificandolo con un nuovo valore casuale a ogni richiesta si annulla la deduplicazione. Un ripristino orfano non crea un nuovo gruppo.
Metti alla prova la catena prima di un vero turno di notte
- Invia il corpo sparante due volte. Aspettatevi un avviso bambino, il servizio previsto e l'attuale assegnatario principale; confermare la consegna effettiva, non solo un successo HTTP.
- Lasciare non riconosciuto un avviso di test separato. Verificare che il backup diventi la destinazione dopo il primo ritardo della politica. La cadenza dello scheduler, le code e la consegna del fornitore indicano che non si tratta di uno SLA di consegna esatto di cinque minuti.
- Riconoscere un altro gruppo di test e verificare che le notifiche di sola attivazione in sospeso vengano interrotte. Invia recupero e conferma che il gruppo si risolve quando non rimangono più bambini licenziati.
- Creare una sostituzione temporanea della rotazione e ripetere il test. Confermare che l'override sia l'effettivo assegnatario, quindi rimuovere la configurazione di test.
Sapere quando la catena si ferma
Nella modalità criterio, l'escalation basata sui promemoria del team viene ignorata. Una volta esaurite tutte le regole e le ripetizioni consentite, i promemoria dei criteri si interrompono; l'avviso può ancora essere attivato. Una persona di riserva senza dettagli di contatto funzionanti è solo un nome in un database.
ACK è proprietà, non recupero del servizio di fatturazione. IR non può riparare l'applicazione né fornire un tecnico scomparso. Mantieni un modo esterno per raggiungere il team se IR o il suo fornitore di notifiche non sono disponibili e concorda tale fallback durante l'onboarding.