Stato di DevOps in Russia 2020

Come capire lo stato di qualcosa?

Puoi fare affidamento sulla tua opinione, formata da varie fonti di informazione, ad esempio pubblicazioni su siti Web o esperienza. Puoi chiedere a colleghi, conoscenti. Un'altra opzione è quella di esaminare i temi delle conferenze: i comitati del programma sono rappresentanti attivi del settore, quindi ci fidiamo di loro nella scelta di argomenti pertinenti. Un'area separata è la ricerca e i rapporti. Ma c'è un problema. La ricerca sullo stato di DevOps viene condotta ogni anno nel mondo, i rapporti vengono pubblicati da società straniere e non ci sono quasi informazioni sui DevOps russi.

Ma è arrivato il giorno in cui è stato condotto uno studio del genere e oggi parleremo dei risultati. Lo stato del DevOps in Russia è stato studiato congiuntamente dalle aziende"espresso 42"E"Ontico". Express 42 aiuta le aziende tecnologiche a implementare e sviluppare pratiche e strumenti DevOps ed è stata una delle prime a parlare di DevOps in Russia. Gli autori dello studio, Igor Kurochkin e Vitaly Khabarov, sono impegnati nell'analisi e nella consulenza presso Express 42, pur avendo un background tecnico derivante dal funzionamento e dall'esperienza in diverse aziende. Per 8 anni i colleghi hanno guardato decine di aziende e progetti - dalle startup alle imprese - con problematiche diverse, oltre che maturità culturali e ingegneristiche diverse.

Nel loro rapporto, Igor e Vitaly hanno spiegato quali problemi c'erano nel processo di ricerca, come li hanno risolti, nonché come viene condotta in linea di principio la ricerca DevOps e perché Express 42 ha deciso di condurre la propria. Il loro rapporto può essere visualizzato qui.

Ricerca DevOps

La conversazione è stata avviata da Igor Kurochkin.

Chiediamo regolarmente al pubblico alle conferenze DevOps: "Hai letto il rapporto sullo stato di DevOps per quest'anno?" Pochi alzano la mano e il nostro studio ha dimostrato che solo un terzo li studia. Se non hai mai visto rapporti del genere, diciamo subito che sono tutti molto simili. Molto spesso ci sono frasi come: "Rispetto all'anno scorso ..."

Qui abbiamo il primo problema, seguito da altri due:

1. Non abbiamo dati per l'anno scorso. Lo stato di DevOps in Russia non interessa a nessuno;
2. Metodologia. Non è chiaro come testare ipotesi, come costruire domande, come analizzare, confrontare risultati, trovare connessioni;
3. Terminologia. Tutti i report sono in inglese, è necessaria la traduzione, non è stato ancora inventato un framework DevOps comune e ognuno ne crea uno proprio.

Diamo un'occhiata a come sono state eseguite le analisi di stato DevOps in tutto il mondo.

storia

La ricerca DevOps è stata condotta dal 2011. Puppet, uno sviluppatore di sistemi di gestione della configurazione, è stato il primo a eseguirli. A quel tempo, era uno dei principali strumenti per descrivere l'infrastruttura sotto forma di codice. Fino al 2013, questi studi erano semplicemente sondaggi chiusi e nessun rapporto pubblico.

Nel 2013 è apparso IT Revolution, l'editore di tutti i principali libri su DevOps. Insieme a Puppet, hanno preparato la prima pubblicazione State of DevOps, in cui sono apparse per la prima volta 4 metriche chiave. L'anno successivo, ThoughtWorks, una società di consulenza nota per i suoi regolari radar tecnologici su pratiche e strumenti del settore, è stata coinvolta. E nel 2015 è stata aggiunta una sezione con la metodologia ed è diventato chiaro come eseguono l'analisi.

Nel 2016 gli autori dello studio, dopo aver creato la propria azienda DORA (DevOps Research and Assessment), hanno pubblicato un rapporto annuale. L'anno successivo, DORA e Puppet pubblicarono il loro ultimo rapporto congiunto.

E poi è iniziato qualcosa di interessante:

Nel 2018 le società si sono divise e sono stati pubblicati due report indipendenti: uno di Puppet, il secondo di DORA insieme a Google. DORA ha continuato a sfruttare la sua metodologia con metriche chiave, profili prestazionali e pratiche ingegneristiche che hanno un impatto sulle metriche chiave e sulle prestazioni a livello aziendale. E Puppet ha offerto il proprio approccio con una descrizione del processo e dell'evoluzione di DevOps. Ma la storia non ha messo radici, nel 2019 Puppet ha abbandonato questa metodologia e ha rilasciato una nuova versione dei report, che elencava le pratiche chiave e come influenzano DevOps dal loro punto di vista. Poi è successo un altro evento: Google ha acquistato DORA e insieme hanno pubblicato un altro rapporto. Potresti averlo visto.

Quest'anno le cose si sono complicate. È noto che Puppet ha lanciato il proprio sondaggio. Lo hanno fatto una settimana prima di noi ed è già finito. Vi abbiamo preso parte e abbiamo esaminato a quali argomenti sono interessati. Ora Puppet sta facendo la sua analisi e si prepara a pubblicare il rapporto.

Ma non c'è ancora nessun annuncio da parte di DORA e Google. A maggio, quando di solito iniziava il sondaggio, è arrivata la notizia che Nicole Forsgren, una delle fondatrici di DORA, si era trasferita in un'altra azienda. Pertanto, abbiamo ipotizzato che quest'anno non ci sarebbero state ricerche e rapporti da parte di DORA.

Come vanno le cose in Russia?

Non abbiamo svolto ricerche DevOps. Abbiamo parlato alle conferenze, raccontando le scoperte di altre persone e Raiffeisenbank ha tradotto "State of DevOps" per il 2019 (puoi trovare il loro annuncio su Habré), molte grazie a loro. Ed è tutto.

Pertanto, abbiamo condotto la nostra ricerca in Russia utilizzando metodologie e risultati DORA. Abbiamo utilizzato il rapporto dei colleghi della Raiffeisenbank per la nostra ricerca, anche per la sincronizzazione della terminologia e della traduzione. E le domande rilevanti per il settore sono state tratte dai rapporti DORA e dal questionario Puppet di quest'anno.

Processo di ricerca

La relazione è solo la parte finale. L'intero processo di ricerca si compone di quattro fasi principali:

Durante la fase di preparazione, abbiamo intervistato esperti del settore e preparato un elenco di ipotesi. Sulla base di queste sono state compilate le domande ed è stato lanciato un sondaggio per tutto il mese di agosto. Quindi abbiamo analizzato e preparato il rapporto stesso. Per DORA, questo processo richiede 6 mesi. Ci siamo incontrati nel giro di 3 mesi e ora capiamo di aver avuto a malapena abbastanza tempo: solo eseguendo l'analisi capisci quali domande devi porre.

Partecipanti

Tutti i rapporti esteri iniziano con un ritratto dei partecipanti e la maggior parte di loro non proviene dalla Russia. La percentuale di intervistati russi oscilla tra il 5 e l'1% di anno in anno e questo non consente di trarre conclusioni.

Mappa dal rapporto Accelerate State of DevOps 2019:

Nel nostro studio, siamo riusciti a intervistare 889 persone - questo è parecchio (DORA interroga circa un migliaio di persone all'anno nei suoi rapporti) e qui abbiamo raggiunto l'obiettivo:

È vero, non tutti i nostri partecipanti hanno raggiunto la fine: la percentuale di completamento si è rivelata leggermente inferiore alla metà. Ma anche questo è stato sufficiente per ottenere un campione rappresentativo e condurre un'analisi. DORA non rivela le percentuali di riempimento nei suoi rapporti, quindi non c'è confronto qui.

Settori e posizioni

I nostri intervistati rappresentano una dozzina di industrie. La metà lavora nella tecnologia dell'informazione. Seguono i servizi finanziari, il commercio, le telecomunicazioni e altri. Tra le posizioni ci sono specialisti (sviluppatore, tester, ingegnere operativo) e personale dirigente (capi di team, gruppi, aree, direttori):

Uno su due lavora per un'azienda di medie dimensioni. Una persona su tre lavora in grandi aziende. La maggior parte lavora in team fino a 9 persone. Separatamente, abbiamo chiesto informazioni sulle attività principali e la maggior parte è in qualche modo correlata all'operazione e circa il 40% è impegnato nello sviluppo:

Quindi abbiamo raccolto informazioni per il confronto e l'analisi di rappresentanti di diversi settori, aziende, team. Il mio collega Vitaly Khabarov parlerà dell'analisi.

Analisi e confronto

Vitaly Khabarov: Mille grazie a tutti i partecipanti che hanno completato il nostro sondaggio, compilato questionari e fornito dati per ulteriori analisi e test delle nostre ipotesi. E grazie ai nostri clienti e clienti, abbiamo una vasta esperienza che ha aiutato a identificare le preoccupazioni del settore e formulare le ipotesi che abbiamo testato nella nostra ricerca.

Sfortunatamente, non puoi semplicemente prendere un elenco di domande da un lato e dati dall'altro, confrontarli in qualche modo, dire: "Sì, funziona tutto così, avevamo ragione" e disperderci. No, sono necessari metodologia e metodi statistici per essere sicuri che non ci sbagliamo e che le nostre conclusioni siano affidabili. Quindi possiamo costruire il nostro ulteriore lavoro sulla base di questi dati:

Chiave metrica

Abbiamo preso come base la metodologia DORA, che hanno descritto in dettaglio nel libro "Accelerate State of DevOps". Abbiamo verificato se le metriche chiave sono adatte al mercato russo, se possono essere utilizzate nello stesso modo in cui DORA utilizza per rispondere alla domanda: "In che modo l'industria in Russia corrisponde all'industria straniera?"

Chiave metrica:

1. Frequenza di distribuzione. Con quale frequenza viene distribuita una nuova versione dell'applicazione nell'ambiente di produzione (modifiche pianificate, esclusi hotfix e risposta agli incidenti)?
2. Tempi di consegna. Qual è il tempo medio tra il commit di una modifica (scrittura della funzionalità come codice) e la distribuzione della modifica nell'ambiente di produzione?
3. I tempi di recupero. Quanto tempo è necessario in media per ripristinare un'applicazione in un ambiente di produzione dopo un incidente, un degrado del servizio o la scoperta di un bug che interessa gli utenti dell'applicazione?
4. Modifiche fallite. Qual è la percentuale di distribuzioni nell'ambiente di produzione che porta al degrado dell'applicazione o a incidenti e richiede la correzione (rollback delle modifiche, sviluppo di un aggiornamento rapido o di una patch)?

DORA nella sua ricerca ha trovato una connessione tra queste metriche e le performance organizzative. Lo testiamo anche nel nostro studio.

Ma per assicurarti che le quattro metriche chiave possano influenzare qualcosa, devi capire: sono in qualche modo correlate tra loro? DORA ha risposto affermativamente con un avvertimento: la relazione tra modifiche non riuscite (Change Failure Rate) e altre tre metriche è leggermente più debole. Abbiamo più o meno la stessa immagine. Se il tempo di consegna, la frequenza di distribuzione e il tempo di ripristino sono correlati tra loro (abbiamo stabilito questa correlazione tramite la correlazione di Pearson e tramite la scala Chaddock), allora non esiste una correlazione così forte con le modifiche non riuscite.

In linea di principio, la maggior parte degli intervistati tende a rispondere di avere un numero piuttosto ridotto di incidenti in produzione. Sebbene vedremo in seguito che esiste ancora una differenza significativa tra i gruppi di intervistati in termini di modifiche non riuscite, non possiamo ancora utilizzare questa metrica per questa divisione.

Attribuiamo questo al fatto che (come è emerso durante l'analisi e la comunicazione con alcuni dei nostri clienti) c'è una leggera differenza nella percezione di ciò che è considerato un incidente. Se siamo riusciti a ripristinare le prestazioni del nostro servizio durante la finestra tecnica, questo può essere considerato un incidente? Probabilmente no, perché abbiamo sistemato tutto, siamo bravissimi. Possiamo considerarlo un incidente se dovessimo rilanciare la nostra applicazione 10 volte in una modalità normale e familiare per noi? Sembra di no. Pertanto, la questione della relazione delle modifiche non riuscite con altre metriche rimane aperta. Lo perfezioneremo ulteriormente.

Importante qui è che abbiamo trovato una correlazione significativa tra tempi di consegna, tempi di ripristino e frequenza di distribuzione. Pertanto, abbiamo preso queste tre metriche per suddividere ulteriormente gli intervistati in gruppi di prestazioni.

Quanto pendere in grammi?

Abbiamo utilizzato l'analisi dei cluster gerarchici:

• Distribuiamo gli intervistati su uno spazio n-dimensionale, dove le coordinate di ciascun intervistato sono le loro risposte alle domande.
• Ogni intervistato è dichiarato un piccolo cluster.
• Combiniamo i due cluster più vicini l'uno all'altro in un cluster più grande.
• Troviamo la prossima coppia di cluster e li combiniamo in un cluster più grande.

Questo è il modo in cui raggruppiamo tutti i nostri intervistati nel numero di cluster di cui abbiamo bisogno. Con l'aiuto di un dendrogramma (un albero di connessioni tra cluster), vediamo la distanza tra due cluster vicini. Non resta che stabilire un certo limite di distanza tra questi ammassi e dire: "Questi due gruppi sono abbastanza distinguibili l'uno dall'altro perché la distanza tra loro è gigantesca".

Ma qui c'è un problema nascosto: non abbiamo restrizioni sul numero di cluster: possiamo ottenere 2, 3, 4, 10 cluster. E la prima idea è stata: perché non dividere tutti i nostri intervistati in 4 gruppi, come fa DORA. Ma abbiamo scoperto che le differenze tra questi gruppi diventano insignificanti e non possiamo essere sicuri che l'intervistato appartenga davvero al suo gruppo e non a quello vicino. Non possiamo ancora dividere il mercato russo in quattro gruppi. Pertanto, abbiamo optato per tre profili tra i quali esiste una differenza statisticamente significativa:

Successivamente, abbiamo determinato il profilo per cluster: abbiamo preso la mediana per ciascuna metrica per ciascun gruppo e compilato una tabella dei profili delle prestazioni. In effetti, abbiamo ottenuto i profili delle prestazioni del partecipante medio in ciascun gruppo. Abbiamo individuato tre profili di efficienza: Basso, Medio, Alto:

Qui abbiamo confermato la nostra ipotesi secondo cui 4 metriche chiave sono adatte per determinare il profilo delle prestazioni e funzionano sia nel mercato occidentale che in quello russo. C'è una differenza tra i gruppi ed è statisticamente significativa. Sottolineo che c'è una differenza significativa tra i profili di performance in termini di metrica delle modifiche non riuscite in termini di media, anche se inizialmente non abbiamo diviso gli intervistati per questo parametro.

Quindi sorge la domanda: come utilizzare tutto questo?

Come usare

Se prendiamo una squadra qualsiasi, 4 metriche chiave e le applichiamo al tavolo, nell'85% dei casi non otterremo una corrispondenza completa: questo è solo un partecipante medio e non ciò che è nella realtà. Siamo tutti (e ogni squadra) leggermente diversi.

Abbiamo verificato: abbiamo preso i nostri intervistati e il profilo delle prestazioni DORA e abbiamo esaminato quanti intervistati si adattano a questo o quel profilo. Abbiamo scoperto che solo il 16% degli intervistati rientrava sicuramente in uno dei profili. Tutto il resto è sparso da qualche parte nel mezzo:

Ciò significa che il profilo di efficienza ha una portata limitata. Per capire dove ti trovi in ​​prima approssimazione, puoi usare questa tabella: “Oh, sembra che siamo più vicini a Medio o Alto!” Se capisci dove andare dopo, questo potrebbe essere sufficiente. Ma se il tuo obiettivo è un miglioramento costante e continuo e vuoi sapere più esattamente dove sviluppare e cosa fare, allora sono necessari fondi aggiuntivi. Li abbiamo chiamati calcolatrici:

• Calcolatrice DORA
• Calcolatrice Express 42* (in fase di sviluppo)
• Sviluppo proprio (puoi creare la tua calcolatrice interna).

A cosa servono? Capire:

• Il team all'interno della nostra organizzazione è all'altezza dei nostri standard?
• In caso contrario, possiamo aiutarlo, accelerarlo nell'ambito delle competenze di cui dispone la nostra azienda?
• Se è così, possiamo fare ancora meglio?

Puoi anche usarli per raccogliere statistiche all'interno dell'azienda:

• Che squadre abbiamo?
• Dividi i team in profili;
• Vedi: Oh, questi comandi sono poco performanti (non tirano fuori un po '), ma sono fantastici: vengono distribuiti ogni giorno, senza errori, hanno un tempo di consegna inferiore a un'ora.

E poi puoi scoprire che all'interno della nostra azienda ci sono le competenze e gli strumenti necessari per quei team che non sono ancora all'altezza.

Oppure, se capisci che ti senti benissimo all'interno dell'azienda, sei migliore di molti, allora puoi sembrare un po 'più ampio. Questa è solo l'industria russa: possiamo ottenere le competenze necessarie nell'industria russa per accelerare noi stessi? La calcolatrice Express 42 aiuterà qui (è in fase di sviluppo). Se hai superato il mercato russo, allora guarda Calcolatrice DORA e al mercato mondiale.

Bene. E se sei nel gruppo Elit sulla calcolatrice DORA, cosa dovresti fare? Non c'è una buona soluzione qui. Molto probabilmente sei in prima linea nel settore e un'ulteriore accelerazione e affidabilità è possibile grazie alla ricerca e sviluppo interna e all'utilizzo di maggiori risorse.

Passiamo al confronto più dolce.

Confronto

Inizialmente volevamo confrontare l'industria russa con l'industria occidentale. Se confrontiamo direttamente, vediamo che abbiamo meno profili, e sono un po' più mescolati tra loro, i bordi sono un po' più sfumati:

I nostri artisti d'élite sono nascosti tra gli artisti di alto livello, ma sono lì: questi sono gli unicorni d'élite che hanno raggiunto altezze significative. In Russia, la differenza tra il profilo Elite e il profilo High non è ancora abbastanza significativa. Pensiamo che in futuro questa separazione avverrà a causa di un aumento della cultura ingegneristica, della qualità dell'implementazione delle pratiche ingegneristiche e delle competenze all'interno delle aziende.

Se passiamo a un confronto diretto all'interno dell'industria russa, possiamo vedere che i team di alto profilo sono migliori sotto tutti gli aspetti. Abbiamo anche confermato la nostra ipotesi che esista una relazione tra queste metriche e le prestazioni organizzative: i team di alto profilo hanno molte più probabilità non solo di raggiungere gli obiettivi, ma anche di superarli.
Diventiamo squadre di alto profilo e non fermiamoci qui:

Ma quest'anno è speciale e abbiamo deciso di verificare come stanno andando le aziende in una pandemia: i team di alto profilo stanno facendo molto meglio e si sentono meglio della media del settore:

• 1,5-2 volte più probabilità di rilasciare nuovi prodotti,
• 2 volte più probabilità di migliorare l'affidabilità e/o le prestazioni dell'infrastruttura applicativa.

Cioè, le competenze che già avevano li hanno aiutati a svilupparsi più velocemente, lanciare nuovi prodotti, modificare prodotti esistenti, conquistando così nuovi mercati e nuovi utenti:

Cos'altro ha aiutato i nostri team?

Pratiche ingegneristiche

Vi parlerò dei risultati significativi per ogni pratica che abbiamo testato. Forse qualcos'altro ha aiutato i team, ma stiamo parlando di DevOps. E all'interno di DevOps, vediamo una differenza tra team di profili diversi.

Piattaforma come servizio

Non abbiamo trovato una relazione significativa tra l'età della piattaforma e il profilo del team: le piattaforme sono apparse all'incirca nello stesso periodo sia per i Low-team che per i High-team. Ma per quest'ultimo, la piattaforma fornisce, in media, più servizi e più interfacce di programmazione per il controllo attraverso il codice del programma. E i team della piattaforma hanno maggiori probabilità di aiutare i propri sviluppatori e team a utilizzare la piattaforma, a risolvere più spesso i loro problemi e gli incidenti relativi alla piattaforma e ad istruire altri team.

Infrastruttura come codice

Tutto è piuttosto standard qui. Abbiamo trovato una relazione tra l'automazione del lavoro del codice dell'infrastruttura e la quantità di informazioni memorizzate all'interno del repository dell'infrastruttura. I comandi di alto profilo memorizzano più informazioni nei repository: questa è la configurazione dell'infrastruttura, la pipeline CI / CD, le impostazioni dell'ambiente e i parametri di build. Memorizzano queste informazioni più spesso, lavorano meglio con il codice dell'infrastruttura e automatizzano più processi e attività per lavorare con il codice dell'infrastruttura.

È interessante notare che non abbiamo riscontrato differenze significative nei test dell'infrastruttura. Attribuisco questo al fatto che i team di alto profilo hanno più automazione dei test in generale. Forse non dovrebbero essere distratti separatamente dai test dell'infrastruttura, ma piuttosto da quei test con cui controllano le applicazioni, e grazie a loro vedono già cosa e dove hanno rotto.

Integrazione e consegna

La sezione più noiosa, perché abbiamo confermato che più automazione hai, meglio lavori con il codice, più è probabile che tu ottenga risultati migliori.

Architettura

Volevamo vedere in che modo i microservizi influiscono sulle prestazioni. In realtà no, poiché l'utilizzo dei microservizi non è associato a un aumento degli indicatori di performance. I microservizi vengono usati sia per i comandi di alto profilo che per i comandi di basso profilo.

Ma ciò che è significativo è che per High-team, la transizione a un'architettura di microservizi consente loro di sviluppare e implementare i propri servizi in modo indipendente. Se l'architettura consente agli sviluppatori di agire autonomamente, senza attendere qualcuno esterno al team, allora questa è una competenza chiave per aumentare la velocità. In questo caso, i microservizi aiutano. E solo la loro implementazione non gioca un ruolo importante.

Come abbiamo scoperto tutto questo?

Avevamo un piano ambizioso per replicare completamente la metodologia DORA, ma non avevamo le risorse. Se DORA utilizza molte sponsorizzazioni e la loro ricerca richiede sei mesi, noi abbiamo svolto le nostre ricerche in breve tempo. Volevamo creare un modello DevOps come fa DORA e lo faremo in futuro. Finora ci siamo limitati alle mappe di calore:

Abbiamo esaminato la distribuzione delle pratiche ingegneristiche tra i team in ciascun profilo e abbiamo scoperto che i team di alto profilo, in media, erano più propensi a utilizzare pratiche ingegneristiche. Puoi leggere di più su tutto questo nel nostro relazione.

Tanto per cambiare, passiamo dalle statistiche complesse a quelle semplici.

Cos'altro abbiamo scoperto?

Strumenti

Osserviamo che la maggior parte dei comandi sono utilizzati dal sistema operativo della famiglia Linux. Ma Windows è ancora di tendenza: almeno un quarto dei nostri intervistati ha notato l'uso dell'una o dell'altra delle sue versioni. Sembra che il mercato abbia questa esigenza. Pertanto, puoi sviluppare queste competenze e fare presentazioni alle conferenze.

Tra gli orchestratori, non è un segreto per nessuno, Kubernetes è in testa (52%). Il prossimo orchestratore in linea è Docker Swarm (circa il 12%). I sistemi CI più popolari sono Jenkins e GitLab. Il sistema di gestione della configurazione più popolare è Ansible, seguito dalla nostra amata Shell.

Amazon è attualmente il principale provider di cloud hosting. La quota di nuvole russe sta gradualmente aumentando. Il prossimo anno sarà interessante vedere come si sentiranno i fornitori di servizi cloud russi, se la loro quota di mercato aumenterà. Lo sono, possono essere usati e va bene:

Passo la parola a Igor, che fornirà qualche statistica in più.

Diffusione delle pratiche

Igor Kurochkin: Separatamente, abbiamo chiesto agli intervistati di indicare come le pratiche ingegneristiche considerate sono distribuite nell'azienda. Nella maggior parte delle aziende esiste un approccio misto, costituito da un diverso insieme di modelli, e i progetti pilota sono molto popolari. Abbiamo anche visto una leggera differenza tra i profili. I rappresentanti di alto profilo usano più spesso il modello "Iniziativa dal basso", quando piccoli team di specialisti cambiano processi di lavoro, strumenti e condividono pratiche di successo con altri team. In Medium si tratta di un'iniziativa dall'alto che interessa l'intera azienda attraverso la creazione di comunità e centri di eccellenza:

Agile e DevOps

La questione della connessione tra Agile e DevOps è spesso discussa nel settore. Questo problema è stato sollevato anche nel rapporto State of Agile per il 2019/2020, quindi abbiamo deciso di confrontare il modo in cui le attività Agile e DevOps sono collegate nelle aziende. Abbiamo scoperto che DevOps senza Agile è raro. Per la metà degli intervistati, la diffusione di Agile è iniziata molto prima, e circa il 20% ha osservato l'avvio simultaneo, e uno dei segni di un profilo basso sarà l'assenza di pratiche Agile e DevOps:

Topologie di comando

Alla fine dello scorso anno, il libro "Topologie di squadra”, che propone un framework per descrivere le topologie di comando. È diventato interessante per noi se è applicabile alle società russe. E abbiamo posto la domanda: "Quali schemi trovi?".

I team dell'infrastruttura sono osservati nella metà degli intervistati, così come i team separati per lo sviluppo, il test e il funzionamento. I team DevOps separati hanno notato il 45%, tra i quali i rappresentanti di High sono più comuni. Poi vengono i team interfunzionali, che sono anche più comuni in High. Comandi SRE separati appaiono nei profili Alto, Medio e raramente si vedono nel profilo Basso:

Rapporto DevQaOps

Abbiamo visto questa domanda su FaceBook dal caposquadra del team della piattaforma Skyeng: era interessato al rapporto tra sviluppatori, tester e amministratori nelle aziende. L'abbiamo chiesto e abbiamo esaminato le risposte in base ai profili: i rappresentanti di alto profilo hanno meno tecnici operativi e di test per ogni sviluppatore:

Piani per il 2021

Nei piani per il prossimo anno, gli intervistati hanno notato le seguenti attività:

Qui puoi vedere l'intersezione con la conferenza DevOps Live 2020. Abbiamo esaminato attentamente il programma:

• Infrastruttura come prodotto
• Trasformazione DevOps
• Distribuzione delle pratiche DevOps
• DevSecOps
• Case club e discussioni

Ma il tempo della nostra presentazione non è sufficiente per coprire tutti gli argomenti. Lasciato dietro le quinte:

• Piattaforma come servizio e come prodotto;
• Infrastruttura come codice, ambienti e cloud;
• Integrazione e consegna continue;
• Architettura;
• modelli DevSecOps;
• Piattaforma e team interfunzionali.

Segnala abbiamo un voluminoso, 50 pagine, e puoi vederlo in modo più dettagliato.

Riassumendo

Ci auguriamo che la nostra ricerca e il nostro rapporto ti ispirino a sperimentare nuovi approcci allo sviluppo, ai test e alle operazioni, oltre ad aiutarti a navigare, confrontarti con altri partecipanti allo studio e identificare le aree in cui puoi migliorare i tuoi approcci.

Risultati del primo studio sullo stato di DevOps in Russia:

• Chiave metrica. Abbiamo scoperto che le metriche chiave (tempo di consegna, frequenza di implementazione, tempo di ripristino ed errori di modifica) sono adatte per analizzare l'efficacia dei processi di sviluppo, test e operazioni.
• Profili Alto, Medio, Basso. Sulla base dei dati raccolti, possiamo distinguere gruppi statisticamente diversi di Alto, Medio, Basso con caratteristiche distintive in termini di metriche, pratiche, processi e strumenti. I rappresentanti di Alto profilo mostrano risultati migliori rispetto a Basso. È più probabile che raggiungano e superino i loro obiettivi.
• Indicatori, pandemia e piani per il 2021. Un indicatore speciale quest'anno è il modo in cui le aziende hanno affrontato la pandemia. Gli alti rappresentanti se la sono cavata meglio, hanno registrato un maggiore coinvolgimento degli utenti e le ragioni principali del successo sono state processi di sviluppo efficienti e una forte cultura ingegneristica.
• Pratiche DevOps, strumenti e loro sviluppo. I piani principali delle aziende per il prossimo anno includono lo sviluppo di pratiche e strumenti DevOps, l'introduzione di pratiche DevSecOps e cambiamenti nella struttura organizzativa. E l'effettiva implementazione e sviluppo delle pratiche DevOps viene effettuata con l'ausilio di progetti pilota, la formazione di comunità e centri di eccellenza, iniziative ai livelli superiori e inferiori dell'azienda.

Ci piacerebbe sentire il tuo feedback, storie, feedback. Ringraziamo tutti coloro che hanno partecipato allo studio e attendiamo con impazienza la vostra partecipazione l'anno prossimo.

Fonte: habr.com