Gestione degli imprevisti per i team high velocity
Che cos'è un budget di errore e perché è importante?
Ogni team di sviluppo, delle operazioni e IT sa che a volte si verificano imprevisti.
Anche le più grandi aziende con i talenti più brillanti e la reputazione di quasi il 100% di operatività a volte devono assistere al frustrante spettacolo dei loro sistemi che smettono di funzionare. Basti pensare a Apple, Delta o Facebook, tutte aziende che hanno perso decine di milioni a causa di imprevisti negli ultimi cinque anni.
Questa realtà indica che gli accordi sui livelli di servizio (SLA) non dovrebbero mai promettere un tempo di attività del 100%, perché questa è una promessa che nessuna azienda può mantenere.
Indica anche che se la tua azienda eccelle nell'evitare o risolvere gli imprevisti, potresti superare costantemente i tuoi obiettivi di tempo di attività. Potresti forse promettere un'operatività del 99% e avvicinarti in realtà al 99,5% o promettere un tempo di attività del 99,5% e raggiungere in realtà il 99,99% in un mese tipico.
Quando questo accade, gli esperti di settore consigliano di considerare quell'ulteriore 0,99% invece di definire aspettative degli utenti troppo elevate disattendendo costantemente le promesse fatte. Budget di errore: il tempo che il tuo team può utilizzare per assumersi rischi.
Che cos'è un budget di errore?
Un budget di errore è il periodo massimo di tempo durante il quale un sistema tecnico può non essere operativo senza conseguenze contrattuali.
Ad esempio, se il tuo accordo sui livelli di servizio (SLA) specifica che i sistemi funzioneranno per il 99,99% del tempo prima che l'azienda debba indennizzare i clienti per l'interruzione, significa che il tuo budget di errore (o il tempo in cui i tuoi sistemi possono non funzionare senza conseguenze) è di 52 minuti e 35 secondi all'anno.
Se lo SLA promette un tempo di attività del 99,95%, il budget di errore è di quattro ore, 22 minuti e 48 secondi. Inoltre, con uno SLA che promette il 99,9% di tempo di attività, il tuo budget di errore è di otto ore, 46 minuti e 12 secondi.
Perché i team tecnologici hanno bisogno del budget di errore?
A prima vista, il budget di errore non sembra così importante. Parrebbe solo l'ennesima metrica che l'IT e DevOps devono monitorare per assicurarsi che tutto funzioni senza intoppi.
Purtroppo, le cose non stanno così. Il budget di errore non rappresenta solo un modo pratico per assicurarsi di rispettare le promesse contrattuali, ma offre anche ai team di sviluppo un'opportunità per innovare e assumersi rischi.
Come spieghiamo nel nostro articolo sugli SRE:
"Il team di sviluppo può "spendere" questo budget di errore nel modo che preferisce. Se il prodotto funziona perfettamente, senza errori o con un numero limitato di errori, il team può lanciare ciò che vuole, quando vuole. Se, invece, ha raggiunto o superato il budget di errore e opera allo stesso livello di servizio definito o al di sotto dello SLA definito, tutti i lanci vengono bloccati fino a quando il numero di errori non si riduce a un livello che consenta di proseguire con il lancio.
Il vantaggio di questo approccio risiede nel fatto che incoraggia i team a ridurre al minimo gli imprevisti reali e a massimizzare l'innovazione assumendo rischi entro limiti accettabili. Inoltre, colma il divario tra team di sviluppo, i cui obiettivi sono innovazione e agilità, e team delle operazioni, che si preoccupano della stabilità e della sicurezza. A condizione che il tempo di inattività rimanga basso, gli sviluppatori possono rimanere Agile e apportare modifiche senza essere ostacolati dagli attriti delle operazioni.
Come utilizzare un budget di errore
Innanzitutto, devi consultare gli SLA e gli SLO. Quali obiettivi hai già fissato per il tempo di attività o per le richieste di sistema riuscite? Quali promesse ha fatto la tua azienda ai clienti? Sono le risposte a queste domande a determinare il budget di errore.
Budget di errore in base al tempo di attività
La maggior parte dei team monitora il tempo di attività su base mensile. Se la disponibilità è superiore al numero promesso dallo SLA/SLO, il team può rilasciare nuove funzioni e assumersi dei rischi. Se è inferiore al target, i rilasci si fermano fino a quando i numeri target non tornano a essere quelli pianificati.
Per utilizzare efficacemente questo metodo, dovrai tradurre il tuo SLO target (di solito una percentuale) in cifre reali su cui gli sviluppatori possano lavorare. Ciò significa calcolare il tempo di inattività consentito, che sia dell'1%, dello 0,5% o dello 0,1%, in termini di ore e minuti. I target più comuni includono:
Obiettivo SLA | Tempo di inattività annuale consentito | Tempo di inattività annuale consentito | |
|---|---|---|---|
| Tempo di attività del 99,99% | Tempo di inattività annuale consentito 52 minuti, 35 secondi | Tempo di inattività annuale consentito 4 minuti, 23 secondi | |
| Tempo di attività del 99,95% | Tempo di inattività annuale consentito 4 ore, 22 minuti, 48 secondi | Tempo di inattività annuale consentito 21 minuti, 54 secondi | |
| Tempo di attività del 99,9% | Tempo di inattività annuale consentito 8 ore, 45 minuti, 57 secondi | Tempo di inattività annuale consentito 43 minuti, 50 secondi | |
| Tempo di attività del 99,5% | Tempo di inattività annuale consentito 43 ore, 49 minuti, 45 secondi | Tempo di inattività annuale consentito 3 ore, 39 minuti | |
| Tempo di attività del 99% | Tempo di inattività annuale consentito 87 ore, 39 minuti | Tempo di inattività annuale consentito 7 ore, 18 minuti | |
Budget di errore basati su richieste andate a buon fine
Gli SLO sono meno odiati degli SLA, ma possono creare altrettanti problemi se sono vaghi, eccessivamente complicati o impossibili da misurare. I fattori essenziali per avere SLO che non spingano i tecnici sull'orlo della disperazione sono la semplicità e la chiarezza. Solo le metriche più importanti dovrebbero qualificarsi per lo status di SLO, gli obiettivi dovrebbero essere enunciati in un linguaggio semplice e, come per gli SLA, dovrebbero sempre tenere conto di problemi come i ritardi da parte del cliente.
Rimani aggiornato sugli SLA per risolvere le richieste in base alle priorità e utilizza regole di escalation automatizzate per informare i membri del team di competenza e prevenire le violazioni degli SLA con Jira Service Management.
Scopri di più sulla comunicazione degli imprevisti con Statuspage
In questo tutorial ti mostreremo come utilizzare i modelli di imprevisto per comunicare in modo efficace durante le interruzioni. Puoi adattarlo a molti tipi di interruzione del servizio.
Segui il tutorialL'importanza del processo di analisi retrospettiva degli imprevisti
L'analisi retrospettiva degli imprevisti, nota anche come revisione post-imprevisto, è il modo migliore per esaminare ciò che è avvenuto durante un imprevisto e fissare le lezioni apprese.
Leggi l'articolo