Formazione scritta DevOps

Come favorire l'apprendimento continuo in DevOps?

Dai tuoi progetti software sai già che, anche con checklist, revisioni tra pari, controlli, audit e meccanismi di conformità, i problemi continuano a verificarsi. È inevitabile. Per il team e l'organizzazione DevOps è il momento di creare una cultura capace di diagnosticare i problemi, imparare e migliorare in autonomia. La cultura accetta i problemi e i team sono pronti quando si verificano. Risolverli fa parte del lavoro quotidiano e contribuisce all'apprendimento e al miglioramento continuo. Moltiplichi gli effetti delle soluzioni rendendole trasparenti, disponibili e facilmente accessibili in tutta l'organizzazione DevOps.

Netflix, una delle organizzazioni DevOps di punta, ha realizzato un software interno, Chaos Monkey, per simulare guasti catastrofici nei propri data center cloud. Chaos Monkey distrugge server a caso nei sistemi di produzione, così il team Netflix può acquisire ulteriori garanzie sulla propria capacità operativa di assicurare resilienza, stabilità e qualità del servizio ininterrotta ai clienti. Da ogni guasto trae nuove lezioni e le usa per rendere i sistemi ancora più stabili e resilienti.

Perché è importante creare una cultura dell'apprendimento

Se dopo un incidente si cerca un colpevole, si crea una cultura della paura tra gli ingegneri. L'organizzazione diventa lenta, burocratica e insidiosa sul piano delle dinamiche interne, anziché imparare dagli errori, diventare più resistente e resiliente e prevenirli con maggiore consapevolezza e attenzione. Tutti si preoccupano di tutelarsi. Lavoro, problemi e perfino soluzioni non sono mai pienamente trasparenti.

Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so

1. producono meno lavoro per commettere meno errori.
2. Non sono trasparenti su lavoro, problemi e soluzioni.
3. Non hanno incentivi a trasformare le soluzioni in conoscenze per l'organizzazione.
4. È certo che si ripresenterà lo stesso problema o uno molto simile, perché nessuno dedica tempo ed energie a imparare, condividere, spiegare e rendere visibili problemi e soluzioni.

Conduci i post mortem subito dopo gli incidenti, prima che i ricordi delle cause svaniscano

Gli obiettivi di una revisione post mortem sono semplici:

• Individuare ciò che è stato fatto bene per ricordarsi di ripeterlo in situazioni simili.
• Annotare ciò che si sarebbe dovuto fare diversamente, così da migliorare le proprie tecniche in futuro.
• Prendere nota degli errori commessi e suggerire approcci alternativi o misure di sicurezza da adottare quando si ripresenta un problema simile.
• Capire perché, all'epoca, aveva senso intraprendere (o non intraprendere) l'azione che ha causato l'incidente.

Esaminare i propri errori fa paura e in alcune organizzazioni è pericoloso. Se ammettere un errore espone a critiche o sanzioni, è improbabile che tu lo faccia. È un comportamento controproducente, perché se non capisci un errore passato finisci quasi sempre per ripeterlo. Le organizzazioni che prendono sul serio il miglioramento lo capiscono e si impegnano a creare un processo e una cultura in cui si possano esaminare gli errori in sicurezza.

Quando partecipi a un post mortem, devi accettare alcune premesse:

• Tutti cercano di fare del loro meglio, nei limiti di ciò che capiscono.
• Prendi decisioni sotto stress, con informazioni incomplete.
• Ti viene spesso chiesto di svolgere attività per cui non hai ricevuto formazione, con gli strumenti e le risorse che hai a disposizione.
• In queste situazioni gli errori sono inevitabili.
• Il processo serve a esaminare quanto è accaduto e a capire quali lezioni puoi trarne, senza attribuire colpe alle persone o alle loro azioni.
• Il risultato sarà una valutazione dei processi e dei modi in cui migliorarli, senza giudicare persone o gruppi.

È essenziale che tutte le persone coinvolte accettino pienamente il modello «Nessuna colpa, siamo qui per imparare». Molte organizzazioni si impegnano per creare ambienti così sicuri. La FAA, ad esempio, dispone dell'Aviation Safety Reporting System, con cui i piloti che commettono «errori» possono ottenere l'immunità dalle sanzioni dell'autorità di regolamentazione se segnalano gli incidenti.

Le revisioni post mortem devono sempre definire misure concrete per evitare che l'incidente si ripeta. Tra gli esempi di misure preventive ci sono nuove metriche di telemetria, nuovi casi di test automatizzati, l'individuazione dei tipi di modifiche che richiedono ulteriori revisioni del codice, il refactoring e il disaccoppiamento di componenti complessi che causano problemi frequenti.

Diffondi i verbali delle revisioni post mortem e le lezioni apprese in tutta l'organizzazione. Trasformerai così ciò che ha imparato una singola unità operativa del flusso di valore in conoscenze per tutta l'organizzazione e darai un segnale chiaro a favore di trasparenza, apertura e apprendimento.

Organizza game day per migliorare i sistemi

Un game day è diverso dai soliti eventi di gruppo noiosi in cui le persone estroverse si divertono e quelle introverse guardano il telefono per far passare il tempo.

Durante un game day si simulano guasti catastrofici nei sistemi di test e i team DevOps lavorano per risolverli e imparare.

Per esempio, si arresta un server critico per verificare che il failover funzioni senza interrompere il servizio. Il team DevOps verifica poi se e come funziona il ripristino da backup o dall'Infrastructure as Code (IaC). Individuare problemi durante queste simulazioni aiuta il team a creare sistemi resilienti e tolleranti ai guasti e ad acquisire nuove conoscenze.

Durante la risoluzione il team DevOps costruisce rapporti con altri reparti, provando gli scenari di guasto senza stress. Potrai mettere alla prova e migliorare concretamente la comunicazione e la risoluzione dei problemi nell'organizzazione più ampia.

Potrai inoltre cogliere segnali deboli di problemi più gravi che potrebbero manifestarsi in futuro. Incidenti frequenti a bassa priorità durante queste simulazioni o un piccolo effetto collaterale che ha quasi mandato in crash un altro componente critico dell'architettura sono segnali da considerare e affrontare per migliorare i sistemi.

CONCLUSIONE

Incoraggia il team DevOps ad assumersi rischi calcolati. Le organizzazioni DevOps più performanti come la tua sbagliano più spesso. Va bene ed è anche ciò di cui l'organizzazione ha bisogno per imparare e lavorare meglio.

Rispetto alle organizzazioni tipiche, quelle più performanti hanno l'80% in meno di guasti critici in produzione. In altre parole, hanno 5 volte meno incidenti che incidono sui clienti. Per questo gli ingegneri della tua organizzazione DevOps devono sentirsi liberi di sbagliare e imparare dagli errori.