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.

Headshot of 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.

Mindful thinking logo
materiale correlato

Adotta una mentalità orientata al cliente

Trophy logo
materiale correlato

Scopri di più sui vantaggi di DevOps

DevOps entails shared responsibilities. Development and operations staff should both be responsible for the success or failure of a product. Developers are expected to do more than just build and hand off to operations — they are expected to share the responsibility of overseeing a product through the entire course of its lifetime, adopting a "you build it, you run it" mentality. They test and operate software and collaborate more with QA and IT Ops. When they understand the challenges faced by operations, they are more likely to simplify deployment and maintenance. Likewise, when operations understand the system’s business goals, they can work with developers to help define the operational needs of a system and adopt automation tools.

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.

What are the benefits of DevOps culture?


The most obvious and impactful benefit of embracing a DevOps culture is streamlined, frequent, and high-quality software releases. This not only increases company performance, but also employee satisfaction.

A DevOps culture fosters high levels of trust and collaboration, results in higher quality decision making, and even higher levels of job satisfaction, according to the book “Accelerate: Building and Scaling High Performing Technology Organizations.”

Embracing a DevOps culture is key to building a high-performing engineering organization without sacrificing employee contentment. It’s a win-win. For an engineer there is nothing like the feeling of frequently and easily deploying and running stable, high-performing software that makes its users happy, and for executives the improved business outcomes are a hit.

What are the challenges?


Fully embracing a DevOps culture usually requires individuals and teams to make significant changes to how they work, and therefore requires buy-in at the highest levels of the organization.

A grassroots effort can be, and often is, an important starting point for getting management and executive-level buy-in for a DevOps transformation. Often the most compelling argument in favor of broader DevOps adoption is when a few individuals or small teams adopt a DevOps approach and begin demonstrating success.

The high levels of autonomy and trust that are typical in a DevOps culture can be difficult to cultivate if there is a history of conflict between any of the individuals or teams involved. The more siloed the teams were before attempting to adopt a DevOps approach, the harder it will be to build connections.

Change is hard. Even in environments where there is a high level of harmony between the existing individuals and teams, if the benefits of change aren't clearly articulated and understood, it can be difficult to drive acceptance and willingness to put in the work.

Understandably, organizations with a strong engineering mindset often jump immediately to tools and technologies to solve business challenges. Yes, there are tools and technologies that can help your organization transition to a DevOps approach. But changing tools and technologies without changing the culture is often called “cargo-cult DevOps” since it changes the facade without addressing the weakness in the foundation.

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 - a cultural shift that yields results


Developers have been chasing the dream of delivering software more frequently, with less effort, and fewer bugs for decades. Now, the tools and practices to make this a reality are finally here.

Atlassian found that organizations practicing DevOps say they ship higher quality deliverables (61%), with increased deployment frequency and faster time to market (49%). And it’s not just organizations who reap the benefits, practitioners say they’ve learned new skills (78%) and received a raise (48%).

Cultivating a DevOps culture can be challenging, but the rewards in increased satisfaction for developers, managers, and customers alike are worth it.

Are you looking to improve your DevOps culture? Start with the Service Team Health Monitor. Also, practice communicating, collaborating, and brainstorming with colleagues with the Top 4 Plays for Building a DevOps Culture.

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

Workshop di simulazione

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up