Scopri il budget degli errori per team piccoli: imposta SLO realistici per prodotti precoci, decidi quali incidenti contano e avvia un semplice rituale settimanale di affidabilità.
I team piccoli rilasciano velocemente perché devono farlo. Il rischio di solito non è un singolo blackout drammatico. È lo stesso piccolo problema che si ripete: una registrazione instabile, un checkout che a volte fallisce, un deploy che occasionalmente rompe una schermata. Ognuno di questi ruba ore, erode la fiducia e trasforma i rilasci in una moneta lanciata.
I budget degli errori danno ai team piccoli un modo semplice per muoversi in fretta senza fingere che l’affidabilità “arriverà da sola”.
Un SLO (service level objective) è una promessa chiara sull’esperienza utente, espressa come un numero su una finestra temporale. Esempio: “I checkout riusciti sono almeno il 99,5% negli ultimi 7 giorni.” Il budget degli errori è la quantità consentita di “male” dentro quella promessa. Se il tuo SLO è 99,5%, il tuo budget settimanale è lo 0,5% di checkout falliti.
Non si tratta di perfezione o di teatro dell’uptime. Non è processo pesante, riunioni infinite o un foglio di calcolo che nessuno aggiorna. È un modo per mettersi d’accordo su cosa significa “abbastanza buono”, notare quando si sta scivolando e prendere una decisione calma su cosa fare dopo.
Inizia in piccolo: scegli 1–3 SLO rivolti all’utente legati ai percorsi più importanti, misurali con segnali che hai già (errori, latenza, pagamenti falliti) e fai una breve revisione settimanale in cui guardi il consumo del budget e scegli una azione di follow-up. L’abitudine conta più degli strumenti.
Pensa all’affidabilità come a una dieta. Non servono giorni perfetti. Ti serve un obiettivo, un modo per misurarlo e una tolleranza per la vita reale.
Un SLI (service level indicator) è il numero che guardi, come “% di richieste che vanno a buon fine” o “p95 del caricamento pagina sotto i 2 secondi”. Un SLO è il target per quel numero, come “99,9% delle richieste va a buon fine”. Il budget degli errori è quanto puoi mancare lo SLO e restare comunque sulla buona strada.
Esempio: se il tuo SLO è 99,9% di disponibilità, il budget è lo 0,1% di downtime. Su una settimana (10.080 minuti), lo 0,1% sono circa 10 minuti. Non significa che devi provare a “usare” quei 10 minuti. Significa che quando li consumi, stai consciamente scambiando affidabilità per velocità, esperimenti o nuove funzionalità.
Questo è il valore: trasforma l’affidabilità in uno strumento decisionale, non in un esercizio di reportistica. Se hai consumato gran parte del budget entro mercoledì, metti in pausa cambi rischiosi e sistema ciò che si sta rompendo. Se stai consumando poco, puoi rilasciare con più fiducia.
Non tutto ha bisogno dello stesso SLO. Un’app pubblica rivolta ai clienti potrebbe necessitare del 99,9%. Uno strumento amministrativo interno può spesso essere più permissivo perché meno persone lo notano e l’impatto è minore.
Non iniziare misurando tutto. Proteggi i momenti in cui un utente decide se il tuo prodotto funziona o no.
Scegli 1–3 percorsi utente che portano più fiducia. Se quelli sono solidi, la maggior parte degli altri problemi sembrerà più piccola. Buoni candidati sono il primo contatto (registrazione o login), il momento del denaro (checkout o upgrade) e l’azione principale (pubblicare, creare, inviare, caricare o una chiamata API critica).
Scrivi cosa significa “successo” in termini semplici. Evita linguaggio tecnico come “200 OK” a meno che i tuoi utenti non siano sviluppatori.
Alcuni esempi che puoi adattare:
Scegli una finestra di misurazione che si adatti a quanto velocemente cambi le cose. Una finestra di 7 giorni funziona quando rilasci ogni giorno e vuoi un feedback rapido. Una finestra di 28 giorni è più calma se i rilasci sono meno frequenti o i dati sono rumorosi.
I prodotti early hanno vincoli: il traffico può essere basso (un singolo deploy sbagliato distorce i numeri), i flussi cambiano rapidamente e la telemetria è spesso scarsa. Va bene. Inizia con conteggi semplici (tentativi vs successi). Raffina le definizioni quando il percorso stesso smette di cambiare.
Parti da quello che rilasci oggi, non da quello che vorresti avere. Per una o due settimane, cattura una baseline per ogni percorso chiave: quanto spesso riesce e quanto spesso fallisce. Usa traffico reale se ce l’hai. Se non ce l’hai, usa i tuoi test più ticket di supporto e log. Stai costruendo un quadro approssimativo del “normale”.
Il tuo primo SLO dovrebbe essere qualcosa che puoi rispettare la maggior parte delle settimane continuando a rilasciare. Se la tua baseline è 98,5%, non impostare 99,9% e sperare. Imposta 98% o 98,5%, poi stringi dopo.
La latenza è seducente, ma può distrarre all’inizio. Molte squadre ricavano più valore da uno SLO sul tasso di successo prima (le richieste si completano senza errori). Aggiungi la latenza quando gli utenti la percepiscono chiaramente e hai dati abbastanza stabili da rendere i numeri significativi.
Un formato utile è una riga per percorso: chi, cosa, target e finestra temporale.
Mantieni la finestra più lunga per momenti di fiducia e denaro (fatturazione, auth). Tienila più corta per i flussi quotidiani. Quando riesci a rispettare lo SLO con facilità, alzalo un po’ e continua.
I team piccoli perdono molto tempo quando ogni intoppo diventa un allarme. L’obiettivo è semplice: il dolore percepito dall’utente consuma il budget; tutto il resto viene gestito come lavoro normale.
Un piccolo insieme di tipi di incidente è sufficiente: outage totale, outage parziale (un flusso chiave si rompe), prestazioni degradate (funziona ma è lento), deploy problematico (una release causa fallimenti) e problemi di dati (dati sbagliati, mancanti, duplicati).
Mantieni la scala piccola e usala ogni volta.
Decidi cosa conta contro il budget. Tratta i fallimenti visibili all’utente come consumo: registrazione o checkout rotti, timeout percepiti, picchi di 5xx che fermano i percorsi. La manutenzione pianificata non dovrebbe contare se è stata comunicata e l’app si è comportata come previsto durante quel periodo.
Una regola risolve la maggior parte delle discussioni: se un utente esterno reale noterebbe e non potrebbe completare un percorso protetto, conta. Altrimenti no.
Questa regola copre anche le aree grigie comuni: un outage di terze parti conta solo se rompe il tuo percorso utente, le ore a basso traffico contano se gli utenti sono impattati, e i tester interni non contano a meno che il dogfooding non sia l’uso principale.
L’obiettivo non è la misurazione perfetta. È un segnale condiviso e ripetibile che ti dice quando l’affidabilità sta diventando costosa.
Per ogni SLO, scegli una fonte di verità e mantienila: una dashboard di monitoring, i log dell’app, un controllo sintetico che colpisce un endpoint, o una singola metrica come checkout riusciti al minuto. Se cambi metodo di misura, annota la data e trattala come un reset così non confronti mele con arance.
Gli alert dovrebbero riflettere il consumo del budget, non ogni intoppo. Un picco breve può essere fastidioso, ma non dovrebbe svegliare nessuno se influisce appena sul budget mensile. Un pattern semplice funziona bene: avvisa su “fast burn” (sei sulla traiettoria per consumare il budget mensile in un giorno) e un alert più morbido su “slow burn” (traiettoria per consumarlo in una settimana).
Tieni un piccolo registro di affidabilità così non ti affidi alla memoria. Una riga per incidente basta: data e durata, impatto sugli utenti, causa probabile, cosa hai cambiato e un responsabile per il follow-up con una scadenza.
Esempio: un team di due persone rilascia una nuova API per un’app mobile. Il loro SLO è “99,5% di richieste riuscite”, misurato da un contatore. Un deploy sbagliato abbassa il successo al 97% per 20 minuti. Scatta un alert di fast-burn, fanno rollback e il follow-up è “aggiungere un controllo canary prima dei deploy”.
Non ti serve un processo grande. Ti serve un’abitudine piccola che mantenga l’affidabilità visibile senza rubare tempo di sviluppo. Un check-in di 20 minuti funziona perché trasforma tutto in una domanda: stiamo consumando l’affidabilità più velocemente di quanto previsto?
Usa lo stesso slot in calendario ogni settimana. Tieni una nota condivisa che appendi (non riscriverla). La coerenza batte i dettagli.
Un’agenda semplice che ci sta dentro:
Tra follow-up e impegni, decidete la regola di rilascio per la settimana e mantienila noiosa:
Se il flusso di registrazione ha avuto due brevi outage e ha consumato gran parte del budget, potresti congelare solo i cambi relativi alla registrazione continuando a rilasciare lavoro non correlato.
Un budget di errore conta solo se cambia cosa fate la settimana successiva. Lo scopo non è uptime perfetto. È un modo chiaro per decidere: rilasciamo funzionalità o riduciamo il debito di affidabilità?
Una politica semplice da dire ad alta voce:
Non è una punizione. È uno scambio pubblico così gli utenti non lo pagano più tardi.
Quando rallenti, evita compiti vaghi come “migliorare la stabilità”. Scegli cambi che modifichino il prossimo esito: aggiungi un guardrail (timeout, validazione input, rate limit), migliora un test che avrebbe catturato il bug, rendi il rollback facile, sistema la fonte principale di errori o aggiungi un alert collegato a un percorso utente.
Tieni il reporting separato dalla colpa. Premia i write-up veloci degli incidenti, anche se i dettagli sono disordinati. L’unico report veramente cattivo è quello che arriva in ritardo, quando nessuno ricorda cosa è stato cambiato.
Una trappola frequente è impostare uno SLO dorato il primo giorno (99,99% suona bene) e poi ignorarlo quando la realtà arriva. Il tuo SLO iniziale dovrebbe essere raggiungibile con le persone e gli strumenti attuali, altrimenti diventa rumore di fondo.
Un altro errore è misurare la cosa sbagliata. Le squadre guardano cinque servizi e un grafico del database, ma perdono il percorso che l’utente percepisce: registrazione, checkout o “salva modifiche”. Se non riesci a spiegare lo SLO in una frase dal punto di vista dell’utente, probabilmente è troppo interno.
L’alert fatigue consuma l’unica persona che può risolvere la produzione. Se ogni piccolo picco sveglia qualcuno, le pagine diventano “normali” e i veri incendi vengono persi. Pagina solo per impatto utente. Metti tutto il resto in controlli quotidiani.
Un killer più silenzioso è il conteggio incoerente. Una settimana conti un rallentamento di due minuti come incidente, la settimana dopo no. Allora il budget diventa una discussione invece che un segnale. Scrivi le regole una volta e mantienile coerenti.
Guardrail che aiutano:
Se un deploy rompe il login per 3 minuti, contalo ogni volta, anche se viene risolto in fretta. La coerenza è ciò che rende utile il budget.
Metti un timer a 10 minuti, apri un doc condiviso e rispondi a queste cinque domande:
Se non puoi misurare qualcosa ancora, inizia con un proxy che vedi subito: pagamenti falliti, errori 500 o ticket di supporto etichettati “checkout”. Sostituisci i proxy quando il monitoraggio migliora.
Esempio: un team di due persone vede tre messaggi “impossibile resettare la password” questa settimana. Se il reset password è un percorso protetto, quello è un incidente. Scrivono una nota breve (cosa è successo, quanti utenti, cosa hanno fatto) e scelgono un follow-up: aggiungere un alert sui fallimenti del reset o aggiungere un retry.
Maya e Jon gestiscono una startup di due persone e rilasciano ogni venerdì. Si muovono veloci, ma i primi utenti paganti tengono a una cosa: possono creare un progetto e invitare un collega senza che si rompa?
La scorsa settimana hanno avuto un outage reale: “Crea progetto” ha fallito per 22 minuti dopo una migration sbagliata. Hanno anche avuto tre periodi “lenti ma non morti” in cui la schermata girava per 8–12 secondi. Gli utenti si sono lamentati, ma il team ha discusso se il rallentamento contasse come “down”.
Hanno scelto un percorso e lo hanno reso misurabile:
Lunedì fanno il rituale di 20 minuti. Stesso orario, stesso documento. Rispondono a quattro domande: cosa è successo, quanto budget è stato consumato, cosa si ripeteva e quale singolo cambiamento potrebbe prevenire la ripetizione.
Il compromesso diventa ovvio: l’outage più i periodi lenti hanno consumato gran parte del budget settimanale. Quindi la “grande feature” della settimana successiva diventa “aggiungi un indice al DB, rendi le migration più sicure e alert sui fallimenti di create-project”.
Il risultato non è affidabilità perfetta. Sono meno problemi ripetuti, decisioni più chiare sì/no e meno nottate in bianco perché avevano concordato prima cosa significa “abbastanza male”.
Scegli un percorso utente e fai una promessa di affidabilità semplice su di esso. I budget degli errori funzionano meglio quando sono noiosi e ripetibili, non perfetti.
Inizia con uno SLO e un rituale settimanale. Se dopo un mese sembra facile, aggiungi un secondo SLO. Se sembra pesante, ridimensionalo.
Mantieni la matematica semplice (settimanale o mensile). Mantieni il target realistico per il punto in cui sei ora. Scrivi una nota di affidabilità di una pagina che risponde: lo SLO e come lo misuri, cosa conta come incidente, chi è di turno questa settimana, quando avviene il check-in e cosa fate per default quando il budget brucia troppo in fretta.
Se stai costruendo su una piattaforma come Koder.ai (koder.ai), può aiutare ad abbinare iterazioni rapide a pratiche di sicurezza, specialmente snapshot e rollback, così “revert all’ultimo stato buono” resta una mossa normale e praticata.
Tieni il loop stretto: uno SLO, una nota, un breve check-in settimanale. L’obiettivo non è eliminare gli incidenti. È notarli presto, decidere con calma e proteggere le poche cose che gli utenti percepiscono davvero.
Un SLO è una promessa sulla affidabilità relativa a un'esperienza utente, misurata su una finestra temporale (come 7 o 30 giorni).
Esempio: “99,5% dei checkout riesce negli ultimi 7 giorni.”
Un budget di errore è la quantità consentita di “cose che vanno male” dentro il tuo SLO.
Se il tuo SLO è 99,5% di successo, il budget è lo 0,5% di fallimenti in quella finestra. Quando consumi il budget troppo in fretta, rallenti le modifiche rischiose e risolvi le cause.
Inizia con 1–3 percorsi che gli utenti notano subito:
Se quelli sono affidabili, la maggior parte degli altri problemi pesa meno e diventa più facile priorizzare.
Scegli una baseline che puoi davvero rispettare la maggior parte delle settimane.
Se oggi sei al 98,5%, partire da 98–98,5% è più utile che dichiarare 99,9% e poi ignorarlo.
Usa conteggi semplici: tentativi vs successi.
Buone sorgenti iniziali:
Non aspettare l’osservabilità perfetta; parti con un proxy che ti dà fiducia e mantienilo coerente.
Conta come incidente se un utente esterno noterebbe e non riuscirebbe a completare un percorso protetto.
Esempi che “contano” contro il budget:
Non contare disagi solo interni, a meno che l’uso interno sia il caso d’uso principale.
Una semplice regola: sveglia qualcuno per il consumo del budget, non per ogni sbalzo.
Due tipi di allerta utili:
Questo riduce l’alert fatigue e concentra l’attenzione su problemi che cambieranno cosa si rilascia.
Tienila a 20 minuti, stesso orario, stesso documento:
Concludi con una modalità di rilascio per la settimana: , o .
Usa una politica semplice e chiara:
L’obiettivo è un compromesso calmo, non una colpa.
Alcune pratiche che aiutano:
Se usi una piattaforma come Koder.ai, rendi “torna all’ultimo stato valido” una mossa normale e considera i rollback ripetuti come un segnale per investire in test o controlli di deploy più sicuri.
