Skip to content

Cosa significa DevOps? Come influenza i team?

DevOps è un movimento, un atteggiamento mentale, una modalità di organizzazione e un contesto di continuous learning.

Questa la definizione di Matthew Skelton: ci affidiamo a un suo articolo sulla Team Topology, la contestualizzazione dei gruppi di lavoro,  per approfondirne  il significato e le implicazioni nella sua applicazione.

DevOps, o dell’invisibilità

DevOps, dice Skelton, è un concetto che talvolta non è facile afferrare per chi deve decidere di adottarlo in una organizzazione, non dipendendo da pratiche prescritte di adozione.

Niente di più indicato, quindi, che portare come contributo alla scelta alcuni casi concreti.

Lo scopo dell’articolo è di indagare le relazioni tra il team, le motivazioni individuali e l’efficacia nella consegna del software, ovvero la topologia stessa del team e la sua operatività funzionale.

DevOps e Legge di Conway

Uno degli approcci d’analisi fornito da Skelton è la Legge di Conway, secondo la quale:

Le organizzazioni che producono sistemi […] sono limitate a produrre sistemi che sono copie delle strutture di comunicazione delle organizzazioni stesse.

Posto che una entità IT è un “sistema”, ne segue che, alla luce della Legge di Conway, la topologia di tale sistema sarà plasmata dai tipi di comunicazione utilizzati e incoraggiati. A chi sta studiando topologia dei sistemi in chiave DevOps appare evidente il riproporsi in molteplici casi della coerenza della Legge di Conway. Essa può essere un valido strumento DevOps quando si va a presentare una nuova organizzazione del team, contestuale e coerente con la struttura (il sistema, l’azienda) a cui inerisce e alle forme di comunicazione proprie della struttura stessa.

La molteplicità della cultura DevOps

La cultura DevOps per Skelton non esprime una singolarità. Diversi sistemi (ancora: diverse aziende) applicano con successo a sé stesse la cultura DevOps declinata in maniere diverse. Naturalmente il sostrato (la cultura) è la stessa, ma si differenziano le pratiche: “autopsie” (l’analisi del software) indolori; autonomia del team; rispetto tra colleghi; e, sempre, il desiderio e l’opportunità di migliorare continuativamente, tutti aspetti che corrispondono alla cultura DevOps.

Comunque, all’interno di una organizzazione, ci sono team che collaborano di più e team che collaborano meno, e il tipo e la finalità della comunicazione contestuale a un team può essere diversa a quelli di un altro team della stessa organizzazione: talvolta è necessario limitare la collaborazione tra team per mantenere le strutture logiche necessarie all’organizzazione stessa – una necessità definita “manovra inversa di Conway” e legata alla Legge di Conway stessa.

Alla luce di 20 case history analizzate, Skelton individua tre principali e più frequenti topologie di team:

  • Infrastruttura come servizio (Infrastructure as a service) – definita topologia di Tipo 3 da devopstopologies.com;
  • Responsabilità completamente condivisa (Fully-shared responsibility, Tipo 2);
  • SRE team (Site Reliability Engineering, Tipo 7).

Infrastruttura come servizio (Infrastructure as a service, Tipo 3)

DevOps - Topologia di team - Tipo 3

L’ambiente virtuale di contesto ha bisogno di essere utilizzato come servizio dai team di Sviluppo dell’Applicazione: in questo caso, come correttivo inerente alla Legge di Conway si applica una limitazione alla comunicazione tra i team di sviluppo (Dev) e i team di infrastrutture (infrastructure).

Il Tipo 3 si applica a sistemi con molteplici prodotti e servizi differenti, con una struttura Ops tradizionale, oppure operanti completamente su strutture Cloud pubbliche.

In casi come questi il team Dev è in qualche modo deliberatamente isolato da quello di infrastrutture: rispetto al codice e ai tool c’è più comunicazione nel team che tra i team. Ci sarà una condivisione di alcun metriche e una interazione limitata tra i provider di infrastrutture e team Dev, appunto come nel caso di Cloud pubbliche

Lo facciamo e lo gestiamo

Diversamente, in organizzazioni orientate alla produzione e con team orientati ai KPI (Key Performance Indicator), sviluppatori, infrastrutture e team dei tester lavorano in un ambiente di comunicazione molto più condivisa, compreso il fatto che a chiunque di ciascuno dei team può toccare di doversi svegliare alle due del mattino per risolvere un problema di un servizio…

Responsabilità completamente condivisa (Fully-shared responsibility, Tipo 2): organizzazioni incentrate su un singolo prodotto o servizio web

Fully-shared responsibility, Tipo 2

In questo caso i membri di team con diverse skills lavorano a stretto contatto, aiutandosi reciprocamente nei diversi aspetti di deliveryoperation. in questo caso la mentalità lo facciamo e lo gestiamo ha bisogno di indipendenza tra team che lavorano a sotto-sistemi diversi, tanto, probabilmente, da usare anche tool differenti. Tornando alla Legge di Conway, si configura l’ambiente di lavoro così che comunicazione e collaborazione tra team diversi siano ridotte al minimo.

SRE team (Site Reliability Engineering, Tipo 7)

SRE team (Site Reliability Engineering, Tipo 7)

Il terzo caso preso in considerazione riguarda i sistemi basati sulla Site Reliability Engineering (SRE) secondo il modello Google (talvolta definito WebOps). Il team SRE si carica di tutte le responsabilità (chiamata, intervento su un problema – incident response, …) fino a quando sono forniti criteri operativi assolutamente definiti per il software prodotto dal team Dev. Questo tipo di organizzazione è adatta per sistemi ad alto tasso di maturità e votati all’eccellenza operativa.

La collaborazione con il team di sviluppo è sostanzialmente limitata ad aiutarlo nel raggiungimento dei criteri operativi e nel fornire feedback sul comportamento tramite analisi metriche, report delle problematiche e così via. Il team Dev è deliberatamente escluso da alcuni degli aspetti dell’operatività in produzione del software, così che possa rimanere concentrato piuttosto su nuove feature, anche se questo ha bisogno di un alto livello di maturità da parte della proprietà per far sì che i criteri operativi vengano prioritizzati in maniera appropriata.

 


 

L’effetto della Team Topology sulla cultura DevOps

Una organizzazione applica DevOps con successo a partire dall’applicazione dei suoi fondamenti: rispetto, autonomia, non attribuire colpe. Da questa base si ottiene un rapporto tra i team tale da poterli indirizzare uniti verso un obiettivo comune. Comunque, dove una delle tre topologie presentate ha successo, la comune cultura DevOps sottintesa è declinata in maniera diversa. Ciò che funziona per una azienda di ecommerce potrebbe non funzionare per un’altra, date le differenze di skill, motivazioni, tecnologie e, persino, personalità!

Scegliere la Team Topology per confermare una cultura?

Ci sono sistemi, organizzazioni, affette da rivalità tra i team, obiettivi in conflitto, scarsa leadership e problematiche “politiche”. Tra queste, le organizzazioni più reattive cercano di adottare DevOps e Continuous Delivery per migliorare le loro performance, ma hanno più difficoltà ad applicare il cambiamento a causa dei conflitti inerenti ai team. Prendete un’organizzazione in cui il project manager ha un incentivo nella consegna di 20 Storie al mese, mentre il team Operation ha un incentivo per la soluzione di un ticket in un tempo predeterminato: non è sorprendente che nascano conflitti e comportamenti strani.

In casi come questi, a meno che al timone non subentri una leadership forte, ha senso adottare una Topologia di Team che si adatti il più possibile alla struttura esistente, cercando di adottare la migliore rispetto alla cultura corrente tra i team.

Per esempio, se il team Dev ha una forte cultura CapEx (Capital expenditure) e il team Ops una cultura OpEx (Operating expense), probabilmente la topologia più adatta è la Tipo 7: il suo “contratto di operatività” rappresenta un buon compromesso per mettere d’accordo i due approcci opposti.

D’altro canto, se un nuovo Head of Technology cerca un approccio completamente DevOps ma si rende conto che i team Dev da una parte e Ops dall’altra sono troppo lontani per competenze ed obiettivi per iniziare subito a collaborare, potrebbe creare un team DevOps temporaneo (12 – 18 mesi) per incoraggiare la cultura della collaborazione.

Tipo 5: Team DevOps temporaneo

Tipo 5: Team DevOps temporaneo

È il precursore di un Tipo 2 o Tipo 3, ma si deve far sì che non escluda le comunicazioni tra team Dev e team Ops esistenti.

In alcuni sistemi i Sysadmin di Ops sono riluttanti ad adottare pratiche essenziali quali controllo di versione, sviluppo test-firstinfrastructure code, così come in aziende in cui gli sviluppatori non coinvolti in monitoraggio e metriche non si interessano alle problematiche dell’operatività. In casi come questi per introdurre il DevOps è necessario un catalizzatore: un team interno o esterno.

Quale che sia la topologia scelta, l’approccio teso a prendere in considerazione la preesistente cultura di team del sistema bilancia realismo e volontà di cambiamento e miglioramento. La topologia di team porta il “profumo” di DevOps e, con esso, l’approccio a una cultura che si evolve di concerto con l’evolversi continuo di skill, tecnologie, capacità, business.

Immagine: Jadon Barns, unsplash.com

 

Published initaMondo DevOps