Osservabilità e SRE — dai log agli SLO, quando l'affidabilità diventa una decisione

Ogni sistema in produzione, prima o poi, fa qualcosa che nessuno aveva previsto. La domanda non è se accadrà, ma se sarete in grado di capirlo mentre accade. È qui che si gioca la differenza tra un'infrastruttura che si limita a raccogliere log e una che è davvero osservabile: la prima produce dati; la seconda produce risposte. E in un incidente, alle tre di notte, la differenza tra le due si misura in minuti di disservizio e in fiducia dei clienti.

Monitoraggio non è osservabilità

Il monitoraggio classico risponde a domande note: la CPU è sopra soglia? il disco è pieno? l'endpoint risponde? Sono domande legittime, ma tutte decise prima che il problema esistesse. Il guaio è che i guasti interessanti — quelli che davvero fanno male — quasi mai somigliano a ciò che avevate immaginato di dover controllare. Nascono dall'intreccio di più servizi, da una dipendenza lenta a valle, da un rilascio che interagisce male con un dato raro.

L'osservabilità ribalta la prospettiva: invece di predefinire ogni allarme, si struttura il sistema perché si possa interrogare a posteriori, ponendo domande che non erano state previste. «Perché questi utenti, su questa regione, dopo quel deploy, vedono latenze doppie?» è una domanda che nessun dashboard preconfezionato conteneva. Un sistema osservabile permette di formularla e rispondere in pochi minuti; uno solo monitorato costringe a ipotizzare al buio e a redistribuire nella speranza che passi.

I tre segnali, e quello che li tiene insieme

L'osservabilità poggia su tre tipi di segnale complementari — metriche, log e tracce — ma il valore non sta nel raccoglierli, bensì nel poterli attraversare.

• Le metriche dicono che qualcosa è cambiato: sono aggregati economici da conservare, ideali per accorgersi in fretta di una deviazione.
• I log dicono cosa è successo in un punto preciso: sono il racconto dettagliato di un evento, prezioso ma costoso se non disciplinato.
• Le tracce distribuite dicono dove: seguono una singola richiesta mentre attraversa decine di servizi e rivelano in quale anello si accumula il ritardo.

Il salto di qualità arriva quando i tre segnali sono correlati da un contesto comune — un identificativo di traccia, la versione del rilascio, il tenant — così da passare da una metrica anomala alle esatte tracce che la spiegano, e da lì ai log del servizio colpevole, senza cambiare strumento e senza indovinare. Adottare uno standard aperto di strumentazione come OpenTelemetry serve esattamente a questo: rendere il contesto uniforme e non restare prigionieri di un singolo fornitore.

Non serve raccogliere più dati. Serve poter fare, sui dati che già avete, una domanda che non avevate previsto — e ottenere la risposta prima che il cliente se ne accorga.

Gli SLO: trasformare l'affidabilità in una decisione

Strumentare bene serve a poco se poi «il sistema è lento» resta un giudizio soggettivo. Per questo il cuore della pratica SRE non è tecnologico ma di metodo: definire Service Level Objective che traducano l'esperienza dell'utente in una soglia misurabile — per esempio, «il 99,9% delle richieste di checkout completate sotto i 300 ms su base mensile».

Da un SLO discende l'error budget: se l'obiettivo è il 99,9%, esiste uno 0,1% di margine di errore che il team può spendere. È uno strumento sorprendentemente potente perché disinnesca la guerra ricorrente tra chi vuole rilasciare in fretta e chi vuole stabilità. Se il budget è capiente, si osa: si rilascia più spesso, si sperimenta. Se il budget è quasi esaurito, la priorità passa da sola al consolidamento. L'affidabilità smette di essere un'opinione da riunione e diventa una decisione basata su un numero condiviso. Ed è anche un antidoto alla perfezione inutile: puntare al 100% costa moltissimo e non lo percepisce nessuno; il lavoro giusto è scegliere il livello di affidabilità che serve a quel servizio, non il massimo teorico.

Allarmi che parlano di sintomi, non di cause

Il fallimento più comune dell'osservabilità è l'inondazione di allarmi. Un team sommerso da notifiche impara in fretta a ignorarle, e il primo allarme davvero importante si perde nel rumore. La regola che applichiamo è semplice: si allerta una persona solo quando c'è un sintomo che tocca l'utente e richiede un intervento umano immediato. La CPU alta di per sé non è un problema dell'utente; il checkout che sfora l'SLO lo è. Tutto il resto — le tante spie utili ma non urgenti — vive nei cruscotti, non nel cercapersone di notte.

Legare gli allarmi agli SLO, invece che alle singole risorse, riduce drasticamente il rumore e restituisce senso alla reperibilità. E quando l'allarme scatta, deve arrivare accompagnato dal contesto — il collegamento diretto alle tracce e ai log pertinenti — così chi risponde parte dal cosa sta succedendo e non da dove comincio a guardare.

Il post-mortem è dove l'affidabilità si accumula

Ogni incidente serio lascia dietro di sé una lezione, e il valore di lungo periodo dipende da come la si raccoglie. Pratichiamo il post-mortem senza colpa: l'obiettivo non è trovare chi ha sbagliato, ma capire quale proprietà del sistema ha reso possibile l'errore — perché le persone cambiano, i sistemi restano. Un incidente ben analizzato produce due cose concrete: un'azione correttiva che rimuove la causa e un miglioramento dell'osservabilità stessa, così che quella categoria di problema, la prossima volta, sia visibile in secondi anziché in ore.

È così che l'affidabilità si capitalizza invece di ripartire da zero a ogni guasto. Non è l'assenza di incidenti a distinguere un sistema maturo — gli incidenti capitano a tutti — ma la velocità con cui vengono compresi e la disciplina con cui non si ripetono.

Dove interviene MAST

L'osservabilità non si compra installando uno strumento: si costruisce come pratica. Nella nostra esperienza il percorso è concreto e incrementale. Partiamo da un assessment dello stato attuale — che cosa è già strumentato, quali domande oggi restano senza risposta durante un incidente. Introduciamo una strumentazione coerente e aperta, definiamo con i vostri team i primi SLO sui percorsi che contano per il business, e ricostruiamo la reperibilità intorno a sintomi utili invece che a rumore. Infine radichiamo la cultura del post-mortem senza colpa, perché la pratica resti in casa vostra quando noi avremo finito.

Se durante un disservizio il vostro team passa più tempo a indovinare dove guardare che a risolvere, il problema non è la quantità di dati: è la loro osservabilità. Parliamone con un assessment di osservabilità e affidabilità — mappiamo le domande che oggi restano senza risposta e costruiamo insieme i primi SLO che trasformano l'affidabilità da speranza a decisione.