Close

Cos'è la cultura DevOps?

In che modo la cultura DevOps aiuta ad allineare persone, processi e strumenti verso un focus più unificato in direzione del cliente.

Foto di Tom Hall
Tom Hall

DevOps Advocate & Practitioner


Collaborazione

DevOps è un approccio Agile al cambiamento organizzativo che cerca di colmare i divari tradizionali e in silos tra i team e stabilire nuovi processi che facilitino una maggiore collaborazione. Sebbene DevOps sia reso possibile da nuovi strumenti e pratiche di progettazione Agile, questi non sono sufficienti per realizzare tutti i vantaggi offerti da questo approccio. Senza la mentalità, i rituali e la cultura appropriati, è difficile portare a compimento la promessa di DevOps.

Persone e cultura sono i fattori principali della riuscita dell'implementazione di DevOps.
- 2020 DevOps Trends Survey di Atlassian

Cos'è la cultura DevOps?


Nella sua essenza, la cultura DevOps implica collaborazione più stretta e responsabilità condivisa tra i team di sviluppo e delle operazioni per i prodotti che creano e gestiscono. In questo modo le aziende possono allineare persone, processi e strumenti verso un focus sul cliente più unificato.

Comporta inoltre l'educazione di team multidisciplinari che si assumono la responsabilità dell'intero ciclo di vita di un prodotto. I team DevOps lavorano in modo autonomo e adottano una cultura di progettazione del software, un flusso di lavoro e un set di strumenti che elevano i requisiti operativi allo stesso livello di importanza rivestito dall'architettura, dalla progettazione e dallo sviluppo. Gli sviluppatori che si occupano della compilazione del software si dedicano adesso anche alla sua esecuzione: ciò li avvicina all'utente, garantendo una comprensione maggiore dei suoi requisiti e delle sue esigenze. Poiché sono maggiormente coinvolti nel processo di sviluppo, i team delle operazioni possono aggiungere i requisiti di manutenzione e le esigenze dei clienti per creare un prodotto migliore.

Al centro della cultura DevOps ci sono trasparenza, comunicazione e collaborazione maggiori tra team che tradizionalmente lavoravano in silos. Tuttavia, affinché questi team collaborino a stretto contatto, devono prima verificarsi importanti cambiamenti culturali. DevOps è un cambiamento di cultura organizzativa che pone l'accento sull'apprendimento e sul miglioramento continui, soprattutto attraverso l'autonomia del team, feedback rapidi, profonda empatia e fiducia e collaborazione tra team.

Logo del pensiero consapevole
materiale correlato

Adotta una mentalità orientata al cliente

Logo di un trofeo
materiale correlato

Scopri di più sui vantaggi di DevOps

DevOps comporta responsabilità condivise. I membri del team di sviluppo e quelli del team delle operazioni sono allo stesso modo responsabili del successo o del fallimento di un prodotto. Le responsabilità degli sviluppatori devono andare oltre la semplice compilazione e il rilascio al team delle operazioni; devono condividere anche la responsabilità di supervisionare il prodotto durante l'intero ciclo di vita, adottando la mentalità "You Build It, You Run It". Testano e utilizzano il software e collaborano maggiormente con i team di controllo della qualità e delle operazioni IT. Se toccano con mano le difficoltà affrontate dal team delle operazioni, è più probabile che riescano a semplificare la distribuzione e la manutenzione. Allo stesso modo, se il team delle operazioni arriva a comprendere gli obiettivi aziendali del sistema, potrà collaborare con gli sviluppatori per aiutare a definire le esigenze operative di un sistema e adottare strumenti di automazione.

I team autonomi sono un altro aspetto importante di DevOps. Affinché collaborino in modo efficace, i team di sviluppo e quelli delle operazioni devono prendere decisioni e implementare le modifiche senza dover seguire processi di approvazione lunghi e complicati. Ciò implica dare fiducia ai team e creare un ambiente in cui non si teme il fallimento. Questi team devono disporre dei processi e degli strumenti giusti per prendere decisioni in modo più rapido e semplice, per ogni livello di rischio per il cliente .

Ad esempio, un tipico flusso di lavoro di sviluppo potrebbe richiedere il coinvolgimento di tanti collaboratori di team diversi per la distribuzione delle modifiche del codice. Lo sviluppatore apporta una modifica al codice e la invia a un repository di controllo del codice sorgente, il Build Engineer compila e distribuisce il codice in un ambiente di test, l'owner di prodotto aggiorna lo stato del lavoro in uno strumento di monitoraggio dei ticket e così via. Un team autonomo trarrà vantaggio dagli strumenti che automatizzano questi processi, in modo che l'invio di nuovo codice inneschi la compilazione e la distribuzione di una nuova funzione in un ambiente di test e lo strumento di monitoraggio dei ticket venga aggiornato automaticamente.

Ad esempio, un team è svantaggiato da requisiti che richiedono l'apertura di un ticket tramite un team delle operazioni separato per apportare modifiche banali all'infrastruttura, come l'aggiunta di una nuova voce DNS. Un task che dovrebbe richiedere pochi secondi finisce per essere portato a termine in giorni o settimane. Un team autonomo ha la capacità di implementare autonomamente tali modifiche, sia avvalendosi di un membro del team con le competenze e l'esperienza adeguate, sia potendo disporre di accesso a strumenti autogestiti.

Nella cultura del team DevOps i feedback rapidi sono preziosi perché contribuiscono al miglioramento continuo dei team di sviluppo e delle operazioni unificati. In un ambiente in cui i team di sviluppo e delle operazioni si trovano in silos isolati, il feedback sulle prestazioni e la stabilità del software applicativo nell'ambiente di produzione molto spesso impiega molto tempo per ritornare al team di sviluppo e non sempre ci arriva. Rendendo necessaria la collaborazione tra gli addetti alle operazioni per le attività di progettazione e implementazione delle strategie di monitoraggio delle applicazioni e di creazione di report, DevOps assicura che gli sviluppatori ricevano il feedback rapido di cui hanno bisogno per iterare e migliorare rapidamente il codice dell'applicazione. Ad esempio, qualsiasi strumento di continuous integration sufficientemente valido consente la compilazione e il test automatizzati di nuovi push di codice e fornisce agli sviluppatori feedback immediati sulla qualità del codice.

L'automazione è essenziale per la cultura DevOps, poiché rende possibile un'ottima collaborazione e consente di liberare le risorse. Grazie all'automazione e all'integrazione dei processi tra i team di sviluppo software e quelli IT, il software viene compilato, testato e rilasciato in modo più rapido e affidabile.

Quali sono i vantaggi della cultura DevOps?


Il vantaggio più evidente e di grande impatto che è possibile ottenere dall'adozione di una cultura DevOps è rappresentato dai rilasci di software semplificati, frequenti e di alta qualità, che aumentano non solo le prestazioni aziendali, ma anche la soddisfazione dei dipendenti.

Secondo il libro "Accelerate: Building and Scaling High Performing Technology Organizations", la cultura DevOps promuove alti livelli di fiducia e collaborazione e si traduce in processi decisionali di qualità superiore e livelli ancora più elevati di soddisfazione sul lavoro.

Adottare la cultura DevOps è fondamentale per costruire un'organizzazione di progettazione ad alte prestazioni senza sacrificare la soddisfazione dei dipendenti. È un vantaggio per tutti. Per un ingegnere non c'è niente di meglio della soddisfazione di effettuare rilasci frequenti e agevoli ed eseguire software stabile e ad alte prestazioni in grado di soddisfare gli utenti, mentre il miglioramento dei risultati aziendali è estremamente apprezzato dai dirigenti.

Quali sono le sfide?


L'adozione completa di una cultura DevOps di solito richiede che individui e team apportino modifiche significative al loro modo di lavorare, per questo motivo occorre prima ottenere il consenso dei vertici dell'organizzazione.

Il coinvolgimento dei dipendenti può essere, e spesso è, un punto di partenza importante per ottenere il consenso dei manager e dei dirigenti a intraprendere la trasformazione DevOps. Spesso l'argomento più convincente a favore di una più ampia adozione di DevOps è quando alcuni dipendenti o team di piccole dimensioni adottano tale approccio e iniziano a dimostrarne il successo.

Gli elevati livelli di autonomia e fiducia tipici della cultura DevOps possono essere difficili da coltivare se c'è una storia di conflitto tra i singoli dipendenti o i team coinvolti. Più i team erano in silos prima del tentativo di adozione dell'approccio DevOps, più difficile sarà costruire una connessione tra di loro.

Cambiare è difficile. Anche negli ambienti caratterizzati da grande armonia tra i dipendenti e i team esistenti, se i vantaggi del cambiamento non sono chiaramente articolati e compresi, può essere difficile promuovere l'accettazione e la volontà di mettere in pratica le nozioni teoriche.

Com'è comprensibile, le organizzazioni con una radicata mentalità di progettazione spesso passano immediatamente a strumenti e tecnologie per risolvere le sfide aziendali. Sì, esistono strumenti e tecnologie che possono aiutare l'organizzazione a passare all'approccio DevOps. Ma un cambiamento di strumenti e tecnologie che non comporta anche il cambiamento della cultura è spesso chiamato "DevOps cargo-cult" poiché cambia la facciata senza affrontare la debolezza nelle fondamenta.

Considerazioni per il passaggio alla cultura DevOps


Comunicazione aperta

Una delle sfide fondamentali che DevOps cerca di combattere è l'isolamento di conoscenze, esperienze e lavoro in diverse unità organizzative. Quando i programmatori che scrivono codice e gli amministratori di sistema che lo distribuiscono e lo gestiscono non comunicano, è probabile che si verifichino inefficienze.

La capacità di commettere errori

Molte organizzazioni, team e individui esercitano una pressione straordinaria su se stessi e sugli altri per non commettere mai errori. Se il fallimento non è un'opzione, è meno probabile che un individuo o un team tenti un nuovo approccio per risolvere un problema o sviluppare funzionalità innovative.

Questa mentalità si riflette nell'ossessione passata per la misurazione del "tempo medio fra i guasti" (MTBF) rispetto al "tempo medio di recupero" (MTTR). Per il criterio MTBF si utilizzano strumenti come l'"analisi delle cause principali" per identificare l'origine dei guasti e tentare di impedire che si ripetano. Il criterio MTTR riflette una visione delle applicazioni software come sistemi complessi soggetti a errori imprevedibili e si concentra sul ripristino rapido in caso di guasto.

Un'"analisi retrospettiva imparziale" è una caratteristica comune della cultura DevOps. I risultati possono essere migliorati se il team si riunisce alla fine di uno sprint o di un progetto per discutere di cosa è andato bene e cosa deve essere migliorato in un'atmosfera aperta e sicura.

Avere un punto di vista imparziale sul fallimento si rivela vincente in parte perché si adotta una mentalità orientata alla crescita, in cui si riconosce che gli errori possono capitare, ma si agisce basandosi sul presupposto che sia le persone che le organizzazioni sono in grado di apprendere, crescere e migliorare.
- "Effective DevOps" di Jennifer Davis e Katherine Daniels

Un nuovo insieme di processi

Per coltivare la cultura DevOps è necessario sviluppare nuovi approcci verso i vecchi problemi. DevOps comporta il cambiamento del processo in silos in cui i programmatori scrivono il codice dell'applicazione e lo passano al team delle operazioni che si occupa della sua distribuzione e gestione. L'approccio DevOps prevede la collaborazione tra il team di sviluppo e quello delle operazioni durante l'intero ciclo di vita di un progetto.

La continuous integration e la continuous delivery (CI/CD) sono aspetti comunemente ritenuti necessari per l'implementazione della cultura DevOps. Un terzo processo, la continuous deployment, è adottato e promosso da organizzazioni di grandi dimensioni come Netflix, ma non è comunemente adottato (o richiesto) nella maggior parte delle aziende più piccole. Ciò dipende dal fatto che la distribuzione continua di nuove funzioni nell'ambiente di produzione richiede un elevato livello di sicurezza sul fatto che il nuovo codice sia stato accuratamente testato e possa quindi essere distribuito in modo sicuro (ad es. tramite la tecnica di feature toggle). Pertanto, a meno che la propria organizzazione non esegua più distribuzioni al giorno, potrebbe non valere la pena investire nei processi che supportano questo approccio.

Nella maggior parte dei casi, l'esecuzione di alcune varianti di "sviluppo basato su trunk" semplificherà enormemente il lavoro di CI/CD. In questo modello, il team elimina i longevi branch di funzioni ed esegue frequenti commit sul branch del "trunk" del codice.

Una componente importante dello sviluppo basato su trunk sono i test automatizzati completi: unitari, di integrazione e di regressione. Ciò aiuta a garantire che tutti i nuovi commit sul branch del trunk siano stati accuratamente controllati al momento dell'invio al repository.

La continuous integration è un processo che prevede l'automatizzazione dell'integrazione delle modifiche al codice apportate da più collaboratori all'interno di un progetto software. Tale processo si estende oltre i team di sviluppo fino a raggiungere il resto dell'organizzazione. Ad esempio, i team di prodotto coordinano il momento del lancio in sequenza di funzioni e correzioni e stabiliscono quali membri del team saranno responsabili.

La continuous delivery è una metodologia organizzativa che riunisce team di progettazione e non, come quelli di design, prodotto e marketing, per il rilascio di un prodotto. Gli ambienti che non implementano la CD incoraggiano il comportamento di "passare oltre" in cui gli sviluppatori si concentrano sul team di controllo di qualità come esperienza utente principale. Ciò significa che il branch del "trunk" del repository è sempre nello stato "pronto per la distribuzione".

La continuous deployment consente di distribuire automaticamente nell'ambiente di produzione le modifiche del codice nel momento in cui vengono apportate, sia nascoste dietro un flag delle funzioni, che distribuite a una percentuale ridotta di clienti e/o facilmente ripristinate. Dal momento che possono reagire al feedback dei clienti e distribuire e convalidare rapidamente nuove funzioni, i team godono di maggiore flessibilità per rispondere alle mutazioni del mercato e alle richieste dei clienti. Possono anche ripristinare agevolmente le funzioni, in modo da non essere ostacolati dall'eventualità di introdurre errori nella build.

Il flag delle funzioni, il feature toggle o la dark deployment sono metodi comunemente implementati per assicurarsi che le nuove funzioni dell'applicazione non vengano visualizzate o non siano attive quando vengono distribuite nell'ambiente di produzione, ma che possano essere attivate con il minimo intervento. Questa strategia consente la continuous deployment poiché il rischio di impatto negativo sugli utenti è molto ridotto. È anche comune limitare le funzioni a un sottoinsieme della base utenti suddividendola per area geografica o eseguendo istanze server separate e rilasciando le funzioni su un solo server accessibile agli utenti.

Una toolchain aggiornata

La maggior parte dei team di sviluppo software utilizza almeno alcuni tipi di strumenti per il controllo delle versioni e il monitoraggio dei ticket e delle applicazioni. Tutti questi sono strumenti importanti per supportare una cultura DevOps, ma forse l'aggiunta più importante al set di strumenti tradizionali è il software per il supporto della CI/CD. Disporre di un flusso di lavoro automatizzato che richiede l'esecuzione di commit ed esegue test e distribuzioni è davvero l'unico modo per ottenere i feedback rapidi richiesti dalla cultura DevOps.

DevOps: un cambiamento culturale che produce risultati


Gli sviluppatori inseguono da decenni il sogno di distribuire software con maggior frequenza e meno fatica e bug. Ora, gli strumenti e le pratiche per renderlo realtà sono finalmente arrivati.

Dalle ricerche di Atlassian è emerso che le organizzazioni che praticano l'approccio DevOps rilasciano prodotti di qualità superiore (61%), con una maggiore frequenza di distribuzione e un time-to-market più rapido (49%). E non sono solo le organizzazioni a trarne vantaggio: i professionisti affermano di aver appreso nuove competenze (78%) e di aver ricevuto un aumento (48%).

Coltivare la cultura DevOps può essere difficile, ma ne vale la pena per ottenere vantaggi in termini di una maggiore soddisfazione di sviluppatori, manager e clienti.

Vuoi migliorare la tua cultura DevOps? Inizia con il Controllo salute del team di assistenza. Inoltre, esercitati a comunicare, collaborare e fare brainstorming con i colleghi applicando le 4 principali strategie per costruire una cultura DevOps.

Tom Hall
Tom Hall

Tom Hall è DevOps Advocate e Practitioner, lettore vorace e pianista dilettante.
Tra i traguardi degli ultimi 20 anni vanta certificazioni Novell, EMC, VMware e AWS. Dal 2016 aiuta a organizzare i DevOpsDays ad Atlanta e ad Austin, Texas.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Percorso di apprendimento DevOps

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up