Issue 10069
· 5 min
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.
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.
practice
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.
trade-offs
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.
enterprise-example
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.
references
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/ • Google Cloud - Implementing Service Level Objectives - https://cloud.google.com/blog/products/management-tools/implementing-service-level-objectives • Nygard, Michael - Documenting Architecture Decisions - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
Da ricordare
Senza uno SLO, l’affidabilità resta un’intenzione; con uno SLO, diventa un vincolo misurabile che guida trade-off architetturali concreti.
Per la prossima riunione
Se dovessi usare uno SLO come input per una decisione architetturale reale, quale trade-off su ridondanza, consistenza o recovery cambierebbe per primo nel tuo contesto?
Una domanda per te