I team spesso parlano di bug di produzione come se il costo fosse contenuto nel difetto. Una brutta spedizione condizionale. Una migrazione ha mancato un caso limite. Un consumatore in coda ha riprovato in modo troppo aggressivo. Correggi il codice e il costo termina.
Questa visione è troppo piccola.
Il costo di un bug di produzione non è solo la riga di codice che lo ha causato. È il tempo che l'organizzazione trascorre vivendo attorno ad essa.
L'attesa cambia la forma dell'incidente
Un bug che viene risolto in cinque minuti è solitamente un problema di codice. Un bug che attende per un'ora diventa un problema di coordinazione. Un bug che attende per un giorno diventa un problema di fiducia.
Lo stesso difetto di fondo può creare danni molto diversi a seconda di quanto tempo rimane in vita:
- I clienti percorrono ripetutamente lo stesso percorso interrotto.
- I team di supporto raccolgono i ticket senza una risposta sicura.
- I team di vendita o di successo iniziano a scrivere spiegazioni temporanee.
- Gli ingegneri mettono in pausa le distribuzioni nelle vicinanze perché non sono sicuri di cosa sia sicuro.
- Altri dati entrano nel sistema in uno stato non valido o parzialmente gestito.
- Il contesto di distribuzione originale svanisce dalle persone che lo possedevano.
Nessuno di questi costi è esotico. Sono normali trascinamenti della produzione.
MTTR perde alcuni minuti costosi
Il tempo medio di recupero è utile, ma può nascondere i momenti che creano più sprechi.
L'orologio solitamente si avvia quando viene rilevato un problema e si ferma quando il servizio viene considerato ripristinato. Questo dice qualcosa di importante sull'affidabilità. Non indica quanto tempo è stato impiegato nell'incidente per comprendere l'errore, trovare il proprietario, raccogliere prove o attendere una modifica rivedibile.
Per i flussi di lavoro di riparazione, il costoso divario spesso si presenta così:
alert -> evidence -> code path -> owner -> patch -> review -> deploySe il team riesce a comprimere i primi quattro passaggi, la revisione del codice inizia prima e la correzione finale diventa più facile da valutare.
Il decadimento del contesto è un costo reale
È più facile ragionare sul codice recente. L'autore ricorda perché è avvenuto il cambiamento. I revisori ricordano la discussione. Il flag di funzionalità, il piano di implementazione e le ipotesi di test sono ancora freschi.
Col passare del tempo, le indagini si fanno più pesanti. Gli ingegneri rileggono le decisioni prese ore fa. Ricostruiscono la finestra di distribuzione. Riaprono i dashboard. Chiedono se il problema è legato a un altro incidente. La soluzione potrebbe essere ancora piccola, ma la fiducia necessaria per unirla diventa più difficile da costruire.
Una riparazione rapida non è solo una questione di velocità. Si tratta di preservare il contesto finché il team ce l’ha ancora.
Il costo non è sempre visibile nei dashboard tecnici
Alcuni problemi di produzione sembrano modesti in termini di telemetria e continuano a danneggiare l’azienda.
Un bug relativo alle autorizzazioni potrebbe interessare un numero limitato di account di alto valore. Un bug relativo allo stato di fatturazione potrebbe apparire come un caso limite a basso volume durante la creazione di attività finanziarie manuali. Un problema di pagamento potrebbe interessare solo un metodo di pagamento in una regione, ma l'impatto sul supporto può essere immediato.
I dashboard tecnici sono necessari, ma raramente riescono a catturare l'intero onere del ripristino. Il giusto brief sull'incidente dovrebbe includere il percorso del cliente, l'impatto sull'account o sul tenant quando disponibile, il segnale di supporto e la proprietà del codice insieme a tracce e registri.
Ciò che riduce i costi di attesa
I team riducono i costi di attesa quando eseguono indagini e revisioni nello stesso ciclo.
Ciò significa:
- l'avviso è legato alle relative tracce e log
- la finestra di errore viene confrontata con le distribuzioni
- viene denominato il percorso del codice sospetto
- la proprietà viene risolta automaticamente
- la patch proposta è abbastanza piccola da poter essere esaminata
- l’incertezza è visibile invece che nascosta dietro una formulazione fiduciosa
È qui che risulta utile la riparazione assistita dall’intelligenza artificiale. Non dovrebbe apportare una modifica segreta alla produzione. Dovrebbe preparare le prove, redigere la più piccola soluzione plausibile e consegnare al proprietario una richiesta pull che può essere accettata, modificata o rifiutata.
La vera metrica è il tempo per prendere una buona decisione
Una squadra non vince perché un bot produce rapidamente una differenza. Vince quando il revisore giusto riesce a prendere una buona decisione prima.
A volte la decisione è "unire la correzione". A volte è "rollback". A volte è "questo è un incidente a monte". A volte è "abbiamo bisogno di un'indagine umana, non di una patch".
Aspettare è costoso perché ritarda tutte quelle decisioni. L’obiettivo non è l’automazione frenetica. L’obiettivo è un percorso più breve dalla produzione del segnale all’azione supportata dall’evidenza.
