Colmare le lacune: l'importanza della comunicazione DevOps

Anche se la metodologia DevOps è con noi da un po' di tempo, è ancora al centro di accese discussioni. Le aziende lo vogliono ma non sono sicure su come affrontarlo.

DevOps è ovunque. E sebbene sia una tendenza interessante, dovrebbe essere adattata ai prodotti, non viceversa.

Ma alcune persone non la vedono in questo modo. Mi vengono spesso poste domande del tipo: "Pensi che dovremmo iniziare a utilizzare Docker o saltare direttamente a Kubernetes?" Domande del genere sono prive di significato senza nemmeno sapere di cosa tratta il prodotto.

Tutti quei termini fantasiosi (cloud, Kubernetes, container, gestione della configurazione, Infrastructure-as-Code) promettono qualche miglioramento. Ma sono per DevOps proprio come i telescopi per l'astronomia. Possono essere utili, ma non sono necessari.

Fondamentalmente, DevOps mira a colmare il divario tra ciò che il cliente ha ordinato e ciò che il team di sviluppo ha consegnato. C'è un'enfasi sui cicli di rilascio brevi, sull'approccio iterativo alla progettazione e sull'automazione dei passaggi ripetitivi. Cosa pensi sia più importante per portarli alla realtà?

Se hai detto "ottima comunicazione", hai ragione. Gli strumenti sono tutti a posto. Ma valgono solo i soldi investiti in loro quando migliorano la comunicazione.

Un aspetto della comunicazione è sapere cosa è necessario per portare a termine il lavoro. E il lavoro non significa "il codice è impegnato nel repository". Pensalo piuttosto come "il cliente ha visto il cambiamento nella produzione e l'ha accettato".

Non appena questo primo passo è determinato e tutti sanno cosa deve succedere, è il momento migliore per scriverlo. Dove? Bene, sono un grande sostenitore del mantenimento di un README.md . Ogni persona di un team può sempre sbirciare al suo interno e conoscere lo stato di un progetto, ed è un punto di riferimento naturale per i nuovi arrivati.

L'automazione, il passaggio successivo alla scrittura di un README, è facoltativa. Tuttavia, è una conseguenza naturale della documentazione del processo. E sì, l'automazione è ciò che viene spesso in mente quando si pensa a DevOps.

Aspetta un minuto... l'automazione è facoltativa quando si tratta di DevOps? DevOps non è il dipartimento della persona che esegue le distribuzioni?

Ciò che le persone di solito capiscono con il termine "ingegnere DevOps" è un ingegnere dell'affidabilità del software, un ingegnere della piattaforma o un ingegnere dell'automazione delle operazioni. Questi sono tutti ruoli validi che consentono di praticare DevOps, ma l'utilizzo del termine collettivo "ingegnere DevOps" potrebbe essere un po' ambiguo.

Quindi diamo un'occhiata più da vicino a DevOps stesso.

DevOps spiegato

Innanzitutto, lascia che ti mostri cosa non è DevOps:

1. Non è solo un prefisso del titolo di lavoro
2. Non è una squadra (ma “Dev” e “Ops” lo sono)
3. Non è una tecnologia
4. Non significa "un amministratore di sistema in grado di programmare"
5. Non significa "automatizzare le cose"
6. Non significa "non c'è nessun team operativo ora"

Sapendo questo, ora sei consapevole che non puoi semplicemente "assumere un ingegnere DevOps" o "creare un team DevOps" in un'azienda per assicurarti di essere a prova di futuro. DevOps è simile allo sviluppo Agile. Assumeresti uno sviluppatore Agile in quanto tale ? Probabilmente no. O sviluppi un prodotto in modo agile o no.

Come si può quindi descrivere DevOps? È una metodologia. O forse una cultura. Forse anche uno spirito. Realizzare un prodotto secondo i principi DevOps significa che tutti, sviluppatori, ingegneri operativi o product manager, condividono una visione comune, mantenendola attraverso la comunicazione. In misura minore, significa anche che tutti usano gli stessi strumenti. Questi strumenti non hanno lo scopo di aiutare nessun singolo gruppo di persone. Hanno lo scopo di spingere il prodotto in avanti.

Seguire questo concetto richiede un serio cambiamento di mentalità, che è l'ostacolo principale. Perché? È perché le persone devono uscire dalla loro zona di comfort e iniziare a collaborare con persone che hanno competenze diverse. Gli sviluppatori hanno improvvisamente bisogno di imparare come funziona il cloud e iniziare a distribuire il proprio codice. Gli addetti alle operazioni devono abbandonare le impostazioni manuali e iniziare a codificare. Tutti hanno bisogno di imparare nuovi concetti. Ognuno ha nuove responsabilità .

Non è facile, ma con una buona comunicazione e un obiettivo comune è abbastanza realizzabile. Questa comunicazione implica la creazione di una cultura, la creazione di processi leggeri e il mantenimento di una documentazione adeguata.

DevOps Automation è documentazione

Probabilmente non l'hai mai pensato in quel modo. Ma la maggior parte degli strumenti comunemente associati a DevOps sono strumenti di documentazione :

• Gli script di compilazione scritti per la leggibilità servono a documentare il processo di compilazione
• Le pipeline di integrazione continua documentano il processo di integrazione, dalla costruzione di singoli pezzi a un intero prodotto
• Le pipeline di distribuzione continua vanno oltre documentando come distribuire un prodotto che il tuo client può utilizzare
• I file di gestione della configurazione documentano il processo di installazione e configurazione
• Le specifiche dell'infrastruttura come codice documentano l'infrastruttura necessaria (in modo abbastanza formale, in effetti!)
• I container vengono forniti con i propri Dockerfile che documentano come creare e configurare un determinato microservizio

Tutti questi concetti fantasiosi fanno fondamentalmente una cosa: aiutano i membri del team a comunicare meglio documentando i processi. Questi processi possono quindi essere eseguiti manualmente o essere automatizzati. L'importante è che ogni stakeholder in un progetto sia in grado di seguirli.

Documentare i tuoi processi come codice ha un grande vantaggio rispetto ai normali manuali di istruzioni. Il codice può essere verificato e si comporta in modo predittivo. Dato lo stesso input, produce lo stesso output.

Con le istruzioni scritte, avrai tante interpretazioni quanti sono i lettori. Se scrivi documentazione ambigua o vaga, la persona che la legge riempirà le lacune. Il punto è che non hai alcun controllo su ciò che va negli spazi vuoti.

È molto più semplice con il codice. Senza misure concrete, il programma cesserà di funzionare. Questi passaggi concreti sono un aspetto chiave della comunicazione DevOps.

Comunicazione DevOps: l'unico modo per colmare il divario tra sviluppo e operazioni

Nel libro The Phoenix Project assistiamo ai problemi di un manager recentemente promosso incaricato di implementare un grande progetto. Poiché nessuno sa cosa sta succedendo, tutti stanno combattendo gli incendi senza molti progressi. Il sottotitolo del libro menziona che è una storia di DevOps. Sono d'accordo.

Ma la cosa interessante è che nel corso del libro non viene introdotto un solo nuovo strumento. Riesci a raggiungere uno stato di DevOps solo migliorando la comunicazione? I protagonisti del libro ce l'hanno fatta, quindi c'è speranza anche per te!

Anche se l'approccio dei protagonisti può essere considerato "vecchia scuola" (utilizzando vere e proprie carte di carta invece di un vero e proprio sistema di tracciamento dei bug), le cose iniziano a cambiare in meglio solo quando tutte le parti coinvolte iniziano a dialogare tra loro.

Potresti pensare che sia possibile migliorare la collaborazione tra sviluppo e operazioni solo creando migliori interfacce tra di loro, come accordi sul livello di servizio o arretrati di incidenti. Ma l'opposto è vero. Abbattendo le interfacce e introducendo empatia e una causa comune, avrai una squadra che lavora per un obiettivo comune.

Struttura del team DevOps: chi fa parte di un team?

Idealmente, ogni prodotto dovrebbe avere un solo team: il team del prodotto.

Una volta ero in un team di sviluppo in cui un obiettivo comune con gli altri team era assente. Il team di sviluppo voleva spingere il maggior numero possibile di modifiche. Il team di convalida aveva il compito di prevenire l'introduzione di difetti. Avevano manager diversi e venivano valutati individualmente.

Il risultato? Lo sviluppo e la convalida hanno giocato a ping-pong con i rapporti sui difetti. Quando Validation ha trovato un test che non sarebbe andato a buon fine, lo sviluppo era più interessato a trovare difetti nel codice di test stesso che a cercare di rendere il proprio codice privo di bug.

Il ciclo di rilascio è ovviamente aumentato a dismisura, poiché è stato necessario un enorme sovraccarico per compilare correttamente i rapporti, i contro-rapporti e così via. Ciò che la maggior parte sembrava non riconoscere è che in termini di prodotto, entrambi i team dovrebbero condividere un obiettivo comune e lavorare insieme per raggiungerlo. Ma la mancanza di un'adeguata cooperazione e mentalità da silo rendeva molto difficile accorgersene.

La lotta ai rifiuti è uno sforzo congiunto

La mentalità di produzione snella che ha ispirato The Manifesto for Agile Software Development (che a sua volta ci ha presentato DevOps) riguardava la lotta agli sprechi. Per rifiuto si intende tutto ciò che non è direttamente attinente a quanto ordinato dal cliente. I lavori in corso accatastati sono uno spreco. Ogni fase di un processo che non porta chiaramente al rilascio è uno spreco.

Ma i rifiuti possono essere visti solo da un livello elevato. Nell'ambito di una squadra, alcune procedure possono sembrare essenziali. Dal punto di vista del prodotto, tuttavia, potrebbero essere inutili.

Per capire quali sforzi vengono sprecati, è necessario unire le forze e considerare il ciclo di vita di un prodotto spedito. Devi anche pensare dal punto di vista del cliente. Questa caratteristica è qualcosa che il cliente desiderava? In caso contrario, puoi anche saltarlo in questo momento. I tuoi processi sono semplici e snelli? Dai uno sguardo più approfondito, specialmente su quelli che oltrepassano i confini del team.

Vuoi assicurarti che lo sviluppo di un prodotto sia il più efficiente possibile? Invita un estraneo a vedere come lavori. Una persona che non fa parte del tuo team sarà in grado di porre domande approfondite e individuare nuove aree di miglioramento.

Principi DevOps: mantieni la calma

CALMS è una descrizione molto accurata di come fare pratica con DevOps:

• Cultura
• Un'automazione
• magra
• misura
• Condividere

Nota che ha la forma di un panino. I tre valori intermedi sono più tecnici, mentre quelli esterni si riferiscono alle competenze trasversali. Ma la base di tutta la cultura è la comunicazione: scambiamo i nostri valori e le nostre convinzioni con gli altri membri del team fino a raggiungere un consenso su come le cose dovrebbero comportarsi.

Lo stesso vale per la condivisione. Condividere qualcosa di semplice come il cibo non richiede comunicazione. Il gesto stesso, però, può anche essere visto come un atto di comunicazione. "Mi preoccupo per te, quindi condivido con te." Non vogliamo limitare l'ambito alla sola comunicazione verbale.

La condivisione di idee e strumenti, tuttavia, richiede comunicazione. Come dovremmo condividerli? Dove li mettiamo? Sono utili per ogni persona in una squadra o solo per un gruppo più piccolo?

Se ti concentri solo sugli aspetti più tecnici (Automazione, Lean e Misurazione) perdi il senso di DevOps. Cosa c'è di così buono nell'avere uno script di distribuzione automatizzato che nessuno usa mai oltre all'autore? Se la sceneggiatura le fa risparmiare tempo, potrebbe essere giustificato. Ma immagina quanto tempo potrebbe essere risparmiato se tutti condividessero questo script. Questo dice qualcosa sulla lotta allo spreco!

DevOps avvicina il business allo sviluppo

Alcuni sostengono che DevOps avvicini le operazioni allo sviluppo. Questo è vero, ma non è tutta la verità. Se eseguito correttamente, DevOps avvicina ogni unità. Consente alle aziende e ai clienti di vedere cosa sta facendo lo sviluppo, quasi in tempo reale.

Questo ciclo di feedback più breve va a vantaggio di tutte le parti interessate. Il lavoro è generalmente più visibile e anche gli sviluppatori possono vedere facilmente come i client utilizzano il codice che producono. Con la distribuzione tradizionale, puoi attendere diversi mesi prima che qualcuno noti bug o requisiti mancati. Con l'implementazione continua, tutti possono reagire a qualsiasi problema non appena si presenta. Sviluppatori, operazioni, aziende e clienti possono sedersi in una stanza e modificare l'applicazione di lavoro in base alle esigenze attuali.

Prima gli strumenti DevOps? Pensa di nuovo

Naturalmente, sono necessari tutti gli strumenti per renderlo possibile.

Ma nessuna quantità di strumenti può sostituire una buona comunicazione ed empatia all'interno dell'azienda. Una volta ho osservato un prodotto in cui il processo di compilazione era di proprietà di un team, mentre il codice fornito era di proprietà di un altro.

I problemi con il sistema di compilazione erano comuni. Gli sviluppatori non erano sicuri di come usarlo. Si basava su strumenti standard ma sono stati personalizzati al punto che ogni documentazione disponibile sul web si è rivelata inutile.

Tutti volevano migliorare la situazione, ma tra le due squadre non c'era intesa. Ciò significava che entrambe le parti hanno introdotto nuovi strumenti senza consultare l'altra parte. Questo ha solo ampliato il divario, invece di chiuderlo.

Se vuoi avviare una trasformazione DevOps all'interno della tua organizzazione, inizia migliorando il modo in cui comunichi. Non dare semplicemente per scontato una soluzione: fai prima un brainstorming con una mente aperta. Quindi potresti scoprire che, ad esempio, il supporto degli strumenti non è sufficiente per le tue esigenze. È allora che puoi considerare di modificare i tuoi strumenti attuali o di introdurne di nuovi, altrimenti probabilmente andrai ad aggiungere al problema originale.

Il modo più rapido per creare DevOps? Migliore comunicazione!

Nell'introduzione, ho menzionato la domanda che spesso i clienti mi fanno: "Dovrei andare con Docker o dovrei passare direttamente a Kubernetes?" Dopo aver letto questo articolo, puoi vedere che è meglio rispondere a una domanda del genere dopo aver svolto un po' di lavoro di preparazione, con una mentalità DevOps.

Se sai che il tuo team di prodotto comprende i vantaggi di DevOps per se stesso e per il cliente, il team e il cliente possono iniziare definendo le proprie aspettative. Quindi gli ingegneri possono capire il modello di sviluppo e distribuzione. Infine, puoi determinare quali strumenti sono necessari.

Una volta che tutti i requisiti sono stati documentati, le scelte tecnologiche sono molto più facili da fare.

Sono un sostenitore di tutti i grandi strumenti di automazione DevOps che rendono il nostro lavoro più semplice e gestibile. Ma il nostro lavoro quotidiano è lavorare con le persone . Investiamo un po' di tempo per migliorare questo aspetto delle best practice DevOps piuttosto che ottenere un altro certificato tecnologico.