È scattato un allarme. E adesso?

Dalla serie

Obiettivo

Collegare un segnale verificato a una risposta proporzionata, distinguendo intervento urgente, lavoro pianificabile e analisi delle tendenze; definire responsabile, informazioni diagnostiche, autorizzazioni, escalation e verifica dell'esito.

Un allarme apre una decisione, non autorizza un'azione

Quando scatta un allarme, la prima domanda non è «cosa facciamo?», ma «cosa sappiamo davvero?». Verifica quale rischio indica il dato, quanto è affidabile il segnale, quanto tempo hai per intervenire e quale decisione è realmente disponibile. Solo dopo classifica la risposta: coinvolgi il reperibile per un impatto significativo e attuale, assegna un'attività con scadenza per una degradazione gestibile, oppure porta una tendenza alla revisione di capacità. Per ogni segnale prepara una scheda operativa con condizione osservata, qualità e freschezza del dato, ambito, severità, destinatario e sostituto, tempo di presa in carico, escalationGlossarioEscalationUna richiesta deliberata a un’autorità superiore o diversa per risolvere un rischio materiale o una decisione bloccata.Apri la voce completa, informazioni diagnostiche e azioni già autorizzate. L'allarme crea attenzione e contesto: non concede automaticamente autorità per rollback, retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa, modifiche ai dati o blocchi dei rilasci.

Rilevare, diagnosticare e recuperare sono tre cose diverse

Un buon sistema operativo separa tre passaggi. La rilevazione dice che una condizione merita attenzione. La diagnosi cerca di capire causa, impatto e stato reale del processo. Il recovery applica un'azione autorizzata e poi verifica l'esito. Confondere questi passaggi produce automatismi pericolosi: un timeoutGlossarioTimeoutUn limite definito a quanto un’operazione attende prima di considerare il tentativo non riuscito.Apri la voce completa può segnalare un problema senza dirti se l'operazione sia fallita, un errore può indicare una dipendenza degradata senza dimostrare che il servizio vada riavviato, un semaforo tornato verde può significare soltanto che la condizione di alert non è più vera. La catena deve quindi conservare evidenze sufficienti per passare da un passo al successivo senza trasformare un segnale in una conclusione.

Rapidità, rumore e autorità: il compromesso da progettare

Una soglia aggressiva riduce il tempo di rilevazione, ma aumenta falsi positivi e affaticamento del reperibile. Una finestra più lunga filtra il rumore, ma può ritardare la risposta. Il burn rate aiuta a collegare la notifica al consumo dell'error budgetGlossarioError BudgetLa quantità di inaffidabilità consentita implicitamente da uno SLO.Apri la voce completa, ma resta un rapporto osservato: traffico, popolazione e andamento futuro ne limitano l'interpretazione. Con poco traffico, mostra anche i conteggi; con denominatore nullo, non inventare una percentuale. Raggruppare notifiche duplicate riduce il rumore, ma non deve nascondere guasti indipendenti. Infine, un'azione rapida è utile solo se rientra nell'autorità del destinatario: per operazioni ambigue o irreversibili, riconciliare lo stato autorevole prima di ripetere è più sicuro che reagire alla cieca. • Rilevazione più rapida contro maggiore rumore operativo. • Automazione della risposta contro rischio di azioni non autorizzate o non reversibili. • Soppressione delle notifiche contro perdita di visibilità su guasti distinti. • Percentuali sintetiche contro interpretazioni distorte nei servizi a basso traffico.

Ordini accettati, pagamenti incerti

In una piattaforma enterprise, il monitoraggio segnala che alcune richieste d'ordine accettate non raggiungono la conferma entro il tempo previsto. Se il numero di richieste che invecchiano cresce rapidamente e interessa utenti attivi, il reperibile valuta subito l'impatto e consulta stato del workflow, code e dipendenze. Un timeout verso il pagamento, però, non dimostra che l'addebito non sia avvenuto: prima di ripetere l'operazione occorre interrogare la fonte autorevole e proteggere l'unicità della transazione. Se invece emerge una degradazione lenta senza arretrato critico, il responsabile può aprire un'attività pianificata con scadenza. Dopo l'intervento, il team non chiude perché il semaforo è tornato verde: verifica nuove richieste, smaltimento dell'arretrato, riconciliazione degli stati ambigui e attendibilità della telemetria. Il percorso completo va provato in condizioni concordate includendo degrado rapido, persistenza, recupero, dati mancanti, basso volume e notifiche duplicate.

La catena minima da rendere verificabile

Prima di considerare pronto un allarme, assicurati che ogni passaggio abbia un proprietario e un'evidenza verificabile. • Segnale: condizione, ambito, qualità e freschezza dei dati sono espliciti. • Rilevazione: è chiaro perché il segnale merita attenzione adesso. • Diagnosi: rischio, impatto e stato autorevole vengono verificati prima di agire. • Responsabile: destinatario, sostituto, presa in carico ed escalation sono definiti. • Azione: controlli diagnostici, interventi autorizzati e decisioni da escalare sono distinti. • Recovery: il recupero del processo, l'arretrato e gli stati ambigui sono controllati separatamente dalla cessazione dell'allarme. • Revisione: notifiche inutili, problemi non rilevati e regole senza decisione associata vengono corretti o rimossi.

Per approfondire

Fonti esterne autorevoli per progettare notifiche basate sugli SLOGlossarioSLOUn intervallo target per uno SLI su un periodo definito.Apri la voce completa e collegare l'error budget a responsabilità e decisioni operative. • Alerting on SLOs — Google, The Site Reliability Workbook — https://sre.google/workbook/alerting-on-slos/ • Example Error Budget Policy — Google, The Site Reliability Workbook — https://sre.google/workbook/error-budget-policy/

Dai desideri alle evidenze, fino alle decisioni

La serie è partita da una provocazione: ciò che non riesci a misurare è un desiderio. Ma misurare, da solo, non basta. Abbiamo dovuto scegliere cosa proteggere, verificare che la misura osservasse davvero il fenomeno, dare significato alle soglie e infine collegare il segnale a una decisione. Il punto di arrivo non è una dashboard più ricca: è un'architettura che sa spiegare quali proprietà vuole preservare, quali evidenze usa per verificarle e cosa succede quando quelle evidenze indicano un problema.