Certificazione DevOps

Oggi diamo inizio a una serie di articoli che dovrebbero dare una “direzione di studio” a coloro che vogliono approfondire il tema DevOps “sui libri”.

Come ho già fatto con l’articolo ad alto tasso alcolico, stilerò un indice di argomenti che proverò a sviscerare singolarmente e userò questo articolo come punto di raccordo per coloro che volessero seguirne il percorso.

Ma andiamo con ordine.

Per quanto mi riguarda, la prima regola del DevOps è:

Non dovrebbe esistere nessun DevOps

Frase che non è un modo per estrinsecare un istinto autolesionista, ma per dire che se tutti facessero le cose collaborando e condividendo gli obiettivi, non sarebbero necessarie figure di raccordo che fanno parlare il Dev con l’Ops.

Ergo, la massima aspirazione di coloro che promuovono la metodologia DevOps dovrebbe essere, a mio parere, arrivare al giorno in cui la metodologia stessa perda la sua connotazione “di aiuto esterno”, di “corpo estraneo”, perché entrata finalmente nel DNA dei gruppi di lavoro.

Grazie alla progressiva introduzione delle tecnologie cloud nei progetti e agli strumenti “implicitamente DevOps” che queste rendono disponibili, sono fiducioso che prima o poi questa cosa possa accadere, ma al momento il problema rimane, per cui servono le figure di raccordo di cui sopra, in particolare per quegli ambienti in cui il Cloud è di là da venire (siamo sempre in Italia, non dimentichiamocelo) e che, comunque, il “prodotto a casa devono portarlo”.

In questo contesto, la figura principale che abbiamo identificato a suo tempo è quella del DevOps Officer, che vi ricordo essere colui che, più degli altri Devoppers, ha il compito di “fare i piani di scale” e far parlare tra loro gruppi abituati a spararsi a vicenda a palle incatenate.

Quello che finisce quasi tutte le giornate di lavoro con il fegato grosso e parecchie cicatrici, per capirci.

Ma visto che non stiamo parlando dell’Engineer o dell’Architect, che hanno una connotazione più tecnica e che vengono fortemente supportati dai tool Software che hanno a disposizione, oppure dell’Evangelist, che “vola alto” per definizione, la vera domanda è: “quali sono le conoscenze che dovrebbe avere un buon DevOps Officer per essere efficace?”

Oppure, per dirla in altri termini:

Esiste LA Certificazione DevOps?

Vi dico subito che non ho una risposta definitiva a questa domanda, perchè questo blog è nato anche con lo scopo di condividere il mio percorso di continua scoperta delle varie sfaccettature della nostra metodologia preferita e questo è un argomento che ancora non ho sviscerato completamente.

E quindi? Ci affidiamo “ciecamente” a quello che dice l’Institute o ci facciamo il nostro BoK?

Questa è una scelta che dovrete fare voi, dal canto mio io posso provare ad aiutarvi in due modi:

• approfondendo la mia conoscenza di quello che l’Institute offre, condividendovela man mano che ne so di più;
• segnalando quanto di “pertinente” (a mio parere) è presente nei BoK ufficiali delle varie certificazioni riconosciute e che possono essere parte di un ideale percorso di apprendimento che ogni DevOps Officer dovrebbe fare.

Quindi, concentrandosi sul secondo punto e usando la nostra solita metafora alcolica di come trovare gli ingredienti giusti per realizzare un buon DevOps blended whiskey, tendendo fermo come ingrediente base e collante del tutto la Cultura della Condivisione, proverò a raccontarvi cosa mi hanno insegnato/ricordato i BoK dei vari standard “per fare cose” che ho incontrato nel corso della mia carriera di Devopper, a partire da quelli in assoluto più note (e completi) nel loro campo di applicazione:

• PMP
• ITIL
• ISTQB

Stay tuned e alla prossima.