Issue 10069
Gli SLO come input architetturale, non come metrica di fine corsa
Quando l’affidabilità diventa un obiettivo misurabile, le scelte su ridondanza, recovery e osservabilità smettono di essere astratte.
· 5 min
Obiettivo
Usare SLO e tolleranza al fallimento come input per decisioni su ridondanza, consistenza, capacità, recovery e osservabilità, evitando di progettare affidabilità senza un obiettivo esplicito.
Parti dall’obiettivo di servizio, non dalla soluzione resiliente
In un lavoro architetturale serio, la domanda non è “quanto possiamo rendere robusto il sistema?”, ma “quale livello di indisponibilità o degrado è accettabile per questo servizio?”. Lo SLOGlossarioSLOUn intervallo target per uno SLI su un periodo definito.Apri la voce completa rende esplicito quel limite e ti permette di leggere ridondanza, retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa, replica, failover, consistenza e recovery come opzioni con un costo. Senza questo riferimento, il rischio è progettare per paura: aggiungi complessità ovunque, ma non sai se stai proteggendo davvero il risultato di business. Il punto pratico è semplice: collega lo SLO all’esperienza utente o al processo critico che vuoi preservare, poi usa quell’obiettivo per discutere le scelte architetturali. • Definisci l’obiettivo in termini misurabili e legati al servizio. • Usa lo SLO per decidere quanto rischio accettare su disponibilità, latenza e degrado. • Tratta osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa, capacità e recovery come mezzi per sostenere l’obiettivo, non come fini autonomi.
Lo SLO chiarisce cosa guadagni e cosa stai pagando
L’errore più comune è trasformare la resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa in un superlativo: più replica, più automatismi, più failover, più tutto. In realtà ogni scelta sposta il bilancio tra costo, complessità operativa, coerenza dei dati, tempi di ripristino e velocità di delivery. Un SLO ben definito ti aiuta a dire: qui ha senso investire in ridondanza, lì basta una strategia di recovery più semplice; qui la consistenza forte protegge il business, lì un modello eventuale è accettabile. L’error budgetGlossarioError BudgetLa quantità di inaffidabilità consentita implicitamente da uno SLO.Apri la voce completa aggiunge disciplina: quando si consuma, il sistema ti sta dicendo che il margine di rischio si è ristretto e che conviene rallentare il cambiamento o rafforzare la stabilità. Non è un automatismo, è un input per il giudizio architetturale. • Più affidabilità quasi sempre significa più costo e più complessità. • Più resilienza può ridurre la velocità di delivery se non è bilanciata bene. • Un budget di errore piccolo impone maggiore attenzione a stabilizzazione, capacity e osservabilità. • Non tutti i servizi meritano lo stesso livello di tolleranza al fallimento.
Quando un portale ordini deve restare utile anche in degrado
Immagina un portale ordini di un gruppo retail che gestisce picchi promozionali e integra inventario, pagamento e pricing. Se il team dice solo “deve essere affidabile”, l’architettura rischia di andare verso replica ovunque, failover complessi e controlli rigidi anche dove non servono. Con uno SLO chiaro, invece, la conversazione cambia: il checkout deve rimanere disponibile entro un certo margine, il catalogo può degradare in modo controllato, l’inventario può accettare una breve finestra di inconsistenza se questo evita un blocco totale. A quel punto le decisioni diventano più concrete: investi in capacità extra per i periodi critici, osserva i sintomi che anticipano la violazione dello SLO e stabilisci quando fermare nuove release per ridurre il rischio. Il risultato non è un sistema “perfetto”, ma un sistema progettato per preservare il valore giusto nel momento giusto. • Checkout prioritario rispetto a funzioni secondarie. • Degrado controllato invece di blocco totale. • Capacity e osservabilità usate per proteggere l’obiettivo di servizio.
Per approfondire
Fonti esterne autorevoli per approfondire SLO, error budget e decisioni architetturali. • Google - Site Reliability Engineering: How Google Runs Production Systems - https://sre.google/sre-book/service-level-objectives/ • Implementing SLOs — Google, The Site Reliability Workbook — https://sre.google/workbook/implementing-slos/ • Nygard, Michael - Documenting Architecture Decisions - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions