Come in tutte le cose, per imbarcarsi correttamente nella DevOps transformation è necessario prepararsi adeguatamente, sia a livello aziendale che in relazione al singolo professionista coinvolto.

Prepararsi al cambiamento è ancora più difficile perché, come dimostrato scientificamente, le persone tendono inizialmente ad opporsi ad esso e l’unica cosa che può far sopravvivere il nostro esperimento, trasformandolo nel nuovo status-quo, è una forte motivazione d’insieme.

Come abbiamo visto, è difficile individuare una definizione univoca e condivisa di cos’è DevOps, ma è utile “spulciare” tra le risposte che spesso vengono date in merito nei vari eventi e nei vari blog/forum:

• DevOps … is a movement, a philosophy, a way of thinking;
• DevOps … is a person who can perform both Dev and Ops roles;
• DevOps … means cross skilling people;
• DevOps … is continuous delivery;
• DevOps … is a team of developers and operation staff;
• DevOps …is a culture movement;
• DevOps … is monitoring.

It’s DevOps!

Una definizione interessante, a cui faremo riferimento di seguito, è la seguente:

DevOps è un approccio culturale in cui Developers e Operations sperimentano continuamente nuovi modi di lavorare insieme con l’obiettivo di creare costantemente Valore per gli stakeholders. I processi rilevatisi efficaci vengono standardizzati attraverso la ripetitività e la pratica, ovvero le pratiche per raggiungerne la padronanza.

In funzione di questa definizione possiamo agganciarci a quanto descritto da Gene Kim ed evidenziare due punti focali:

1. Enfatizzare le performance dell’intero sistema, ovvero avere una visione olistica di quanto si sta realizzando;
2.  Creare più percorsi di feedback, per assicurarsi di essere sempre allineati rispetto agli obiettivi di qualità e di valore.

Nella pratica, quindi, come possiamo approcciare alla trasformazione DevOps? Ovviamente non esiste un modo univoco (diffidate sempre da chi vi propone soluzioni preconfezionate senza conoscere la vostra cultura aziendale attuale!), ma alcuni suggerimenti possono essere sicuramente utili per iniziare:

• Identificare l’executive sponsor interno e tutti gli stakeholders interni che giornalmente lavorano per promuovere l’adozione dell’approccio DevOps;
• È necessario aver maturata una chiara comprensione di quella che è la catena del valore aziendale (Value Chain) e come il Valore viene creato attraverso di essa (Value Stream);
• Vanno abbattuti i Silos che separano il team di development da quello di operation: l’obiettivo è ottenere un unico team integrato;
• In funzione della ristrutturazione in un unico team, è necessario rivedere le azioni incentivanti (es: bonus) che devono tener conto del risultato complessivo e non di quello parziale, altrimenti si ricade nella precedente suddivisione;
• Bisogna ricercare processi ripetibili e standardizzabili per tutte le attività chiave lungo la catena del valore (pre-requisite to mastery);
• Bisogna automatizzare quante più attività possibili: continuous integration, automated deployments e “infrastructure as code” sono un must;
• E’ fondamentale adottare degli opportuni sistemi di monitoraggio in grado di misurare le metriche fondamentali (key metrics). Nell’ultimo report annuale DevOps realizzato da Puppet Labs, emerge che le 4 metriche principalmente utilizzate sono: Change Frequency, Change Lead Time, Change Failure Rate e MTTR (Mean Time To Restore). A queste è sicuramente è utile aggiungere: Availability, Performance e MTBF (Mean Time Between Failures);
• Bisogna individuare un meccanismo di feedback ben definito al fine di operare in chiave di continuous improvement.

Siete pronti ad abbracciare un mondo fatto di esperimenti continui per migliorare le varie aree chiave della vostra catena del valore, abbinando ad essi la capacità di standardizzare i processi che si sono rilevati vincenti?