The DevOps Ways: dieci anni di errori per capire che DevOps è cultura, non strumenti

Il 26 ottobre 2019, a Parma, sono salito sul palco di DevOps Heroes con un talk dal titolo The DevOps Ways. L’incipit era più o meno questo:

Dieci anni fa avevo una pipeline di build, un sistema di deploy automatico, un log collector e pensavo di essere DevOps. In realtà ero molto distante dall’esserlo. Non avevo capito nulla di DevOps.

Le slide, senza una voce che le racconta, servono a poco. Così all’epoca scrissi una serie di quattro post per mettere nero su bianco il mio viaggio nel mondo DevOps: tutte le volte che ho creduto di esserlo e non lo ero affatto. Questo articolo raccoglie la serie in un testo unico, con i typo corretti e le ripetizioni tagliate; il racconto resta quello del 2019. Il talk, con le slide originali, è The DevOps Ways.

2011-2012: l’inizio del percorso

Facevo parte di un team multi-funzionale che sviluppava un’applicazione web. Il front-end era modulare a plugin, con alcune librerie condivise e una parte core che gestiva il caricamento dei plugin e offriva servizi comuni, come il message bus usato dai componenti per comunicare tra loro e con il back-end. Il back-end era un’architettura a micro-servizi, anche loro con librerie condivise e un SDK che esponeva le funzionalità di base della piattaforma: l’accesso al message bus e la comunicazione con il front-end via websocket.

Compilare e testare manualmente i componenti era complesso: il dependency tree da rispettare richiedeva parecchio tempo e la build era un’operazione noiosa e ripetitiva. Eseguendola in locale, il team aveva poca visibilità sullo stato dei test e sugli errori di compilazione causati dalle modifiche ai componenti upstream. Con l’aumentare di plugin, micro-servizi e librerie condivise stava per diventare un problema serio. La soluzione era abbastanza ovvia: automazione delle build e degli unit test.

Il team lavorava in Scrum e ogni due settimane rilasciava il lavoro svolto. Il deploy avveniva su un cloud di tipo platform e bastava un comando per servizio, ma con l’aumentare dei servizi il tempo necessario cresceva. In realtà il problema dei deploy manuali si presentò molto prima del previsto: servivano test d’integrazione per il back-end e test end-to-end per l’intero sistema, da eseguire sull’ambiente in esecuzione. Automatizzammo i deploy e ci rendemmo subito conto che potevamo fare molto di più.

Gli scenari di deploy erano tre: cloud pubblico (di un provider esterno), cloud privato (un’istanza on-premise) e cloud ibrido. La procedura di deploy dell’applicazione non dipendeva dallo scenario, e questo ci aiutò a tenere le automazioni semplici; in alcuni casi, però, dovevamo installare anche il cloud stesso, e la sua installazione doveva essere ripetibile, consistente e funzionante — quindi testata. Automatizzammo anche quella e aggiungemmo test per verificare che l’automazione stessa funzionasse correttamente.

Lavorammo anche per rendere l’applicazione più semplice e rapida da debuggare. I log di ogni istanza di un micro-servizio erano locali all’istanza e sparivano a ogni riavvio, anche a seguito di un crash; ricostruire il percorso di un messaggio — per quali componenti era passato, quanto tempo era servito, quali errori aveva incontrato — era quasi impossibile. Le risposte furono un log collector centralizzato e il tracking dei messaggi.

Il log collector era un ulteriore micro-servizio, sviluppato da noi, con due caratteristiche: funzionare senza alcuna conoscenza degli altri servizi (per permettere scalabilità e auto-configurazione) e aggregare e filtrare i log per intervallo temporale o per micro-servizio.

Il message tracking, invece, non era un componente aggiuntivo: lo implementammo direttamente nell’SDK. Ogni volta che un componente prendeva in carico un messaggio o lo ripubblicava sul bus, aggiungeva un record al messaggio stesso — un JSON — con il nome del componente, i timestamp di presa in carico e di ripubblicazione, ed eventuali codici di errore da usare come filtro nelle query:

{
    "trace": [
        {
            "component": "nome-del-componente",
            "received": "2012-05-17T10:23:41Z",
            "published": "2012-05-17T10:23:42Z",
            "errors": []
        }
    ]
}

Avevamo adottato alcune tecniche tipicamente pubblicizzate come pratiche DevOps:

Continuous Integration
Build & Test Automation
(near) Continuous Delivery — due deploy in staging al giorno per gli e2e test
Log Collector
Telemetry, tramite il tracking dei messaggi

Raccontata così, sembra che avessi proprio ragione a pensare di essere DevOps. In realtà ero molto distante dall’esserlo. Perché?

2012: la mia prima visione di DevOps (era sbagliata)

Nel 2012 la mia visione si poteva riassumere così: DevOps è un processo per lo sviluppo del software; le persone nel processo sono principalmente sviluppatori e sysadmin, con altre figure come tester e security expert; e usiamo degli strumenti che rendono il nostro processo un processo DevOps.

Per metterla alla prova usai la metafora dell’arciere: il processo è l’arco, gli arcieri sono le persone che lo eseguono, le frecce nella faretra sono gli strumenti. Raccontata diventava: «io arciere scocco la freccia della Continuous Delivery perché sono DevOps», cioè «scocco la freccia perché sono l’arco». Non funziona: la metafora non reggeva perché era la visione a essere sbagliata.

I “come” e i “perché”

Il primo errore è banale e lo faccio spesso, anche fuori dal lavoro: confondere il “come” con il “perché”, e dare più importanza al primo. Sapere come fare qualcosa è importante, ma sapere perché la si dovrebbe fare lo è di più. Riassunto in una frase: gli strumenti sono i “come”, gli strumenti non sono i “perché”.

Il tool non fa il DevOps

Le pratiche e gli strumenti usati in ambito DevOps esistevano da prima che esistesse DevOps, da prima che il nome fosse coniato e il movimento nascesse. Identificando chi fa DevOps con chi usa certi strumenti, avevo finito per pensare che usare quegli strumenti rendesse DevOps. Come dice l’antico proverbio: il tool non fa il DevOps… o forse era “l’abito non fa il monaco”.

Un pessimo nome

Patrick Debois, che coniò il termine, dice lui stesso che è un pessimo nome. Parla di tecnici — DEVelopment + OPerationS; non è inclusivo — security e QA restano fuori, e infatti sono nati DevSecOps, DevSecQAOps e ogni altra combinazione; e soprattutto non c’entra nulla con il business, che è invece il vero soggetto: DevOps è un processo che include management e market/customer, non è solo una cosa tra tecnici.

2015: la seconda visione (manca ancora qualcosa)

Nel 2015 la mia visione aggiornata era questa: DevOps è un processo per lo sviluppo del software che va dal management al market/customer; le persone coinvolte sono i tecnici, ma anche stakeholder, clienti e concorrenti; e gli strumenti non sono solo le pratiche tecniche, ma anche le metodologie che servono a gestire il prodotto e il processo.

Riapplicai la metafora dell’arciere a uno scenario concreto: il management chiede di implementare una funzionalità in modo minimale per verificare se è utile ai clienti; deve andare in produzione appena pronta, accessibile solo ai clienti più fedeli, e serve un feedback per capire se la usano. Gli arcieri scoccano la freccia della Continuous Delivery per consegnare in fretta, quella dell’A/B testing per selezionare i clienti che la vedono, quella della telemetria per riportare al management quanti l’hanno usata tre o più volte.

Ora la metafora funzionava: c’erano i bersagli delle frecce, c’era qualcuno che chiedeva di scoccarle, e gli strumenti erano tornati a essere il “come” al servizio di un “perché”. Eppure qualcosa continuava a non convincermi: in questa visione i tecnici sono in secondo piano, meri esecutori, passacarte, quasi strumenti nelle mani del business. Avevamo creato un flusso di informazioni tra due estremi — dal management al mercato e viceversa — costruendo una condotta stagna con sole due aperture, una per estremità. Ci eravamo limitati ad abilitare la comunicazione, comportandoci da soggetti passivi rispetto al processo.

Ed ecco l’altro errore: mi ero concentrato sulla comunicazione e sull’abbattere i muri tra le persone, ma quello che fa davvero la differenza è la collaborazione. Ci sono tante definizioni; a me piace riassumerla in quattro principi:

il perseguimento di un obiettivo comune;
l’unione degli individui (e delle loro capacità) a beneficio del gruppo;
l’accettazione dei ruoli, emersi o imposti;
l’assunzione di responsabilità come gruppo, e degli individui verso il gruppo.

Rimettere i tecnici sullo stesso piano delle altre persone significa iniziare a collaborare tutti insieme per raggiungere l’obiettivo comune: DevOps is about collaboration, non basta comunicare.

La cultura DevOps: The Three Ways

Non esiste un manifesto che identifichi i valori o i principi DevOps, e nemmeno un manuale del perfetto DevOps. Però valori e principi ci sono: i valori affondano le radici nel settore industriale — il Toyota Production System e i movimenti che ne derivano — e i principi furono formalizzati per la prima volta da Gene Kim nel 2012, nell’articolo The Three Ways: The Principles Underpinning DevOps.

The First Way: System Thinking

Spesso ci si riferisce a questo principio come The Principle of Flow o The Principle of Value Stream, ma è inutile formalizzarsi sul nome. Il focus è sul flusso del valore nella sua interezza: DevOps inizia quando vengono identificate le necessità del mercato o dei clienti e termina quando il valore viene consegnato agli utenti finali. Il processo non attraversa solo le fasi di sviluppo del software — analisi, sviluppo, IT Operations, QA, security — ma copre anche quelle precedenti e successive, come il design, la raccolta dei requisiti e lo user testing.

Identificato il flusso del valore, si cerca di enfatizzare le prestazioni dell’intero processo, per ridurre il lead time e incrementare la qualità. L’approccio è quello dello System Thinking: concentrarsi sui collegamenti e sulle interazioni tra le parti che compongono il sistema, analizzandolo nella sua interezza, invece di suddividerlo in elementi separati da studiare in modo isolato. Le conseguenze:

nessuna ottimizzazione “locale” del processo deve creare un degrado a livello globale;
non si trasmette un difetto alle postazioni di lavoro successive;
si cerca di migliorare il flusso del lavoro, velocizzandolo e incrementandolo.

The Second Way: Amplify Feedback Loops

La chiave di questo principio sono le parole amplify e loops — al plurale. La mia esperienza mi porta a classificare i loop in due gruppi, in base a chi li origina: esterni e interni.

I feedback esterni arrivano dal mercato e dai clienti finali, e si possono ottenere in svariati modi: interviste o questionari ai clienti, monitoraggio dell’applicazione, raccolta e analisi delle recensioni. Servono a comprendere le esigenze del cliente e a verificare costantemente che quello che stiamo facendo crei davvero valore per lui.

I feedback interni sono generati dalle persone che lavorano al prodotto, dal processo stesso o dagli strumenti che monitorano lo stato di salute dei prodotti; i loro scopi principali sono garantire la qualità e capire quando il sistema non sta funzionando come dovrebbe.

Lo scopo complessivo di questi feedback è triplice: comprendere meglio le esigenze degli utenti, rispondere in modo più preciso alle esigenze del mercato, garantire la qualità percepita dall’utente finale.

The Third Way: Company Culture

Questo principio è probabilmente il più discusso e il più bistrattato; per me è il più importante dei tre, perché proprio una cultura aziendale che permette di sperimentare e imparare dai fallimenti è il prerequisito per applicare e sfruttare appieno i primi due. Riguarda due fattori:

promuovere la sperimentazione continua, l’assunzione dei rischi e l’apprendimento dai fallimenti;
la pratica e l’esercizio, fondamentali per acquisire la padronanza degli strumenti e dei processi adottati.

Il primo fattore garantisce il miglioramento continuo, ma porta a correre dei rischi: si abbandona la comfort zone e si va incontro a qualcosa di ignoto. La padronanza, invece, permette di tornare in una zona tranquilla, eludere i pericoli o affrontarli prima che possano arrecare danni irreparabili. Quando si esplora e si sperimenta è possibile fallire, ma il fallimento va trasformato in un’esperienza positiva da cui imparare. Un approccio spesso utilizzato è il ciclo di Deming.

Restano da considerare le persone e i loro comportamenti, partendo da due considerazioni generali: i comportamenti delle persone sono influenzati dalla cultura, e la cultura è definita dall’insieme dei comportamenti delle persone. I due fattori si rafforzano a vicenda e, normalmente, mantengono invariato lo status quo. Si può uscire da questo schema? Sì: partendo da un nostro comportamento diverso — possibilmente positivo e migliorativo — possiamo “contagiare” le persone che ci circondano e introdurre un piccolo cambiamento nella cultura locale del team. Una volta avvenuto, il team inizierà a comportarsi in modo diverso con chi gli sta intorno — PM, stakeholder, altri team — e quel comportamento potrà contagiare anche loro: una piccola e lenta spirale positiva di cambiamento della cultura aziendale, nata da alcuni comportamenti isolati. Con un approccio dal basso non cambieremo la cultura di una multinazionale, ma i benefici locali sono concreti e senza grossi attriti; e se l’azienda è piccola, la nostra influenza può creare le condizioni per una transizione strutturata dell’intera organizzazione verso la cultura Lean/Agile/DevOps.

Conclusioni

Gli errori concettuali che ho fatto, riassunti:

gli strumenti sono i “come”, non i “perché”;
il tool non fa il DevOps: non basta usare certe pratiche e certi strumenti per esserlo;
DevOps è un processo che include management e market/customer, non è solo una cosa tra tecnici;
DevOps is about collaboration: non basta comunicare.

Per applicare davvero DevOps servono una forma mentis e una cultura aziendale che promuovano la sperimentazione continua, l’assunzione dei rischi e l’apprendimento dai fallimenti — con i rischi mitigati dalla padronanza degli strumenti e dei processi, consolidata con la pratica. Solo con una cultura di questo tipo si possono applicare con successo le tecniche dei primi due principi e ottenerne i vantaggi: lead time ridotto, alta qualità dei prodotti e dei servizi, attività di sviluppo e manutenzione incentrate sulle esigenze del cliente finale. In altre parole: generare valore in modo rapido e costante.

Quasi certamente, come dicevo all’inizio del talk nel 2019, scoprirò di sbagliare ancora tutto e che DevOps è qualcosa di diverso da quello che oggi penso che sia.

Approfondimenti

Nel frattempo, il racconto dal vivo resta disponibile nella pagina del talk The DevOps Ways, con le slide originali.