Alcuni anni fa, molte organizzazioni consideravano DevOps un esperimento promettente piuttosto che un approccio tradizionale allo sviluppo software. DevOps è ora un insieme collaudato e potente di pratiche e strumenti di sviluppo e distribuzione in grado di accelerare il rilascio di nuovi prodotti e aumentare la produttività. Ancora più importante, l’impatto di DevOps è sulla crescita complessiva del business e sull’aumento della redditività.
Squadra tradotto il più interessante da , compilato dagli esperti di DevOps Research & Assessment (DORA). Lo studio ha coinvolto 31 specialisti provenienti da tutto il mondo. Diamo un'occhiata a cosa è cambiato nel settore nel 000 e a come le aziende possono migliorare l'efficienza della distribuzione del software.
In che modo le dimensioni del settore e dell'azienda influiscono sullo stato di DevOps
Lo studio non ha rilevato alcuna correlazione tra le prestazioni DevOps e il settore di un'organizzazione, ad eccezione della vendita al dettaglio, che ha ottenuto risultati leggermente migliori. Ciò è dovuto in particolare al fatto che i rivenditori devono rispondere rapidamente alle fluttuazioni della domanda e alle esigenze dei clienti. Secondo lo studio, qualsiasi azienda può raggiungere un elevato livello di DevOps, compreso il settore finanziario e quello pubblico.
Le prestazioni DevOps nelle aziende con più di 5000 dipendenti sono state inferiori rispetto a quelle delle aziende con meno di 5000 dipendenti. Molto probabilmente, ciò è dovuto al fatto che le grandi organizzazioni hanno processi più ampi, controlli più severi e un’architettura dei sistemi IT più complessa, che introduce ritardi nel processo di sviluppo e implementazione del codice. Allo stesso tempo, gli esperti ritengono che le dimensioni dell’azienda non ostacolino il successo nella creazione di DevOps, ma in alcuni casi potrebbero solo richiedere uno sforzo maggiore.
Come valutare il livello di DevOps in un'azienda
Gli esperti hanno confrontato i processi DevOps con un benchmark, dividendo gli intervistati in quattro gruppi con performance migliori, buone, medie e scarse.
Per il report abbiamo preso in considerazione quattro parametri chiave per valutare l'efficacia di DevOps: tempo necessario per completare le modifiche nello sviluppo del software, frequenza di distribuzione, tasso di fallimento e tempo di ripristino.
Quattro livelli di DevOps: valuta dove si trova la tua azienda:
Una metrica per valutare l'efficacia della fornitura di software per i principali servizi e applicazioni dell'azienda
Squadre con i migliori record
Squadre con buone prestazioni
Squadre nella media
Squadre poco performanti
Frequenza di distribuzione
La frequenza con cui l'azienda distribuisce il codice in produzione o lo rilascia agli utenti finali.
Su richiesta, più implementazioni al giorno
Da una volta al giorno a una volta alla settimana
Da una volta alla settimana a una volta al mese
Una volta al mese/diversi mesi
Modificare il tempo di esecuzione
Quanto tempo ci vuole per passare da un test al software che funziona con successo in produzione?
Meno di un giorno
Da un giorno a una settimana
Da una settimana a un mese
Da un mese a sei mesi
Tempo di ripristino del servizio
Quanto tempo è necessario per ripristinare un servizio dopo un incidente o un bug che ha interessato gli utenti.
Meno di un'ora
Durante il giorno
In una settimana
Da una settimana a un mese
Cambia il tasso di fallimento
Quale percentuale di aggiornamenti o nuove versioni comportano un peggioramento del servizio e richiedono correzioni?
0-15%
0-15%
0-15%
46-60%
Lo studio ha rivelato la seguente tendenza: il numero di team ad alte prestazioni è quasi triplicato, passando dal 7% di tutti gli intervistati nel 2018 al 20% nel 2019.
Distribuzione dei team di sviluppo per livello di prestazione.
Rispetto ai team del gruppo a basse prestazioni, i team DevOps ad alte prestazioni:
- Eseguite 208 volte più distribuzioni di codice.
- Ho dedicato 106 volte meno tempo alla distribuzione del codice.
- Abbiamo riscontrato guasti 7 volte meno spesso.
- Il software è stato ripristinato 2,604 volte più velocemente dopo gli errori.
Inoltre, i team DevOps ad alte prestazioni hanno il doppio delle probabilità di raggiungere o superare i parametri di prestazione organizzativa rispetto ai team a basse prestazioni.
Molti esperti ritengono che sia impossibile ottenere un aumento di tutti gli indicatori contemporaneamente e che sia necessario raggiungere un compromesso. Pertanto, alcuni ritengono che l'aumento della velocità dei rilasci possa influire negativamente sull'affidabilità del processo di distribuzione del software e sulla fornitura di servizi. Tuttavia, la ricerca ha dimostrato che la velocità e la coerenza dei risultati non si escludono a vicenda.
Non vedo nulla di sorprendente nella crescita del numero dei team DevOps; è naturale: la filosofia DevOps è ormai popolare e il numero delle startup è in crescita.
Ma, a mio avviso, gli esperti hanno scelto parametri non del tutto corretti per valutare l'efficacia di DevOps.
Valutarlo in base alla velocità di implementazione del codice è a dir poco strano. Questo vale solo per le startup, dove il parametro chiave sarà la velocità di immissione del prodotto sul mercato, e spesso il prodotto viene lanciato nella sua forma grezza. In tali condizioni, i meccanismi che accelerano lo sviluppo e la consegna alla produzione sono vitali. Ma per i software consolidati, come quelli finanziari o medici, il parametro del tasso di fallimento potrebbe non esistere e i guasti potrebbero essere inaccettabili.
Lo stesso vale per il tempo di ripristino del servizio: per qualsiasi servizio sviluppato dovrebbe essere calcolato in secondi, ma per molti servizi il tempo di inattività è inaccettabile, a questo scopo sono state inventate tecnologie di seamless rollout (ad esempio verde/blu);
Inoltre, non dovresti concentrarti sul numero di distribuzioni di codice: dipende dalle necessità e dalle competenze del team di sviluppo. Se la distribuzione prevede l’aggiunta di nuove funzionalità, questa è una cosa, ma se comporta la correzione di errori commessi durante le distribuzioni precedenti, è qualcosa di completamente diverso.
Denis Romanenko, esperto freelance presso Mail.ru Cloud Solutions
Come migliorare i processi DevOps
Il report presenta due aree che contribuiranno a migliorare DevOps: aumentare l’efficienza dello sviluppo e della distribuzione del software e migliorare la produttività dei lavoratori.
Ciascuna delle aree include i propri componenti, migliorando i quali è possibile raggiungere l'obiettivo desiderato.
Secondo il rapporto, la chiave della trasformazione digitale è la cultura aziendale. I team DevOps ad alte prestazioni necessitano di una cultura di fiducia e sicurezza psicologica, un senso di prestazione e obiettivi chiari. Questo ambiente consente ai membri del team di prendere decisioni informate, esprimere le proprie opinioni ed essere più creativi.
Anche le tecnologie cloud, la distribuzione continua, i test di ripristino di emergenza e la gestione delle modifiche contribuiranno a migliorare l'efficienza dello sviluppo e della distribuzione del software. La produttività può essere aumentata investendo in strumenti facili da usare, riducendo il debito tecnico – ovvero riducendo la percentuale di codice inefficace e tecnologia obsoleta – organizzando la base di conoscenza aziendale e l’accesso a soluzioni esterne.
Penso che la metodologia e l'ideologia di DevOps risiedano proprio nel fatto che questi processi non dipendono da condizioni esterne, come il cloud o il proprio hardware. Il cloud stesso non è altro che uno strumento; in alcuni luoghi aiuterà, in altri ostacolerà o non sarà richiesto.
Denis Romanenko, esperto freelance presso Mail.ru Cloud Solutions
Di seguito esamineremo alcuni dei componenti per migliorare l'efficienza dei team DevOps.
Le tecnologie cloud consentono il successo di DevOps
Nel 2019, sempre più organizzazioni scelgono soluzioni cloud che aumentano significativamente la produttività dei team DevOps.
Quali infrastrutture utilizzano i team DevOps?
DORA ha scoperto che l'80% degli intervistati colloca . Tuttavia, solo il 29% degli intervistati ha implementato tutte e cinque le caratteristiche principali del cloud stabilite dal National Institute of Standards and Technology, lo standard più importante per valutare il valore del cloud all'interno di DevOps.
Caratterizzazione
Percentuale di utenti
Self-service su richiesta
I consumatori possono fornire automaticamente le risorse informatiche
secondo necessità, senza la partecipazione del fornitore.
57%
(+ 11% dal 2018)
Ampio accesso alla rete
Le funzionalità cloud sono disponibili attraverso diverse piattaforme,
come telefoni cellulari, tablet, laptop e workstation.
60%
(+ 14% dal 2018)
Pool di risorse
Le risorse del fornitore sono combinate in un modello multi-tenant, in cui le risorse fisiche e virtuali vengono assegnate dinamicamente su richiesta.
58%
(+ 15% dal 2018)
Scalabilità ed elasticità
Le risorse scalano orizzontalmente o verticalmente su richiesta, sono praticamente illimitate e possono essere emesse in qualsiasi quantità in qualsiasi momento.
58%
(+135 dal 2018)
trasparenza
I sistemi cloud monitorano, ottimizzano e segnalano automaticamente l'utilizzo delle risorse in base al tipo di servizio: archiviazione ed elaborazione dei dati, quantità di traffico,
account utente attivi.
62%
(+ 14% dal 2018)
Platform as a Service (PaaS) si sta spostando sempre più verso un modello di implementazione incentrato sui container. Le piattaforme cloud semplificano la distribuzione del software, quindi i team devono preoccuparsi solo di eseguire il codice dell'applicazione stessa. Anche il dimensionamento, la pianificazione delle risorse, l’amministrazione e la manutenzione dell’infrastruttura vengono trasferiti ai fornitori.
Per i fornitori di servizi cloud, la fornitura di una varietà di servizi sta diventando uno standard universale: reti di macchine virtuali, gestione di identità e accessi (IAM), archiviazione e database, apprendimento automatico, Internet of Things (IoT), soluzioni container, soluzioni di sicurezza e altri .
I clienti dei fornitori di servizi cloud pagano solo per le risorse che utilizzano, il che garantisce trasparenza dei costi, a differenza dei data center tradizionali dove è difficile o impossibile ottenere informazioni sui costi di sviluppo. Gli intervistati delle aziende che soddisfano le caratteristiche del cloud sopra elencate hanno 2,6 volte più probabilità di stimare accuratamente il costo di esecuzione del software, 2 volte più probabilità di capire quali applicazioni richiedono più risorse e 1,65 volte più probabilità di rimanere nei limiti del budget IT.
A volte risulta che assumere uno specialista competente e acquisire la capacità assegnata in un data center è più redditizio che pagare per il cloud. Quale opzione sia migliore dipende dal profilo e dalle dimensioni dell'azienda, dalla disponibilità del proprio personale di specialisti e competenze IT. Ad esempio, il cloud è comodo da utilizzare quando si avvia un'impresa o se l'azienda non dispone di un proprio reparto IT. In caso di scalabilità, potrebbe essere più conveniente mantenere tutta o parte dell'infrastruttura on-premise.
Denis Romanenko, esperto freelance presso Mail.ru Cloud Solutions
Pratiche tecniche DevOps
Molte organizzazioni che desiderano implementare DevOps sono alla ricerca di una serie di linee guida o best practice. Tuttavia, non esistono due aziende uguali, quindi le pratiche da scegliere dipendono dallo stato attuale dell’azienda e dai suoi obiettivi.
Detto questo, esistono aree generali che possono contribuire a migliorare le prestazioni DevOps: alcune sono sviluppate a livello di team, altre richiedono sforzi a livello organizzativo.
Quali aree di crescita sono evidenziate per i team DevOps nel 2019:
A livello di organizzazione
- architettura liberamente accoppiata
- implementazione dei cambiamenti
- supporto del codice
A livello di squadra
- integrazione continua
- testare l'automazione
- automazione della distribuzione
- monitoraggio
- pipeline di sviluppo
A livello di squadra e di organizzazione
- utilizzo dei servizi cloud
- test di ripristino di emergenza
Lo studio ha confermato l'impatto positivo dell'architettura liberamente accoppiata sulle prestazioni DevOps.
L'architettura ad accoppiamento flessibile è quella in cui i team possono testare, implementare e modificare i sistemi in modo indipendente su richiesta, indipendentemente da altri team, senza supporto, risorse, approvazione aggiuntivi e con meno feedback. Ciò consente di lavorare in modo più efficiente, ma richiede un elevato livello di organizzazione e gestione.
Questo approccio è possibile solo per le startup e con alcune riserve. La situazione potrebbe essere diversa in altre società. Un buon esempio: settore bancario/fintech. Lì potranno essere utilizzate soluzioni esclusivamente proprietarie, ma verranno applicate le pratiche DevOps.
Denis Romanenko, esperto freelance presso Mail.ru Cloud Solutions
I team DevOps di successo automatizzano tutto
consente di rilasciare servizi e applicazioni in produzione con costi e rischi inferiori, oltre a supportare i rilasci in conformità con gli obiettivi dell'organizzazione.
Un CI/CD di successo significa anche che i team possono implementare modifiche alla produzione su richiesta, avere un feedback immediato sulla qualità della distribuzione e agire rapidamente per migliorare il ciclo di distribuzione successivo.
Il report mostra che i team DevOps di successo investono in un’ampia gamma di processi, pratiche e strumenti di supporto:
- Il 92% utilizza strumenti di assemblaggio automatizzati;
- L'87% utilizza test unitari automatizzati;
- Il 57% estende l'automazione ai test di accettazione;
- Il 72% automatizza le distribuzioni negli ambienti di test, il 69% fa lo stesso per la distribuzione in produzione;
- Il 69% integra i chatbot nel processo di implementazione;
- Il 57% si integra con strumenti di monitoraggio.
È importante scegliere gli strumenti e le tecnologie giuste
Quando si costruiscono sistemi complessi e si gestiscono infrastrutture business-critical, è importante selezionare le tecnologie:
- facili da utilizzare sia per il primo collegamento che per l'uso continuativo;
- che ti aiutano a raggiungere i tuoi obiettivi.
Il rapporto ha esaminato gli strumenti utilizzati durante la distribuzione del software tramite CI/CD e strumenti di automazione dei test: queste sono le tecnologie alla base di DevOps.
Quali tecnologie utilizzano i team DevOps:
Tecnologia
Squadre poco performanti
Squadre nella media
Squadre con buone prestazioni
Squadre ad alte prestazioni
Una combinazione di prodotti proprietari, open source e commerciali
30%
34%
32%
33%
Principalmente soluzioni pacchettizzate open source e altamente personalizzate
17%
8%
7%
10%
Per lo più soluzioni open source e pacchettizzate con poca personalizzazione
14%
21%
18%
20%
Soluzioni commerciali prevalentemente boxate
8%
12%
8%
4%
Sviluppi interni e soluzioni proprietarie per l'azienda
20%
6%
5%
6%
Principalmente open source con forte personalizzazione
6%
7%
5%
12%
Principalmente open source con una piccola personalizzazione
5%
12%
24%
15%
L'usabilità degli strumenti ha un impatto significativo sulla capacità di un team di massimizzare il valore dello stack tecnologico scelto: gli ingegneri con tecnologie facili da usare hanno una probabilità 1,5 volte maggiore di appartenere a team ad alte prestazioni.
Secondo me, questa tabella dà la sensazione che per avere successo in un team DevOps sia necessario seguire la moda, non il problema tecnico.
Uno specialista competente sceglie gli strumenti per il compito e non viceversa. Esistono sempre diversi strumenti e approcci per risolvere qualsiasi problema. Uno strumento specifico è determinato da: le specificità del compito; quanto il personale ha familiarità con questo strumento (quanto è alta la soglia di accesso se lo strumento è nuovo); componente finanziaria, se presente.
Denis Romanenko, esperto freelance presso Mail.ru Cloud Solutions
Ripristino in caso di disastro
Ogni organizzazione il cui funzionamento dipende dal funzionamento del software deve averlo . Il rapporto mostra quali tipi di test di resilienza ai disastri utilizzano le diverse aziende.
Quali tipi di test utilizzano le aziende per il disaster recovery?
Tipo di prova
Squadre poco performanti
Squadre nella media
Squadre con buone prestazioni
Squadre ad alte prestazioni
La media
Test che non influenzano i sistemi reali
35%
26%
27%
30%
28%
Failover dell'infrastruttura (compresi i data center)
27%
43%
34%
38%
38%
Test di errore dell'applicazione
25%
46%
41%
49%
43%
Simulazione di incidenti che comportano l'interruzione dei sistemi di test
18%
22%
23%
29%
23%
Simulazione di incidenti che comportano l'interruzione dei sistemi di lavoro
18%
11%
12%
13%
12%
Creare automazione e sistemi che interrompono
sistemi di produzione su base regolare e continuativa
9%
8%
7%
9%
8%
Solo il 40% degli intervistati effettua annualmente test di disaster recovery utilizzando uno o più dei metodi elencati. Allo stesso tempo, le aziende che conducono test di disaster recovery hanno un livello più elevato di disponibilità del servizio. Il report mostra che i team DevOps ad alte prestazioni hanno 1.4 volte più probabilità di incorporare i dati dei test di disaster recovery nei processi di sviluppo e distribuzione del software.
È importante fornire ai team DevOps l'accesso alle informazioni
Trovare facilmente informazioni per risolvere i problemi può aiutare a mantenere produttivi i team DevOps. Ciò è particolarmente vero nell'ambiente tecnologico odierno, costituito da sistemi complessi.
Le fonti di tali informazioni possono essere divise in due gruppi:
- Fonti interne: documentazione aziendale sulla creazione e manutenzione del codice, basi di conoscenza aziendali, repository e altro ancora. I team DevOps che hanno utilizzato fonti di conoscenza interne sono stati 1,73 volte più produttivi.
- Fonti esterne: Motori di ricerca e completamento dello stack. I team DevOps in outsourcing sono stati 1,67 volte più produttivi. Le tecnologie esterne offrono un grande vantaggio per l’apprendimento e la crescita, in particolare l’uso di cloud pubblici e strumenti open source.
È importante che le aziende riducano il debito tecnico
Il debito tecnico include codice o sistemi con bug noti ma non risolti; copertura dei test insufficiente; codice o design di bassa qualità; artefatti che non vengono utilizzati ma non eliminati; implementazioni che il team non può supportare efficacemente; tecnologie obsolete; documentazione incompleta o obsoleta.
Gli esperti hanno scoperto che il debito tecnico ha un impatto negativo sulle prestazioni DevOps. Le squadre con un debito tecnico elevato erano 1,6 volte meno produttive. I team con prestazioni elevate avevano 1,4 volte più probabilità di avere un debito tecnico basso.
Principali risultati del sondaggio sullo stato di DevOps
- La percentuale di team DevOps con prestazioni elevate è quasi triplicata, raggiungendo il 20%. Ciò significa che le aziende comprendono la promessa di pratiche volte a migliorare lo sviluppo e la distribuzione del software e che le aziende stanno implementando più attivamente DevOps nei propri dipartimenti IT.
- La fornitura rapida di applicazioni e servizi è al centro della trasformazione tecnologica e organizzativa. La velocità e la coerenza dei rilasci aumentano i profitti e la soddisfazione del cliente.
- Le tecnologie cloud continuano a essere fondamentali per raggiungere l'eccellenza per i team DevOps. L'utilizzo del cloud consente di organizzare la consegna del software alla velocità richiesta, garantisce disponibilità, scalabilità e prestazioni dell'infrastruttura.
- L'efficacia dei team DevOps può essere migliorata prestando attenzione alla produttività dei membri del team, fornendo un'atmosfera psicologica confortevole e utilizzando strumenti convenienti.
- Aumentare la velocità di implementazione dei rilasci con il giusto approccio non influisce sulla stabilità dei servizi e delle applicazioni dell'azienda.
Fonte: habr.com
