Costruire uno SLO esplicito senza confondere obiettivo, misura e allarme

Tipo

Pratica

SEPARA CIÒ CHE OSSERVI DA CIÒ CHE PROMETTI. La situazione misurata descrive il comportamento del sistema, non stabilisce automaticamente ciò che gli utenti possono accettare. Uno SLI è l'indicatore osservato; uno SLO esprime un obiettivo su quell'indicatore. Non è la stessa cosa di un accordo contrattuale con conseguenze esterne [1]. La pratica seguente costruisce un esempio originale sul processo Ordini/Pagamenti: non propone valori universali né certifica un servizio esistente. DEFINISCI EVENTI E PERIODO. Riprendi il contratto della misura in KA-155. Nel nostro perimetro l'operazione inizia quando la piattaforma registra autorevolmente una richiesta di ordine come accettata. Un evento è buono se l'ordine è persistito e la conferma è resa disponibile entro cinque secondi da quella registrazione. La misura non comprende le richieste che non raggiungono l'accettazione né il tempo necessario al cliente per visualizzare la conferma: tali aspetti richiedono indicatori distinti. Retry della stessa operazione non aggiungono nuove richieste al denominatore. Un errore noto o un completamento oltre cinque secondi non sono eventi buoni. Non eliminare dal denominatore le richieste rimaste aperte oltre il limite. FORMULA LO SLO. Come ipotesi didattica, richiedi che almeno il 99,9% delle operazioni eleggibili accettate in una finestra scorrevole di 28 giorni sia buono secondo quella definizione. Per una classificazione finale, attendi che per le richieste più recenti siano trascorsi i cinque secondi previsti e il ritardo di acquisizione dichiarato; mostra separatamente la porzione ancora in attesa di valutazione. Il criterio sul singolo evento è cinque secondi, l'obiettivo sulla popolazione è 99,9%, il periodo è 28 giorni. Sono tre elementi diversi. La specifica completa deve anche spiegare esclusioni, fonte, granularità e gestione dei dati tardivi. La distinzione tra definizione dello SLI e sua implementazione permette di discutere copertura, qualità e costo della misura [2]. CALCOLA UN CASO CHIUSO. Supponi un periodo completamente osservato con 100.000 operazioni eleggibili, già valutabili, di cui 99.920 buone e 80 non buone. Lo SLI è 99.920 / 100.000 = 99,92%. Con l'obiettivo ipotizzato del 99,9%, il budget di errore riferito a quella popolazione è 100 operazioni; ne risultano consumate 80 e restano 20 operazioni di margine nel conto di quel periodo. Il margine non è un'autorizzazione a causare altri errori. Non trasformare inoltre 100 operazioni in minuti di indisponibilità: il budget qui è basato sugli eventi, non sul tempo. In una finestra scorrevole cambiano sia la popolazione sia gli eventi che entrano ed escono; il conto non è un saldo immutabile. MOTIVA I VALORI. Per scegliere davvero tempo, percentuale e periodo, raccogli aspettative sul processo, impatto del degrado, vincoli, comportamento osservato e costo per sostenere il risultato. Prodotto, sviluppo e operation devono concordare un obiettivo difendibile e un modo di rivederlo [2]. I cinque secondi e il 99,9% servono soltanto a rendere verificabile l'esempio. Se il risultato corrente è insufficiente, dichiara il divario e le azioni; non rinominare il comportamento esistente come obiettivo per ottenere un verde. Se è migliore del necessario, rendi esplicito il costo prima di promettere di mantenerlo per sempre. NON CONFONDERE BUDGET E VINCOLI. Lo SLO di tempestività non sostituisce la verifica di unicità dell'ordine, l'autorizzazione del pagamento o il controllo di una dipendenza vietata. Un vincolo di integrità va valutato separatamente e può richiedere intervento anche quando lo SLO è rispettato. Il rapporto di eventi buoni misura la proprietà definita, non la correttezza dell'intera architettura. Un degrado concentrato su una popolazione importante può inoltre essere poco visibile nell'aggregato: dichiara quando servono segmenti separati e con quale volume osservato. QUALITÀ DEL DATO E DECISIONE. Se la fonte necessaria a classificare gli esiti è incompleta, non dichiarare soddisfatto lo SLO sulla base dei soli successi rimasti. Esponi copertura e incertezza e applica la politica concordata per i casi non valutabili. La soglia di un allarme è una scelta distinta: deve consentire un intervento utile, non essere semplicemente la percentuale dello SLO ricopiata su una finestra breve. Lo sviluppo delle regole di risposta appartiene all'uscita successiva. OUTPUT MINIMO. Documenta scopo, utenti e confine, evento eleggibile, evento buono, sorgente e qualità del dato, formula, periodo, obiettivo e motivazione, error budget, responsabili, politica decisionale collegata e condizioni di revisione. Versiona i cambiamenti della definizione, così che i confronti storici non nascondano un cambio di significato. COLLEGAMENTI CANONICI. TERM-044 definisce SLI, TERM-045 SLO e TERM-046 Error Budget. KA-126 motiva l'obiettivo di affidabilità e KA-127 il suo uso nei trade-off; qui viene aggiunta la costruzione operativa di un criterio verificabile. FONTI PRIMARIE. [1] Google, Site Reliability Engineering, Service Level Objectives: https://sre.google/sre-book/service-level-objectives/ . [2] Google, The Site Reliability Workbook, Implementing SLOs: https://sre.google/workbook/implementing-slos/ . Numeri, stati Ordini/Pagamenti e calcolo sono un esempio didattico originale, non evidenza di un ambiente reale.