1) Quando tutto è attivo, ma nulla è utilizzabile
Un incidente cambiò definitivamente le mie priorità. I servizi erano attivi. I deployment risultavano corretti. Ma un risultato fondamentale non era aggiornato e nessuno sapeva dire con sicurezza da quando o perché.
Quel giorno mi insegnò una lezione dura: l’uptime è una metrica debole se i risultati su cui si basano le decisioni sono sbagliati o tardivi.
2) Il vero problema
Su larga scala il comportamento del sistema è distribuito e non lineare. Un picco in una coda, un ritardo nello scheduling e una tempesta di nuovi tentativi su un altro percorso possono combinarsi e avere conseguenze sul servizio. Se la telemetria è frammentata, lo sarà anche la risposta agli incidenti.
- Dovevamo rilevare più rapidamente i rischi per i risultati, oltre a quelli per l’infrastruttura.
- Serviva un contesto condiviso tra i team backend, dati e piattaforma.
- Servivano dashboard che guidassero le decisioni, oltre al semplice monitoraggio.
3) Situazione iniziale
Avevamo log e dashboard, ma non erano allineati alle domande operative. Troppo volume di segnali e poca qualità. Durante gli incidenti passavamo troppo tempo a cercare il contesto e troppo poco a risolvere la causa.
Figura 1 — Architettura di osservabilità prima della revisione
La pipeline esisteva, ma il modello delle metriche non era allineato alle decisioni e ai confini di responsabilità.
4) Perché il debugging tradizionale non bastava
Il vecchio approccio consisteva nel controllare i log, esaminare le dashboard infrastrutturali e correlare tutto manualmente. Su scala maggiore è troppo lento. Quando la correlazione è completa, l’impatto si è già esteso.
Smisi di chiedermi «abbiamo i dati?» e iniziai a chiedermi «questi dati possono rispondere alle domande principali di un incidente in cinque minuti?».
5) Osservabilità vista dai sistemi distribuiti
Nelle pipeline distribuite ogni fase dovrebbe emettere informazioni utili: pressione in ingresso, latenza di elaborazione, classe di errore, classe dei nuovi tentativi e affidabilità del risultato. Se una fase è una scatola nera, l’intera catena diventa più lenta da diagnosticare.
- La visibilità per fase ridusse i rimpalli di responsabilità tra team.
- Ritardo delle code e latenza dello scheduler davano un allarme prima delle violazioni degli SLA.
- Le metriche per classe di nuovo tentativo rivelavano amplificazioni nascoste dei guasti.
Figura 2 — Flusso della telemetria orientata alle decisioni
Il passaggio fondamentale fu dalla telemetria grezza a una telemetria che supportava direttamente azione e verifica.
6) Lezioni di osservabilità specifiche per Kubernetes
Le metriche del cluster divennero utili solo quando le collegammo ai risultati. Pod in attesa, eviction e ricambio dei pod erano anche indicatori di futuri problemi di tempestività e affidabilità.
- Il tempo di attesa dei pod diventò una metrica di rischio precoce.
- Le eviction venivano monitorate insieme al ritardo delle code e alla latenza p95.
- Le dashboard dei rilasci includevano verifiche sui risultati, oltre alla readiness dei pod.
7) Dati e fiducia
Dovevamo osservare esplicitamente anche la qualità e la tempestività dei dati. Un job «riuscito» che produce partizioni incomplete è un fallimento operativo. Aggiungemmo controlli di affidabilità e li rendemmo visibili nelle stesse dashboard usate per gestire gli incidenti.
Figura 3 — Indicatori di fiducia operativa
Quando migliorò la qualità dei segnali, migliorarono anche la rapidità decisionale e la qualità del ripristino.
8) Lezioni di osservabilità che hanno cambiato il mio modo di sviluppare
- Partire dalle domande, oltre che dalle metriche.
- Collegare ogni avviso critico a una procedura operativa.
- Misurare fiducia e tempestività, oltre all’uptime.
- Trattare la manutenzione delle dashboard come quella di un prodotto.
Con questo modello gli incidenti divennero meno caotici e la collaborazione tra team molto più chiara.
9) Lezioni sull’affidabilità
Una migliore osservabilità cambiò l’affidabilità perché cambiò i tempi di intervento. Rilevavamo prima, classificavamo meglio e ripristinavamo con meno tentativi alla cieca. L’affidabilità divenne un processo ripetibile.
Figura 4 — Ciclo di affidabilità supportato dall’osservabilità
Il ciclo si chiudeva solo verificando l’affidabilità dei risultati, oltre alla disponibilità dei servizi.
10) Errori che oggi eviterei
- Costruire dashboard prima di definire le domande operative.
- Lasciare divergere tra team le convenzioni per nomi e tag.
- Considerare facoltativa la telemetria sulla qualità dei dati.
- Ignorare la qualità degli avvisi e il rapporto tra rumore e utilità operativa.
11) Consigli per chi sviluppa questi sistemi
Se la tua piattaforma cresce, rendi subito l’osservabilità una competenza ingegneristica fondamentale. Non aspettare che la scala riveli i punti ciechi in produzione.
- Definisci esplicitamente le domande principali da porre durante gli incidenti.
- Associa ogni domanda a una metrica e a un responsabile.
- Associa ogni avviso critico ad azioni concrete.
- Rivedi la qualità della telemetria nelle retrospettive.
12) Conclusioni
Su larga scala la qualità del codice è necessaria, ma non sufficiente. L’osservabilità determina se il team può gestire la complessità con sicurezza.
La mia lezione pratica: quando i sistemi crescono, i team più veloci sono spesso quelli che vedono chiaramente la realtà, decidono rapidamente e ripristinano con calma.
Se iniziasse ora un problema ad alto impatto, le tue dashboard saprebbero indicare al team cosa fare dopo, senza procedere a tentativi?