Le 3 vie di DevOps

I principi di DevOps: the Three Ways
Featured

Le 3 vie di DevOps

I 3 Principi di DevOps: The Three Ways

Quali sono i valori e i principi su cui DevOps si basa e quali sono le fondamenta su cui si poggiano le sue pratiche?

Il paradigma delle 3 Vie (“The Three Ways”) è stato presentato per la prima volta nel libro “The Phoenix Project: A Novel About It, DevOps, And Helping Your Business Win” di Gene Kim, Kevin Behr e George Spafford (il libro è uno dei must-read su DevOps da aggiungere alla tua libreria) e descrive i 3 principi di DevOps che costituiscono fondamento teorico del suo sistema valoriale.

Immaginiamo il percorso verso DevOps come un cammino costituito da tre vie, costellate di pratiche diverse, ma tutte orientate al miglioramento continuo delle nostre organizzazioni ed alla creazione di un luogo migliore in cui lavorare.

Parliamo di principi, è vero, ma i concetti sono tutt’altro che teorici perchè ai principi DevOps espressi nelle 3 vie sono ricunducibili tutte le pratiche DevOps più comuni: 

  • The First Way: Flow & System Thinking
  • The Second Way: Amplify Feedback Loops
  • The Third Way: Culture of Continual Experimentation & Learning.

The First Way: Flow & System Thinking

“The First Way” è la via del Flusso e del Pensiero sistemico: il suo obiettivo principale è quello di velocizzare e fluidificare il flusso di lavoro da sinistra a destra, da DEV ad OPS.
DevOps: the First Way

The First Way: Flow & System Thinking

Questi concetti guida ed i principi che sottendono la Prima Via:

  • Dobbiamo raggiungere la profonda comprensione del flusso di lavoro che va da sinistra a destra, da DEV ad OPS: quali sono tutte le attività che effettuiamo, i diversi step, gli attori che partecipano, il loro contributo, quali i tempi? Solo questa profonda comprensione dell’intero sistema ci consentirà poi di poterlo ottimizzare
  • Dobbiamo guardare al processo nella sua interezza ad un flusso di valore (value-stream) in cui, ogni attore ed ogni step aggiunge qualcosa, in termini di valore, al flusso generale. L’approccio deve essere quindi olistico, non settoriale e non focalizzato sulle attività verticali dei settori potenzialmente coinvolti
  • Quando abbiamo compreso e descritto il flusso, il nostro obiettivo sarà quello di migliorarlo, identificando e rimuovendo vincoli (constraints) e i colli di bottiglia (bottleneck): tutto ciò che è inutile, che non aggiunge valore deve essere rimosso a, quantomeno, ottimizzato
  • Non consentiamo mai che un difetto noto passi a valle: guardiamo al flusso generale, dove non esiste mio o tuo ma solo nostro. Se un problema viene riscontrato, in un qualsiasi step del processo, ci si ferma a correggerlo non si passa “la patata bollente” allo step che segue
  • Non permettiamo mai che ottimizzazioni locali causino un degrado a livello globale: quando progettiamo dei miglioramenti, delle ottimizzazioni le valutiamo sempre per l’effetto e le conseguenze che possono avere sul flusso generale (ad esempio aumentando le risorse o ottimizzando le prestazioni di un sistema rischiamo di spostare il collo di bottiglia altrove, oppure l’aggiunta di più applications server può sovraccaricare un data server e farlo collassare, etc.). Questo principio si applica sia a livello tecnologico che a livello organizzativo. La separazione tra DEV ed OPS spesso causa questo tipo di problemi.
  • Adottiamo un approccio systems thinking quando scegliamo una metrica per misurare le prestazioni dei nostri processi.

Come forse avrai letto nel mio precedente post, DevOps applica il System Thinking all’intero sprettro dei processi IT.

L’approccio sistemico considera una organizzazione IT come “un sistema di sistemi”: un sistema complesso in cui interagiscono persone, strutture organizzative, processi, tools, tecnologie diverse che devono essere valorizzate e armonizzate per co-creare valore. Il punto di vista di DevOps è sempre olistico e il suo obiettivo di miglioramento è complessivo: ridurre il lead-time a beneficio del cliente sono obiettivi che non possono focalizzarsi su un processo particolare o verticale ma sull’intero  flusso di valore.

In pratica DevOps:

  • rappresenta l’evoluzione del ciclo di vita dello sviluppo del software (SDLC) da Waterfall ad Agile/Lean
  • sfrutta i principi Lean per rimuovere gli “sprechi” (Waste/Muda, tutto ciò che è inutile e non aggiunge valore) dall’ SDLC

Alcune pratiche DevOps hanno proprio l’obiettivo di aiutarci ad ottimizzare l’intero il flusso di lavoro consentendo alle persone di autoorganizzarsi attorno a questo obiettivo, in particolare:

  • The Theory of Constraints
  • Value-Stream Mapping.

Theory of Constraints

La Teoria dei Vincoli è un approccio introdotto da Eliyahu M. Goldratt, nel suo libro “The Goal” (il testo che ha poi ispirato “The Phoenix Project”).

L’obiettivo di questa teoria è di identificare il fattore limitante più importante (vincolo) che ostacola il raggiungimento di un obiettivo e quindi migliorarlo sistematicamente fino a quando cessa di essere un fattore limitante.

Secondo Goldratt:

  • Ogni processo ha almeno un vincolo o collo di bottiglia che influenza la sua capacità di raggiungere coerentemente il suo obiettivo
  • La capacità di un processo è pari a quella del suo vincolo principale (l’anello più debole)
  • Ottimizzare/rimuovere i vincoli è il modo più rapido ed efficiente per migliorare l’intero processo o sistema

L’esistenza di ambienti incoerenti, processi di compilazione e distribuzione del software manuali, scarsa qualità, dovuta a pratiche di test insufficienti, obsolete o manuali, mancanza di comunicazione e collaborazione tra silos IT, frequenti interruzioni del lavoro dei team per attività non pianificate, SLA non rispettati, etc., sono esempi tangibili di step, attività che non aggiungono alcun valore al flusso complessivo ma hanno un costo perchè richiedono l’impiego di risorse, di tempo, di denaro per essere eseguite o mantenute.

Altri esempi di vincoli/colli di bottiglia in cui potresti esserrti imbatttuto:

  • Ritardi nello sviluppo
  • Ritardi nella creazione di ambienti (test, staging, produzione, etc.)
  • Problemi nell’implementazione del codice
  • Configurazione ed esecuzione dei Test
  • Assessment su sicurezza e qualità
  • Architetture eccessivamente complesse
  • Processi ingessati e burocratici
  • Eccessivo e inutile ricorso a step autorizzativi.

Value-Stream Mapping

Una Value-Stream è la sequenza di attività necessarie per progettare, produrre e rilasciare valore attraverso specifici processi o servizi e quindi, tipicamente, attraversa più strutture/silos funzionali.

La Value-Stream Mapping (VSM) è una tecnica Lean per descrivere il flow di attività, informazioni o risorse che attraversano i silos funzionali e i relativi processi. L’obiettivo è l’identificazione e quantificazione degli sprechi, inclusi quelli relativi a tempo e qualità.

La tecnica Value-Stream Mapping (VSM) consente a team cross-funzionali di:

  • osservare l’intera Value-Stream da una prospettiva complessiva
  • identificare le aree che non aggiungono valore e quindi rappresentano sprechi (MUDA/Waste) da eliminare o ottimizzare per migliorare il flusso
  • identificare, prioritizzare e misurare i miglioramenti necessari

La mappa del flusso di valore viene utilizzata quindi per comprendere e semplificare i processi utilizzando strumenti e tecniche Lean, sforzandosi di osservare la realtà dal punto di vista del cliente per ridurre gli sprechi e i ritardi che compromettono o rallentano il rilascio di valore.

I principali indicatori presi in considerazione sono:

  • Value-Added Time: la somma della durata di tutte le attività che aggiungono valore al processo
  • Non-Value-Added Time: la somma della durata di tutte le attività che non aggiungono valore al processo (code, ritardi, vincoli, colli di bottiglia, attese, etc,)
  • Total Cycle Time: la durata totale del processo  (Value-Added Time + Non-Value-Added Time)
  • Process Cycle Efficiency: il rapporto tra Value-Added Time e Total Cycle Time (Value-Added Time / Total Cycle Time) da utilizzare come misura della nostra capacità di migliorare il flusso nel tempo.

The Second Way: Amplify Feedback Loops

La prima via ci è piuttosto familiare, siamo abituati al suo scorrere, da destra a sinistra, tipico di quando, ad esempio, Dev rilascia il software a Quality Assurance e questi lo invia ad Ops.

Molto meno intuitivo è invece parlare di flusso da destra a sinistra, da Ops a Dev: si tratta del feedback che, come Dev o Quality Assurance, riceviamo, ad esempio da Ops, come reazione ad un problema (un incident, un errore) riscontrato. Ci è meno familiare perchè non lo consideriamo uno step del processo e non gli dedichiamo tempo sufficiente.

“The Second Way” è la via del Feedback: il suo obiettivo principale è quello di amplificare ed accorciare il feedback loop (da destra a sinistra) che rende possibile il miglioramento continuo.
DevOps: the Second Way

The Second Way: Amplify Feedback Loops

Rendere dispnibili, in modo tmpestivo, le informazioni utili perchè le attività di correzione/change possano avvenire in modo fluido e veloce: senza questo feedback, i team non dispongono delle informazioni necessarie per migliorare continuamente i propri processi.

La Seconda Via ci aiuta a comprendere e rispondere alle esigenze di tutti i clienti, sia interni (i nostri colleghi che lavorano su processi diversi dal nostro) che esterni (come nel caso di un cliente che contatta il nostro Help Desk per segnalarci un disservizio).

E per accorciare questo loop il feedback deve essere “reso visibile” (ad esempio condividendo i relativi indicatori con strumenti telemetria o dashboard).

Con loop di feedback più brevi:

  • crescono la condivisione e la conoscenza
  • aumenta la fiducia
  • comprendiamo meglio i nostri clienti, sia interni che esterni
  • gestiamo i problemi più rapidamente e siamo in grado di prevenirli
  • i processi vengono migliorati con conseguente amplificazione del flusso, velocità di rilascio più elevata, minor quantità di lavoro reattivo e non pianificato.

Ecco alcuni esempi di feedback loop:

  • Automated Testing
  • Peer Review di change in produzione con un team tecnico che si assume la responsabilità della qualità del proprio codice attraverso la revisione e l’approvazione dei change tra pari
  • Change, Incident, Problem e Knowledge Management Data
  • Dashboards/Telemetry
  • Production Log fruibili e trasparenti
  • Misurazione efficace dei processi (metriche, KPIs, Indicatori intelligenti)
  • Gestione efficace degli Incident Post-Mortems (tutte quelle attività finalizzate a trarre lezioni utili dagli incident avvenuti, tipicamente attraverso attività di confronto, analisi e discussione, da effettuare, possibilmente, a valle dell’evento).

The Third Way: Continual Experimentation & Learning

“The Third Way” è la via della contiinua sperimentazione e del continuo apprendimento con l’obiettivo di: (1) incoraggiare una cultura che favorisca la sperimentazione, attraverso l’assunzione di rischi e l’apprendimento che deriva anche dal fallimento, (2) comprendere che solo la ripetizione e la pratica sono il prerequisito per la padronanza.
DevOps: the Third Way

The Third Way: Continual Experimentation & Learning

Continua sperimentazione e continuo apprendimento: abbiamo bisogno di entrambi gli aspetti della Terza Via in ugual modo.

Per questo è necessario stimolare:

  • una cultura che favorisca la sperimentazione ed incoraggi le persone ad assumersi dei rischi è ciò che ci garantisce una spinta continua al miglioramento, anche se questo implica dover uscire dalla propria confort-zone, tentare strade nuove, potenzialmente rischiose ed avvicinarci ad una zona di pericolo più di quanto abbiamo mai fatto prima
  • la consapevolezza e l’accettazione che, per guadagnarci la padronanza delle abilità che possono aiutarci a superare i nuovi problemi è necessaria la “ripetizione e la pratica” continue, l’esercizio costante della nostra capacità di affrontare pericoli ed imprevisti.

Questi due aspetti cruciali del mindset DevOps implicano una rottura con l’approccio aziendale tradizionale, basato sulla colpa e sulla paura, e richiedono una cultura basata sul premiare la capacità di assumersi dei rischi e di tentare strade nuove anche quando potenzialmente rischiose.

Chi vuole davvero innovare sa di doversi esporre ad un rischio tentando strade inesplorate e sa che questo rischio può potenzialmente tradursi in un fallimento. Sa anche però che il fallimento è la strada per l’apprendimento ed il miglioramento e quindi incoraggia e premia le persone coraggiose che accettano di sperimentare e correre rischi.

Le nuove regole del gioco imposte da DevOps relegano il ricorso alla punizione solo al  caso in cui il fallimento derivi da superficilità o dolo.

Alcune delle pratiche che possono aiutarci ad implementare concretamente la Terza Via nella nostra organizzazione sono ad esempio:

  • il ricorso ai Dojo luogi in cui (come nelle arti marziali giapponesi) i membri del team DevOps partecipano a sessioni di addestramento pratico per allenare nuove competenze. I DevOps Dojos (in genere della durata di 6 settimane) offrono ai partecipanti un ambiente coinvolgente e protetto in cui è possibile allenare nuove competenze senza doversi preoccupare di errori che possano compromettere l’ambiente di produzione
  • l’introduzione degli Hackathons (che durano solitamente 24-48 ore ed in genere non più di una settimana) in cui più team si sfidano in una competizione per progettare e realizzare un prodotto innovativo
Nell’attuale contesto di business, in così rapida evoluzione, il fallimento è forse uno dei maggiori vantaggi competitivi che le organizzazioni possono avere.

E ci sono molti esempi concreti di aziende che premiano il fallimento come importante occasione di apprendimento:

  • P&G ha il suo “Heroic Failure Award” (“Eroico Fallimento”)
  • TATA ha il premio “Dare to Try Award” (“Coraggio di provare”)
  • Supercell (società di gaming di Clash of Clans) apre una bottiglia di champagne ogni volta che un nuovo gioco fallisce
  • Google X (un laboratorio di innovazione di Google) premia i propri dipendenti per i fallimenti
  • Etsy assegna il premio annuale “Three-Armed Sweater”, un vero “maglione a tre braccia” (un “maglione sbaglliato”), al dipendente che ha commesso un errore, per dimostrare che gli incidenti sono considerati come una fonte di apprendimento e non qualcosa di imbarazzante per cui si può essere puniti.

Chaos Engineering

La risposta agli attacchi aiuta ad allenare le competenze necessarie per ripristinare l’ambiente di produzione da inevitabili problemi e costringe gli sviluppatori a progettare sistemi resilienti.
  • Il paradigma dell’«Esercito delle Scimmie» (Simian Army) è stato introdotto da Netflix come servizio che termina casualmente un’istanza in ambiente di produzione
  • Chaos Monkey è uno strumento (un demone open-source) che disattiva casualmente le istanze di produzione e viene utilizzato come allenamento per poter gestire i problemi in produzione gestendoli  via via che si presentano (quindi rendendo sempre più resilienti  propri sistemi)
  • il servizio opera solo in giornate ed orari lavorativi (quindi non nei fine settimana, nei giorni festivi o fuori dall’orario lavorativo)  in modo che i tecnici siano in grado di presidiare l’ambiente di produzione e intervenire in caso di problemi prevenendo potenziali disservizi
  • viene utilizzato da organizzazioni mature che vogliono apprendere dai fallimento.
… e così la prossima volta che un’istanza fallisce alle 3 del mattino di domenica, noi non lo noteremo neppure. – Netflix

Encourage a Learning Culture

La creazione di una cultura dell’apprendimento è fondamentale per sostenere la crescita e l’innovazione.

Alla fine di “Beyond The Phoenix Project” (altro libro che dovresti leggere), Gene Kim e John Willis parlano delle organizzazioni ad alte prestazioni che si ispirano ai principi DevOps come di “Organizzazioni ad apprendimento dinamico“.

I piani di formazione aiutano a identificare le competenze necessarie e incoraggiano un vocabolario ed una comprensione comuni ma l’apprendimento è troppo importante per essere relegato solo ad iniziative di formazione istituzionale in aula da svolgere “solo se abbiamo budget”! Le organizzazioni che lasciano che ciò accada restano bloccate nello status quo.

E’ invece importante incoraggiare l’apprendimento quotidiano e la condivisione della conoscenza:

  • creando piani di formazione per accrescere le competenze
  • incorporando l’apprendimento nei processi (come avviene in Scrum con le Retrospettive o attraverso gli Incident Blamess Postmortem)
  • utilizzando la tecnologia per accelerare l’apprendimento (ad esempio attraverso soluzioni ChatOps, canali Slack, Wiki, etc.)
  • adottando un approccio Learning by doing (esperienze immersive, sperimentazioni, demo, Dojo, Hackathons, etc.)
  • capitalizzando gli errori e i fallimenti come fonti di apprendimento
  • rendendo visibili i successi dell’apprendimento

Le nostre fonti

Lasciaci un commento

  • Come tu o la tua organizzazione vivono i principi DevOps descritti nelle 3 Vie?
  • Quanto pensi che le nostre organizzazioni siano disposte a rimettere in discussione i propri processi per renderli più semplici e meno burocratici?
  • Quanto è importante secondo te accorciare il feedback loop? Cosa potremmo fare?
  • Come la tua organizzazione valorizza l’apprendimento continuo? Qual’è la sua propensione al richio intrinseco nella capacità di innovare? Come vive e interpreta il fallimento?

Sono davvero domande importanti a cui non è facile dare una risposta. Se ti va di condividere con me i tuoi dubbi o le tue considerazioni, lasciami un commento qui.

E, per approfondire, puoi dare un’occhiata ad uno dei nostri corsi DevOps online o in aula/virtual room.

A presto!

Stay agile! 🏄‍♀️

No Comments

Give a comment