Progettare la risposta a un segnale: allarme, responsabilità e verifica

1. Definisci il segnale

• Nome e versione della regola sono espliciti?
• Servizio, processo e popolazione sono identificati?
• Proprietà protetta, rischio, condizione, finestra e soglia sono motivati?
• Fonte autorevole, copertura, qualità e freschezza dei dati sono note?
• Assenza di eventi, telemetria mancante ed esiti non valutabili sono distinti?

2. Collega il segnale a una decisione

Per ogni condizione distinta indica l'azione attesa e perché il tempo disponibile la giustifica. Impatto significativo attuale, degradazione gestibile e semplice tendenza non richiedono necessariamente la stessa urgenza né lo stesso canale.

3. Assegna responsabilità e autorità

• Destinatario primario e sostituto sono noti?
• Canale, copertura e tempo atteso di presa in carico sono definiti?
• Condizioni e destinatario di escalation sono espliciti?
• È chiaro chi può diagnosticare, intervenire e chiudere?

Un allarme non concede automaticamente autorità per rollback, retry di pagamenti, modifiche ai dati o blocco dei rilasci. Le azioni ambigue richiedono riconciliazione con la fonte autorevole e limiti espliciti.

4. Verifica il recupero reale

Registra due evidenze distinte: il segnale non supera più la condizione e il processo ha effettivamente recuperato. Dove pertinente verifica nuove richieste, arretrato, stati ambigui, dipendenze e attendibilità della telemetria.

5. Prova regola, instradamento e procedura

1. Prepara casi di degrado rapido, persistente e recupero.
2. Aggiungi telemetria mancante, traffico basso e notifiche duplicate.
3. Per ogni caso registra input noto, comportamento atteso, instradamento, ricezione e utilizzabilità della procedura.
4. Verifica che la deduplicazione non nasconda guasti indipendenti.

Una simulazione della regola non prova la consegna sul canale reale.

Esempio breve: Ordini/Pagamenti

6. Mantieni il contratto operativo

• Un'altra persona reperibile può capire perché è stata avvisata adesso?
• Rischio, evidenze, owner, escalation e limiti di autorità sono leggibili senza interpretazioni?
• È definito come dimostrare che il processo, e non solo il semaforo, ha recuperato?
• Dopo prove o incidenti vengono registrati falsi positivi, mancati rilevamenti e regole senza decisione?

Collegamenti e fonti

• KA-156 documenta lo SLO dell'esempio; KA-155 il contratto della misura; KA-127 l'error budget; KA-094 la manutenzione del portfolio.
• Google, The Site Reliability Workbook — Alerting on SLOs: https://sre.google/workbook/alerting-on-slos/
• Google, The Site Reliability Workbook — Example Error Budget Policy: https://sre.google/workbook/error-budget-policy/

La scheda è un risultato operativo autonomo: non è una configurazione applicata né un'autorizzazione automatica a intervenire.