Creato il 05.06.2019

Vita da sviluppatori: storia della correzione di un bug

Ci colgono quasi sempre nel momento sbagliato e possono darci parecchio filo da torcere: i bug. Del resto, soprattutto con le nuove tecnologie, sono praticamente inevitabili. Simon Vogt, software engineer presso PostFinance, ha esperienza con i bug, come dimostra il suo esempio.

Il bug piomba in riunione

È giovedì, poco prima di mezzogiorno. Durante una riunione nella nostra sede di Mingerstrasse a Berna, dove si trova una parte della nostra IT, mi arriva un’e-mail di Jan. È il product owner con cui, in veste di software engineer, collaboro a stretto contatto su un progetto innovativo. L’oggetto dell’e-mail è: «I: nessun dato». Il contenuto dell’e-mail è altrettanto conciso: giusto la citazione dell’Apollo 13 «Houston, abbiamo un problema!» e un link a un tabulato. Nessun dato disponibile. Il tabulato è vuoto, cosa che non dovrebbe essere e che fino a quel momento non era nemmeno mai stata. E questo nella versione produttiva (interna) chiamata «brikks». Nemmeno il tempo di digerire il primo shock che ecco comparire nella finestra di chat il messaggio «Simon, hai distribuito tu la versione nell’ambiente produttivo?». No, certo che no.

Mi sono forse distratto per un momento?

Il battito aumenta, in testa si affollano mille pensieri. O invece l’ho fatto? Ma come è potuto succedere? Forse in un momento di distrazione? Mi sembra molto strano. E poi la versione produttiva è stata lanciata già un mese fa e finora ha funzionato senza alcun problema serio di deployment. E ovviamente, l’attuale base di codici contiene migrazioni di banche dati delicate che prevedono la rimozione dei dati obsoleti dalla banca dati. Qualcosa è andato storto? Sarebbe davvero imbarazzante.

Non è possibile!

In chat scrivo a Jan che lo avrei richiamato subito, abbandono la riunione prima del dovuto, salgo in bici e pedalo in direzione Engehalde, il mio luogo di lavoro ordinario. Nel frattempo sono già al telefono con Jan. Mi chiede ancora una volta se stamattina ho effettuato il deployment alla produzione. Il master branch presenta lo stato live. Nel frattempo realizzo con certezza di non aver effettuato modifiche e rispondo: «No, non ne so nulla! Per favore, guarda velocemente chi ha effettuato la distribuzione nel deployment log». Ma Jan lo aveva già fatto: «Il log dice che l’ultimo deployment alla produzione è stato fatto due settimane fa».

Il primo sospetto

Entrambi riflettiamo un attimo. Jan mi comunica di aver ricevuto quella stessa mattina un messaggio d’errore da parte della piattaforma di coordinamento Kubernetes e mi chiede se questo possa avere a che fare con il problema. Che disastro. Ho un certo presentimento e spiego a Jan che nel nostro setup di Kubernetes rimandiamo ancora al :latest tag della nostra docker image. Jan aggiunge: «E tu credi che Kubernetes dopo i messaggi d’errore stamattina abbia automaticamente ripreso la docker image più recente?» Entrambi sospettiamo la stessa cosa: sì, potrebbe essere.

«It’s not a bug, it’s a feature» ... ;-)

È così. Poco dopo, una volta ritornati alla postazione di lavoro, affrontiamo il problema del tabulato vuoto. Con nostro stupore e per fortuna, riusciamo a rimuoverlo direttamente nell’interfaccia utente, poiché non direttamente legato al problema del deployment. Successivamente, creiamo un avviso per i nostri utenti in cui segnaliamo che è stata distribuita una nuova versione di brikks. Come dire, all’insegna del motto «It’s not a bug, it’s a feature» ... ;-)

Retroscena del bug e del bug fixing

Presso PostFinance lavoriamo con nuove tecnologie, tra cui anche Kubernetes. Poiché non volevamo complicare inutilmente le prime esperienze con la piattaforma di coordinamento, all’epoca avevamo consapevolmente strutturato il nostro deployment setup nel modo più semplice possibile. Anche perché volevamo lanciare la soluzione il prima possibile per raccogliere velocemente le interazioni e i feedback dei clienti. In fase di strutturazione del deployment setup avevamo espressamente messo in conto quanto riportato dal seguente avvertimento ufficiale: «Note: You should avoid using the :latest tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly».

Nel backlog avevamo registrato un improvement, senza però attribuirgli una priorità alta, con la conseguenza che ora a darci da fare non era l’improvement programmato nel backlog, bensì un bug critico. Ora vi starete chiedendo: «E il PSP, il Potentially Shippable Product?». Giusto. In linea di principio, per ogni modifica nel master branch abbiamo un PSP che può essere distribuito. Tuttavia, in questo caso avremmo preferito un’introduzione controllata delle modifiche, poiché volevamo effettuare anche diverse modifiche dell’interfaccia utente e informare gli utenti con anticipo.

Cosa abbiamo imparato dal bug

Nel frattempo tagghiamo le nostre docker image riuscendo così a liberarci anche del :latest tag nella configurazione del deployment. Non siamo riusciti a chiarire in modo definitivo la causa del riavvio dei pod Kubernetes. È più che possibile che Chaos Monkey abbia causato problemi. In questo caso, in effetti, la configurazione non era ottimale e ne avevamo espressamente tenuto conto. Per fortuna siamo riusciti a risolvere tempestivamente il problema.

Gli sviluppatori presso PostFinance lavorano assumendosi una buona dose di responsabilità personale, all’interno di un ambiente agile e di un team che promuove una cultura positiva dell’errore. Vi interessa lavorare come sviluppatori? Saremo lieti di ricevere la vostra candidatura spontanea.

Candidatura spontanea

Navigare in PostFinance

Immissione termine di ricerca

Ricerca risultati live

Le sezioni del nostro sito

Selezione della lingua