Estat de DevOps a Rússia 2020

Com entens fins i tot l'estat d'alguna cosa?

Pots confiar en la teva opinió, formada a partir de diverses fonts d'informació, per exemple, publicacions en llocs web o experiència. Pots preguntar als teus companys i amics. Una altra opció és mirar els temes de les jornades: el comitè del programa està format per representants actius del sector, per la qual cosa confiem en ells per triar els temes rellevants. Una àrea separada és la investigació i els informes. Però hi ha un problema. La investigació sobre l'estat de DevOps es realitza anualment a tot el món, les empreses estrangeres publiquen informes i gairebé no hi ha informació sobre DevOps rus.

Però ha arribat el dia en què es va fer un estudi d'aquest tipus, i avui us explicarem els resultats obtinguts. L'estat de DevOps a Rússia va ser estudiat conjuntament per les empreses "Express 42"I"Ontiko" L'empresa Express 42 ajuda les empreses tecnològiques a implementar i desenvolupar pràctiques i eines de DevOps i va ser una de les primeres a parlar de DevOps a Rússia. Els autors de l'estudi, Igor Kurochkin i Vitaly Khabarov, es dediquen a l'anàlisi i consultoria a Express 42, amb una formació tècnica d'operació i experiència en diferents empreses. Durant 8 anys, els companys van analitzar desenes d'empreses i projectes, des de startups fins a empreses, amb diferents problemes, així com amb diferent maduresa cultural i d'enginyeria.

En el seu informe, Igor i Vitaly van explicar quins problemes hi va haver durant el procés d'investigació, com els van resoldre, així com com es duu a terme la investigació de DevOps en principi i per què Express 42 va decidir fer-ne la seva. Podeu veure el seu reportatge aquí.

Recerca DevOps

Igor Kurochkin va iniciar la conversa.

Periòdicament preguntem al públic a les conferències de DevOps: "Has llegit l'informe sobre l'estat de DevOps d'aquest any?" Només uns pocs aixequen la mà, però la nostra investigació va demostrar que només un terç els estudia. Si mai no heu vist aquest tipus d'informes, diguem de seguida que tots són molt semblants. Molt sovint hi ha frases com: "En comparació amb l'any passat..."

Aquí tenim el nostre primer problema, seguit de dos més:

1. No tenim dades de l'any passat. Ningú està interessat en l'estat de DevOps a Rússia;
2. Metodologia. No està clar com provar hipòtesis, com construir preguntes, com realitzar anàlisis, comparar resultats, trobar connexions;
3. Terminologia. Tots els informes estan en anglès, cal la traducció, encara no s'ha inventat un marc comú per a DevOps i cadascú en crea el seu.

Vegem com es van dur a terme generalment les anàlisis de l'estat de DevOps al món.

La informació històrica

La investigació de DevOps es porta a terme des del 2011. El primer a realitzar-los va ser Puppet, un desenvolupador de sistemes de gestió de configuració. En aquell moment, era una de les principals eines per descriure la infraestructura en forma de codi. Fins al 2013, aquests estudis eren simplement enquestes en format tancat i sense informe públic.

El 2013 va aparèixer IT Revolution, editor de tots els llibres principals sobre DevOps. Juntament amb Puppet, van preparar la primera publicació “State of DevOps”, on apareixien per primera vegada 4 mètriques clau. L'any següent, la consultora ThoughtWorks, coneguda pels seus radars tecnològics habituals sobre pràctiques i eines de la indústria, es va implicar. I l'any 2015 s'hi va afegir un apartat amb metodologia, i va quedar clar com realitzen l'anàlisi.

L'any 2016, els autors de l'estudi, després d'haver creat la seva empresa DORA (DevOps Research and Assessment), van publicar un informe anual. L'any següent, DORA i Puppet van emetre el seu informe conjunt final.

I llavors les coses es van posar interessants:

El 2018, les empreses es van dividir i es van publicar dos informes independents: un de Puppet, el segon de DORA en col·laboració amb Google. DORA va continuar utilitzant la seva metodologia amb mètriques clau, perfils de rendiment i pràctiques d'enginyeria que afecten les mètriques i el rendiment clau de l'empresa. I Puppet va proposar el seu enfocament amb una descripció del procés i l'evolució de DevOps. Però la història no es va enganxar; el 2019, Puppet va abandonar aquesta metodologia i va publicar una nova versió dels informes, en què enumerava les pràctiques clau i com afecten a DevOps des del seu punt de vista. Aleshores va passar una altra cosa: Google va comprar DORA i junts van publicar un altre informe. Potser ho heu vist.

Aquest any les coses es van complicar. Se sap que Puppet va llançar la seva enquesta. Ho van fer una setmana abans que nosaltres, i ja estava acabat. Vam participar-hi i vam veure quins temes els interessaven. Puppet està ara fent la seva anàlisi i es prepara per publicar l'informe.

Però encara no hi ha cap anunci de DORA i Google. Al maig, quan començava habitualment l'enquesta, va arribar informació que Nicole Forsgren, una de les fundadores de DORA, s'havia traslladat a una altra empresa. Per tant, vam suposar que no hi hauria cap investigació ni informe de DORA aquest any.

Com van les coses a Rússia?

No hem realitzat cap investigació sobre DevOps. Vam parlar a conferències, explicant les conclusions d'altres persones, i Raiffeisenbank va traduir l'"Estat de DevOps" per al 2019 (podeu trobar el seu anunci a Habré), moltes gràcies a ells. I és tot.

Per tant, vam dur a terme la nostra pròpia investigació a Rússia mitjançant les metodologies i els resultats de DORA. Hem utilitzat l'informe dels companys de Raiffeisenbank per a la nostra investigació, inclòs per sincronitzar terminologia i traducció. I les preguntes rellevants per a la indústria es van extreure dels informes DORA i del qüestionari Puppet d'enguany.

Procés de recerca

L'informe és només la part final. Tot el procés de recerca consta de quatre grans etapes:

Durant l'etapa de preparació, vam entrevistar experts del sector i vam preparar una llista d'hipòtesis. A partir d'ells, vam recopilar preguntes i vam llançar una enquesta per a tot el mes d'agost. Després vam analitzar i elaborar el propi informe. Per a DORA, aquest procés dura 6 mesos. El vam completar en 3 mesos, i ara entenem que amb prou feines vam tenir prou temps: només fent l'anàlisi s'entén quines preguntes cal fer.

Els participants

Tots els informes estrangers comencen amb un retrat dels participants, i la majoria d'ells no són de Rússia. El percentatge d'enquestats russos oscil·la entre un 5 i un 1% d'un any a l'altre, i això no ens permet treure cap conclusió.

Mapa de l'informe Accelerate State of DevOps 2019:

En el nostre estudi, vam poder entrevistar 889 persones, això és bastant (DORA enquesta a un miler de persones anualment als seus informes) i aquí vam aconseguir el nostre objectiu:

És cert que no tots els nostres participants van arribar al final: el percentatge de finalització va ser lleugerament inferior a la meitat. Però això va ser suficient per obtenir una mostra representativa i realitzar anàlisis. DORA no revela les taxes d'ocupació als seus informes, per la qual cosa no es poden fer comparacions aquí.

Indústries i posicions

Els nostres enquestats representen una dotzena d'indústries. Treball mig en tecnologia de la informació. El segueixen els serveis financers, el comerç, les telecomunicacions i altres. Entre les posicions hi ha especialistes (desenvolupador, provador, enginyer d'operacions) i personal directiu (líders d'equips, grups, àrees, directors):

Cada segona persona treballa en una empresa mitjana. Una tercera persona treballa en grans empreses. La majoria treballen en equips de fins a 9 persones. Per separat, vam preguntar sobre les activitats principals, i la majoria estan d'una manera o altra relacionades amb el funcionament, i prop del 40% estan implicats en el desenvolupament:

Així és com vam recopilar informació per a la comparació i anàlisi de representants de diferents indústries, empreses i equips. El meu company Vitaly Khabarov us explicarà l'anàlisi.

Anàlisi i comparació

Vitaly Khabarov: Moltes gràcies a tots els participants que han completat la nostra enquesta, han omplert qüestionaris i ens han donat dades per a una posterior anàlisi i prova de les nostres hipòtesis. I gràcies als nostres clients i clients, tenim una gran experiència que ens ha ajudat a identificar qüestions que preocupen al sector i a formular les hipòtesis que vam provar en la nostra recerca.

Malauradament, no es pot simplement agafar una llista de preguntes d'una banda i dades de l'altra, comparar-les d'alguna manera, dir: "Sí, tot funciona així, teníem raó" i seguir camins separats. No, necessitem metodologia i mètodes estadístics per assegurar-nos que no ens hem equivocat i que les nostres conclusions són fiables. Aleshores podem construir el nostre treball posterior a partir d'aquestes dades:

Mètriques clau

Vam prendre com a base la metodologia DORA, que van descriure amb detall al llibre "Accelerate State of DevOps". Hem comprovat si les mètriques clau són adequades per al mercat rus, si es poden utilitzar de la mateixa manera que DORA fa servir per respondre a la pregunta: "Com es correspon la indústria a Rússia amb la indústria estrangera?"

Mètriques clau:

1. Freqüència de desplegament. Amb quina freqüència s'implementa una versió nova d'una aplicació a l'entorn de producció (canvis planificats, excloent les correccions ràpides i la resposta a incidents)?
2. Hora d'entrega. Quin és el temps mitjà entre la realització d'un canvi (escriptura de la funcionalitat com a codi) i la implementació del canvi a l'entorn de producció?
3. Temps de recuperació. Quant de temps triga de mitjana a restaurar una aplicació en un entorn de producció després d'un incident, una degradació del servei o la detecció d'un error que afecta els usuaris de l'aplicació?
4. Canvis sense èxit. Quin percentatge de desplegaments en un entorn de producte condueixen a la degradació de l'aplicació o a incidents i requereixen l'eliminació de conseqüències (reversió dels canvis, desenvolupament d'una correcció o pedaç)?

La investigació de DORA ha trobat una connexió entre aquestes mètriques i el rendiment de l'organització. També ho comprovem al nostre estudi.

Però per assegurar-vos que les quatre mètriques clau poden influir en alguna cosa, heu d'entendre: estan relacionades d'alguna manera entre elles? DORA va respondre que sí, amb una advertència: la relació entre la taxa de fracàs del canvi i les altres tres mètriques és lleugerament més feble. Tenim aproximadament la mateixa imatge. Si el temps de lliurament, la freqüència de desplegament i el temps de recuperació estan correlacionats entre si (hem establert aquesta correlació mitjançant la correlació de Pearson i l'escala de Chaddock), aleshores no hi ha una correlació tan forta amb els canvis sense èxit.

En principi, la majoria dels enquestats tendeixen a respondre que tenen un nombre força reduït d'incidents que es produeixen a la producció. Tot i que veurem més endavant que encara hi ha una diferència significativa entre els grups d'enquestats en la taxa de canvis sense èxit, encara no podem utilitzar aquesta mètrica per a aquesta divisió.

Ho atribuïm al fet que (tal com va resultar en el procés d'anàlisi i comunicació amb alguns dels nostres clients) hi ha una lleugera diferència en la percepció del que es considera una incidència. Si aconseguim restaurar la funcionalitat del nostre servei durant la finestra tècnica, es pot considerar una incidència? Probablement no, perquè ho hem arreglat tot, som genials. Es pot considerar un incident si haguéssim de tornar a enrotllar la nostra aplicació 10 vegades en el mode normal i familiar? Sembla que no. Per tant, la qüestió de la relació entre canvis infructuosos i altres mètriques continua oberta. Ho aclarirem més.

El que és important aquí és que hem trobat una correlació significativa entre el temps de lliurament, el temps de recuperació i la freqüència de desplegament. Per tant, vam utilitzar aquestes tres mètriques per dividir encara més els enquestats en grups en funció de la productivitat.

Quant penjar en grams?

Hem utilitzat l'anàlisi de clúster jeràrquic:

• Distribuïm els enquestats per un espai n-dimensional, on la coordenada de cada enquestat és les seves respostes a les preguntes.
• Declarem que cada enquestat és un grup petit.
• Combinem els dos grups més propers l'un a l'altre en un clúster més gran.
• Trobem el següent parell de cúmuls i els combinem en un cúmul més gran.

Així és com agrupem tots els nostres enquestats en el nombre de clústers que necessitem. Utilitzant un dendrograma (un arbre de connexions entre clústers) veiem la distància entre dos clústers veïns. Només ens queda establir un cert límit a la distància entre aquests grups i dir: "Aquests dos grups es distingeixen bastant entre ells perquè la distància entre ells és gegantina".

Però aquí hi ha un problema amagat: no tenim restriccions sobre el nombre de clústers: podem obtenir 2, 3, 4, 10 clústers. I la primera idea va ser: per què no dividir tots els nostres enquestats en 4 grups, com fa DORA? Però vam comprovar que les diferències entre aquests grups esdevenen insignificants i no podem estar segurs que l'enquestat pertanyi realment al seu grup i no al veí. Encara no podem dividir el mercat rus en quatre grups. Per tant, ens hem fixat en tres perfils, entre els quals hi ha una diferència estadísticament significativa:

A continuació, vam determinar el perfil per clúster: vam prendre les mitjanes de cada mètrica per a cada grup i vam compilar una taula de perfils d'eficiència. De fet, es van obtenir els perfils de rendiment resultants per al participant mitjà de cada grup. Hem identificat tres perfils d'eficiència: Baix, Mitjà i Alt:

Aquí hem confirmat la nostra hipòtesi que 4 mètriques clau són adequades per determinar el perfil de rendiment i funcionen tant al mercat occidental com al mercat rus. Hi ha una diferència entre els grups, i és estadísticament significativa. M'agradaria subratllar que hi ha una diferència significativa en la mitjana entre els perfils de rendiment per a la mètrica dels canvis no reeixits, tot i que inicialment no vam dividir els enquestats per aquest paràmetre.

Aleshores sorgeix la pregunta: com utilitzar tot això?

Com s'utilitza

Si agafem qualsevol equip, 4 mètriques clau i les apliquem a la taula, en el 85% dels casos no obtindrem un partit complet: aquest és només el participant mitjà i no el que és en realitat. Tots (i cada equip) som una mica diferents.

Vam comprovar: vam agafar els nostres enquestats i el perfil de rendiment DORA, i vam mirar quants enquestats corresponien a un o altre perfil. Hem trobat que només el 16% dels enquestats entraven amb precisió en un dels perfils. Tota la resta es troben disperses entremig:

Això vol dir que el perfil de rendiment té un abast limitat. Per obtenir una primera aproximació d'on et trobes, pots fer servir aquesta taula: "Oh, sembla que estem més a prop de Mitjà o Alt!" Si enteneu cap a on aneu a continuació, pot ser suficient. Però si el vostre objectiu és la millora constant i contínua i voleu saber amb més precisió on desenvolupar-vos i què fer, calen fons addicionals. Els hem anomenat calculadores:

• Calculadora DORA
• Calculadora Express 42* (en desenvolupament)
• El vostre propi desenvolupament (pots crear la teva pròpia calculadora interna).

Per a què es necessiten? Entendre:

• L'equip de la nostra organització compleix els nostres estàndards?
• Si no, podem ajudar-la - accelerar-ho en el marc de l'experiència que té la nostra empresa?
• Si és així, ho podem fer encara millor?

També podeu utilitzar-los per recopilar estadístiques dins de l'empresa:

• Quin tipus d'equips tenim?
• Dividir els equips en perfils;
• Vegeu: Ah, aquests equips tenen un rendiment inferior (una mica lents), però són fantàstics: es despleguen cada dia, sense errors, el seu temps de lliurament és inferior a una hora.

I aleshores podreu descobrir que dins de la nostra empresa disposem de l'experiència i les eines necessàries per a aquells equips que encara s'estan quedant curts.

O, si entens que et sents molt bé dins de l'empresa, que ets millor que molts, pots mirar una mica més ampli. Aquesta és precisament la indústria russa: podem obtenir l'experiència necessària en la indústria russa per accelerar-nos? La calculadora Express 42 us ajudarà aquí (està en desenvolupament). Si heu superat el mercat rus, mireu Calculadora DORA i al mercat mundial.

Bé. I si sou al grup Elit segons la calculadora DORA, què heu de fer? Aquí no hi ha una bona solució. El més probable és que estiguis a l'avantguarda del sector, i es poden accelerar i millorar la fiabilitat mitjançant R+D interna i la despesa de grans recursos.

Passem a la part més dolça: la comparació.

Comparació

Al principi volíem comparar la indústria russa amb la indústria occidental. Si comparem directament, veiem que tenim menys perfils, i estan una mica més barrejats entre ells, els límits són una mica més difuminats:

Els nostres artistes d'elit s'amaguen entre els d'alt rendiment, però hi són: aquests són l'elit, els unicorns que han assolit cotes importants. A Rússia, la diferència entre els perfils Elit i Alt encara no és prou significativa. Pensem que en el futur aquesta divisió es produirà a causa de l'augment de la cultura de l'enginyeria, la qualitat de la implantació de les pràctiques d'enginyeria i l'experiència dins de les empreses.

Si passem a la comparació directa dins de la indústria russa, veiem que els equips d'alt perfil són millors en tots els aspectes. També vam confirmar la nostra hipòtesi que hi ha una connexió entre aquestes mètriques i l'eficàcia de l'organització: els equips d'alt perfil tenen més probabilitats no només d'assolir els objectius, sinó també de superar-los.
Convertim-nos en equips d'alt perfil i no ens aturem aquí:

Però aquest any és especial i vam decidir comprovar com viuen les empreses en una pandèmia: els equips d'alt perfil s'enfronten molt millor i se senten millor que la mitjana del sector:

• Els nous productes es van llançar 1,5-2 vegades més sovint,
• Augment de la fiabilitat i/o rendiment de la infraestructura d'aplicacions dues vegades més sovint.

És a dir, les competències que ja tenien els van ajudar a desenvolupar-se més ràpidament, introduir nous productes, modificar productes existents, i així conquerir nous mercats i nous usuaris:

Què més ha ajudat als nostres equips?

Pràctiques d'enginyeria

Us explicaré les troballes significatives per a cada pràctica que vam comprovar. Potser alguna cosa més va ajudar els equips, però estem parlant de DevOps. I dins de DevOps, veiem diferències entre equips de diferents perfils.

Plataforma com a servei

No hem trobat una relació significativa entre l'edat de la plataforma i el perfil de l'equip: les plataformes van aparèixer aproximadament al mateix temps per als equips Baix i Alt. Però per a aquest últim, la plataforma ofereix de mitjana més serveis i més interfícies de programari per al control mitjançant codi de programa. I és més probable que els equips de la plataforma ajudin els seus desenvolupadors i equips a utilitzar la plataforma, més probabilitats de resoldre els seus problemes i incidències relacionades amb la plataforma i formar altres equips.

Infraestructura com a codi

Aquí tot és bastant estàndard. Hem trobat una relació entre l'automatització del codi d'infraestructura i la quantitat d'informació emmagatzemada al dipòsit d'infraestructura. Els equips d'alt perfil emmagatzemen més informació als dipòsits: això inclou la configuració de la infraestructura, el pipeline CI/CD, la configuració de l'entorn i els paràmetres de compilació. Emmagatzemen aquesta informació amb més freqüència, funcionen millor amb el codi d'infraestructura i han automatitzat més processos i tasques per treballar amb codi d'infraestructura.

Curiosament, no vam veure una diferència significativa en les proves d'infraestructura. Ho atribueixo al fet que els equips d'alt perfil generalment tenen més automatització de proves. Potser no s'han de distreure per separat amb les proves d'infraestructura, sinó que les proves que fan servir per comprovar les aplicacions són suficients, i gràcies a elles poden veure què i on s'han trencat.

Integració i lliurament

La secció més avorrida, perquè vam confirmar: com més automatització tinguis, millor treballes amb el codi, més probabilitats tindreu d'obtenir millors resultats.

arquitectura

Volíem veure com els microserveis afecten el rendiment. Per ser sincers, no ho fan, ja que l'ús de microserveis no està associat a un augment dels indicadors d'eficiència. Els microserveis són utilitzats tant per equips de perfil alt com per baix.

Però el que és significatiu és que per als equips alts, la transició a una arquitectura de microserveis els permet desenvolupar de manera independent els seus serveis i desplegar-los. Si l'arquitectura permet als desenvolupadors actuar de manera autònoma, sense esperar a algú extern a l'equip, aquesta és una competència clau per augmentar la velocitat. Aquí és on els microserveis ajuden. Però simplement la seva implementació no té un paper important.

Com vam descobrir tot això?

Teníem un pla ambiciós per replicar completament la metodologia DORA, però ens mancaven els recursos. Si DORA fa servir molt de patrocini i l'estudi els porta sis mesos, vam realitzar el nostre estudi en poc temps. Volíem crear un model DevOps com fa DORA, i ho farem en el futur. De moment ens hem limitat als mapes de calor:

Vam analitzar la distribució de les pràctiques d'enginyeria entre els equips de cada perfil i vam trobar que els equips de perfil alt, de mitjana, utilitzen pràctiques d'enginyeria amb més freqüència. Pots llegir més sobre tot això al nostre informe.

Per variar, passem d'estadístiques complexes a estadístiques senzilles.

Què més hem descobert?

Instruments

Observem que la família del sistema operatiu Linux utilitza més ordres. Però Windows encara està en tendència: almenys una quarta part dels nostres enquestats van assenyalar l'ús d'una o altra versió. El mercat sembla tenir aquesta necessitat. Per tant, podeu desenvolupar aquestes competències i fer presentacions en conferències.

Entre els orquestradors, no és cap secret que Kubernetes lidera (52%). El següent orquestrador en línia és Docker Swarm (al voltant del 12%). Els sistemes CI més populars són Jenkins i GitLab. El sistema de gestió de configuració més popular és Ansible, seguit del nostre estimat Shell.

Entre els proveïdors d'allotjament en núvol, Amazon ocupa actualment la posició de lideratge. La proporció de núvols russos augmenta gradualment. L'any que ve serà interessant veure com es sentiran els proveïdors de núvol russos i si augmentarà la seva quota de mercat. Existeixen, es poden utilitzar i això és bo:

Dono la paraula a Igor, que donarà més estadístiques.

Difusió de pràctiques

Igor Kurochkin: Per separat, vam demanar als enquestats que indiquin com es distribueixen les pràctiques d'enginyeria considerades a l'empresa. La majoria de les empreses tenen un enfocament mixt que consisteix en un conjunt diferent de patrons, i els projectes pilot són molt populars. També vam veure una lleugera diferència entre els perfils. Els representants de l'alt perfil utilitzen més sovint el patró "Iniciativa des de baix", quan petits equips d'especialistes canvien els processos de treball, les eines i comparteixen desenvolupaments reeixits amb altres equips. A Medium, es tracta d'una iniciativa de dalt a baix que toca tota l'empresa mitjançant la creació de comunitats i centres d'excel·lència:

Àgil i DevOps

La relació entre Agile i DevOps es discuteix sovint a la indústria. Aquesta pregunta també es planteja a l'Informe sobre l'estat de l'Àgil per al 2019/2020, per la qual cosa hem decidit comparar com es relacionen les activitats Agile i DevOps a les empreses. Hem trobat que DevOps sense Agile és rar. Per a la meitat dels enquestats, la propagació d'Agile va començar notablement abans i al voltant del 20% va observar un inici simultani, i un dels signes d'un perfil baix serà l'absència de pràctiques àgils i DevOps:

Topologies d'equip

A finals de l'any passat el llibre “Topologies d'equip", que proposa un marc per descriure topologies d'equip. Ens vam preguntar si s'aplicaria a les empreses russes. I vam fer la pregunta: "Quins patrons veus?"

S'observen equips d'infraestructura a la meitat dels enquestats, així com equips separats de desenvolupament, proves i operacions. Els equips de DevOps individuals van anotar un 45%, entre els quals els alts representants són més habituals. A continuació vénen els equips multifuncionals, que també són més habituals a High. Les ordres SRE separades apareixen als perfils alt i mitjà i rarament es troben al perfil baix:

Relació DevQaOps

Vam veure aquesta pregunta a FaceBook del cap de l'equip de la plataforma Skyeng: estava interessat en la proporció de desenvolupadors, provadors i administradors a les empreses. Ho vam preguntar i vam mirar les respostes tenint en compte els perfils: els representants de l'alt perfil tenen un nombre menor d'enginyers de proves i operacions per a cada desenvolupador:

Plans per al 2021

En els seus plans per al proper any, els enquestats van assenyalar les activitats següents:

Aquí podeu veure la intersecció amb la conferència DevOps Live 2020. Hem revisat acuradament el programa:

• La infraestructura com a producte
• Transformació DevOps
• Distribució de pràctiques de DevOps
• DevSecOps
• Clubs de casos i discussions

Però la nostra xerrada no tindrà prou temps per tractar tots els temes. Darrere les càmeres:

• Plataforma com a servei i com a producte;
• Infraestructura com a codi, entorns i núvols;
• Integració i lliurament contínues;
• Arquitectura;
• Patrons DevSecOps;
• Plataforma i equips multifuncionals.

Informe El nostre és voluminós, de 50 pàgines, i el podeu veure amb més detall.

En resum

Esperem que la nostra investigació i informe us inspirin a experimentar amb nous enfocaments de desenvolupament, proves i operacions, així com us ajudin a orientar-vos, a comparar-vos amb els altres de l'estudi i a identificar àrees on podeu millorar els vostres propis enfocaments. .

Resultats del primer estudi de l'estat de DevOps a Rússia:

• Mètriques clau. Hem trobat que les mètriques clau (temps de lliurament, índex de desplegament, temps de recuperació i errors de canvi) són adequades per analitzar l'eficàcia dels processos de desenvolupament, proves i operacions.
• Perfils Alt, Mitjà, Baix. A partir de les dades recollides, és possible identificar estadísticament diferents grups: Alt, Mitjà, Baix, amb trets distintius basats en mètriques, pràctiques, processos i eines. Els representants de l'alt perfil mostren millors resultats que els baixos. Tenen més probabilitats d'assolir i superar els seus objectius.
• Indicadors, pandèmia i plans per al 2021. Un indicador especial d'aquest any és com les empreses van fer front a la pandèmia. High va tenir un millor rendiment, va experimentar un augment de l'activitat dels usuaris i les principals raons de l'èxit van ser processos de desenvolupament eficients i una forta cultura d'enginyeria.
• Pràctiques, eines de DevOps i el seu desenvolupament. Els principals plans de les empreses per al proper any inclouen el desenvolupament de pràctiques i eines DevOps, la introducció de pràctiques DevSecOps i canvis en l'estructura organitzativa. I la implementació i el desenvolupament efectius de les pràctiques DevOps es duu a terme mitjançant projectes pilot, formació de comunitats i centres de competència, iniciatives als nivells superiors i inferiors de l'empresa.

Estarem encantats d'escoltar els vostres comentaris, històries, comentaris. Donem les gràcies a tots els que han participat en l'estudi i esperem la vostra participació l'any vinent.

Font: www.habr.com