L'anomalia irriproducibile: il bug che esiste solo in produzione

Narratore: Allineiamoci Offline è un podcast di fiction satirica sul mondo dell'IT aziendale, realizzato interamente con voci sintetiche. Ogni somiglianza con riunioni realmente vissute non è casuale, ma comunque non è una nostra responsabilità. È giovedì mattina. Il Junior apre un ticket di supporto: per un solo cliente, un'interfaccia si blocca ogni volta. Il cliente usa la stessa sequenza di azioni da settimane. Il Junior, fiducioso, riproduce la sequenza in staging.

Junior Developer: Sequenza identica: apro la schermata, carico il file, clicco conferma. In staging funziona. Riprovato tre volte. In produzione si blocca sempre, e solo per questo cliente. Che significa?

Senior Developer: Significa che il bug esiste solo in produzione.

Junior Developer: Ma se non riesco a riprodurlo, come facciamo a correggerlo?

Senior Developer: Innanzitutto, guardiamo i log di produzione.

Junior Developer: Li ho già guardati. Sono oscurati per privacy: al posto dei valori c'è scritto 'valore oscurato'. Ogni riga. Ho passato mezz'ora a leggere 'valore oscurato'.

Senior Developer: Classico.

Junior Developer: E poi staging ha dati di test generati da un vecchio script, anni fa: nomi tipo 'Cliente Test Uno'. Il cliente reale si chiama in un altro modo, e il sistema in staging non ha mai visto niente di simile. Perché i due ambienti sono così diversi?

Senior Developer: Lo staging è stato 'allineato alla produzione' tre anni fa. Con uno script di sync. Mai rilanciato di nuovo. E copiare i dati reali è vietato per policy.

Junior Developer: Quindi lo script di allineamento ha allineato gli ambienti per un giorno, nel 2023, e da allora si differenziano ogni giorno di più.

Senior Developer: La policy protegge i dati. La protezione funziona benissimo: i dati di produzione non riescono a raggiungere nessuno, nemmeno noi.

Junior Developer: Quindi per correggere un bug di produzione dobbiamo indovinare le differenze tra produzione e staging a memoria, senza dati e senza log leggibili.

Senior Developer: Esatto. Si chiama esperienza. Si acquisisce proprio così.

Junior Developer: E adesso?

Senior Developer: Procediamo come da manuale: copio il ticket in staging, gli do una priorità, e aspetto che il bug decida di manifestarsi anche qui.

Narratore: Il Senior copia il ticket in staging. Il ticket entra nell'ambiente di test e non succede più niente. Poco dopo, entra il Product Owner: il cliente ha minacciato di aprire una segnalazione formale e vuole una stima di risoluzione da dare in call nel pomeriggio.

Product Owner: Allora, situazione veloce: il bug è grave? È riproducibile? Quanto tempo serve? Il cliente vuole una data in call alle tre. E il commerciale ha già promesso che è 'sistemato entro oggi'. Io devo almeno mantenere la coerenza.

Junior Developer: Nessuno sa ancora cosa causa il blocco. Siamo all'inizio.

Senior Developer: Entro oggi non si sistema niente. Ma 'sistemato' è una definizione, non uno stato.

Product Owner: Ok. Ok. Posso dire al cliente che ci siamo già attivati?

Junior Developer: Tecnicamente sì. Ci siamo attivati da tre minuti.

Product Owner: Perfetto. 'Il team è già al lavoro'. È vero, non è una bugia, è una verità molto recente.

Senior Developer: È la verità con la data di oggi.

Product Owner: Perfetto, allora alle tre dico: team attivato, analisi in corso, aggiornamento domani. Non specifico cosa stia analizzando il team, giusto?

Junior Developer: Meno dettagli metti, più a lungo resta vero.

Narratore: Nel pomeriggio la stima viene comunicata al cliente. Il giorno dopo, il team è di nuovo in call con il cliente per presentare il piano di risoluzione.

Product Owner: Ringraziamo per la pazienza. Oggi presentiamo il piano di risoluzione, strutturato in fasi: analisi, contenimento e consolidamento.

Narratore: Mentre il Product Owner parla, il Senior analizza in silenzio i log di produzione su un terminale. Il piano ufficiale prevede quarantotto ore di analisi. Il Senior ci mette dieci minuti, ma il piano non ammette confronti.

Senior Developer: Trovato. C'è un limite di configurazione sul record di questo cliente. Impostato a mano in produzione, nel 2019. Mai documentato. Ogni volta che l'interfaccia incontra quel limite, si blocca.

Junior Developer: Chi l'ha impostato?

Product Owner: Scusate, torno dalla call: devo dire al cliente che la causa è identificata? Posso usare la parola 'identificata'?

Junior Developer: La causa esiste, però è stata impostata da una persona non identificata, in un anno non documentato.

Senior Developer: Non ricordo. Era un'emergenza. I sistemi così si costruiscono: un'emergenza per volta.

Junior Developer: E non era scritto da nessuna parte?

Senior Developer: Era temporaneo.

Junior Developer: Ha sei anni.

Senior Developer: La correzione è una riga: tolgo il limite, riavvio il servizio. Fatto.

Product Owner: Attenzione: al cliente presentiamo il piano in tre fasi. Non gli diciamo che è una riga.

Junior Developer: Perché? Se è una riga, la facciamo subito.

Senior Developer: Perché una correzione da una riga richiede comunque la valutazione d'impatto. E la valutazione d'impatto dura più di una riga.

Product Owner: Esatto. Fase uno: analisi, che abbiamo appena fatto. Fase due: contenimento, cioè la riga. Fase tre: consolidamento, cioè documentiamo che era temporaneo.

Junior Developer: Quindi documentiamo il limite dopo averlo tolto.

Senior Developer: Documentiamo la sua memoria.

Narratore: Il piano in tre fasi viene approvato dal cliente. La riga viene eseguita durante la fase due. Il bug scompare e il ticket viene chiuso come risolto secondo procedura. Il limite del 2019, a sei anni dalla sua introduzione, ottiene finalmente una riga di documentazione. La prossima volta che in staging tutto funziona al primo colpo, ricordate: è solo perché lo staging non è abbastanza simile alla produzione. Alla prossima Allineiamoci Offline.