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: i clienti SaaS lavorano in diversi fusi orari
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 team SaaS B2B serve clienti in Europa e Nord America. Il pomeriggio lavorativo di un cliente si sovrappone alla serata di un altro tecnico e l'operatore abituale è in vacanza. Senza un programma concordato, il team si affida a chi nota per primo la chat. Il rischio è un blackout senza proprietario e ripetute interruzioni per il personale fuori servizio.
Flusso di lavoro con IR. Concorda la copertura con personale, quindi rappresentala con una rotazione di base e un livello di giorni lavorativi. Registra le sostituzioni delle festività come sostituzioni e configura una destinazione di escalation di backup separata. Controllare i passaggi di consegne e le lacune future. Per una distribuzione della fatturazione pianificata, utilizza una finestra di manutenzione con ambito di servizio mentre i servizi non correlati continuano a inviare notifiche.
Vantaggio operativo derivante dalla convalida. Rendi prevedibile la responsabilità per il supporto e la progettazione, compresi congedi e passaggi di consegne. Il lavoro pianificato non dovrebbe richiedere la disattivazione del flusso di avvisi dell'intera azienda.
Che cosa misurare. Esamina i minuti non coperti in un periodo futuro definito, ad esempio i prossimi 14 giorni, i passaggi manuali dell'ultimo minuto e i riconoscimenti all'interno dell'obiettivo di risposta del team. Confrontare le notifiche notturne per ingegnere con il programma effettivo del personale; un calendario equilibrato da solo non mostra il carico di lavoro.
Confine. Un calendario pieno non crea personale aggiuntivo né dimostra che qualcuno possa rispondere. IR non garantisce tempi di risposta contrattuali né calcola la disponibilità del cliente dagli ACK. Mantieni le decisioni relative al personale, il monitoraggio degli SLO e la comunicazione con i clienti nel processo operativo più ampio.
Coprire la notte prima ottimizzando la giornata lavorativa
Supponiamo che un team SRE possieda l'affidabilità della fatturazione durante un turno di un giorno lavorativo e un turno notturno. In una rotazione, crea un livello di base con priorità 10 e copertura illimitata 24/7. Aggiungi un livello con priorità 20, limitato a lunedì-venerdì, 09:00-18:00 in Europe/Berlin. Utilizza membri attivi reali e verifica il calendario generato.
Il livello attivo con la priorità più alta fornisce l'assegnatario; una sostituzione ha la precedenza sui livelli. Questi non sono due risponditori simultanei. Configurare una destinazione di escalation o una rotazione separata per la copertura del backup. Se nessun livello è attivo e non si applica alcuna sostituzione, non esiste alcun assegnatario. Consulta le regole di rotazione e di livello.
Sospendi le notifiche di fatturazione durante una distribuzione pianificata
Crea una finestra con ambito di servizio tramite l'interfaccia o invia questa configurazione a POST /api/maintenance-windows utilizzando una sessione di gestione API autenticata con l'autorizzazione a modificare l'ambito. Un token del percorso di assunzione non è una credenziale di gestione. Sostituisci 42 con il tuo ID servizio di fatturazione effettivo e scegli una finestra di test futura.
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}Questi timestamp sono gli orari dell'orologio nel fuso orario selezionato, non i valori UTC con un Z omesso. Durante questo periodo, gli avvisi di fatturazione in arrivo rimangono visibili, ma le notifiche, i promemoria e l'escalation vengono sospesi. Gli altri servizi dovrebbero rimanere inalterati. Questo comportamento non è suppress_incident, che impedisce la creazione di nuovi AlertGroup, o pause_escalation_only, che mantiene abilitate le notifiche.
Metti alla prova i confini, non solo nel mezzo di un turno
- Esamina l'incarico appena prima e dopo le 09:00 e le 18:00, durante il fine settimana e il passaggio all'ora legale. Aggiungi una sostituzione temporanea e conferma che vince, quindi rimuovila.
- Apri il controllo completo dell'integrità delle chiamate. Esamina la finestra futura controllata, le lacune, i membri inattivi e i metodi di consegna utilizzabili. Un riepilogo verde non è una prova di copertura per sempre o di consegna a un telefono.
- Invia eventi di test di fatturazione e di servizi non correlati durante la manutenzione. Conferma che la fatturazione è visibile ma silenziosa e che il servizio non correlato invia comunque notifiche. Per includere avvisi già non risolti, abilitare esplicitamente l'opzione per applicare la finestra agli avvisi esistenti; è disattivato per impostazione predefinita.
- Lascia attiva la fatturazione al termine del periodo. Con la riattivazione abilitata, verifica che la normale notifica riprenda senza riprodurre ogni promemoria mancato. Confermare che il risponditore effettivo lo riceva e possa riconoscerlo.
Un servizio tranquillo non è un servizio recuperato
La manutenzione non ripara il servizio, non ritira i messaggi consegnati né implica la risoluzione. La riattivazione al termine è abilitata per impostazione predefinita; disabilitandolo si mantiene l'effetto di manutenzione al termine della finestra. Le finestre sovrapposte possono mantenere silenzioso un avviso finché non viene rilasciato l'ultimo effetto attivo o mantenuto applicabile. Esamina questi controlli nella guida alla manutenzione.
Mantieni i calcoli SLO e il rilevamento della velocità di combustione nel tuo stack di monitoraggio. IR instrada e coordina i segnali risultanti. Un AlertGroup possiede il riconoscimento tecnico, la risoluzione, le notifiche e l'escalation; un Incidente è un flusso di lavoro operativo separato. Il collegamento di diversi AlertGroup a un incidente non unisce le loro cronologie tecniche. Nella versione 2.3.1, i risponditori e le parti interessate appartengono ancora ad AlertGroups. Testare entrambi i cicli di vita invece di trattare una modifica dello stato di un incidente come un Gruppo di avvisi ACK.