Estado de DevOps en Rusia 2020

Como entendes o estado de algo?

Podes confiar na túa opinión, formada a partir de diversas fontes de información, por exemplo, publicacións en sitios web ou experiencia. Podes preguntar aos teus compañeiros e amigos. Outra opción é mirar os temas das xornadas: a comisión do programa está formada por representantes activos do sector, polo que confiamos neles para escoller os temas relevantes. Unha área separada é a investigación e os informes. Pero hai un problema. A investigación sobre o estado de DevOps realízase anualmente en todo o mundo, os informes son publicados por empresas estranxeiras e case non hai información sobre o DevOps ruso.

Pero chegou o día no que se realizou un estudo deste tipo e hoxe contarémosvos os resultados obtidos. O estado de DevOps en Rusia foi estudado conxuntamente polas empresas "Express 42"E"Ontico" A empresa Express 42 axuda ás empresas tecnolóxicas a implementar e desenvolver prácticas e ferramentas de DevOps e foi unha das primeiras en falar de DevOps en Rusia. Os autores do estudo, Igor Kurochkin e Vitaly Khabarov, dedícanse á análise e consultoría en Express 42, con formación técnica de operación e experiencia en diferentes empresas. Ao longo de 8 anos, os compañeiros analizaron decenas de empresas e proxectos -desde startups ata empresas- con diferentes problemas, así como con diferente madurez cultural e de enxeñería.

No seu informe, Igor e Vitaly explicaron que problemas houbo durante o proceso de investigación, como os resolveron, así como como se realiza en principio a investigación de DevOps e por que Express 42 decidiu realizar a súa propia. Podes ver o seu informe aquí.

Investigación DevOps

Igor Kurochkin comezou a conversa.

Preguntámoslle regularmente ao público das conferencias de DevOps: "Liches o informe sobre o estado de DevOps deste ano?" Só algúns levantan a man, pero a nosa investigación demostrou que só un terzo os estuda. Se nunca viches este tipo de informes, digamos de inmediato que todos son moi similares. A maioría das veces hai frases como: "Comparado co ano pasado..."

Aquí temos o noso primeiro problema, seguido de dous máis:

1. Non temos datos do ano pasado. Ninguén está interesado no estado de DevOps en Rusia;
2. Metodoloxía. Non está claro como probar hipóteses, como construír preguntas, como realizar análises, comparar resultados, atopar conexións;
3. Terminoloxía. Todos os informes están en inglés, é necesaria a tradución, aínda non se inventou un marco común para DevOps e cada un crea o seu.

Vexamos como se realizaron xeralmente as análises do estado de DevOps no mundo.

Información histórica

A investigación DevOps realízase desde 2011. O primeiro en realizalos foi Puppet, un desenvolvedor de sistemas de xestión de configuración. Nese momento, era unha das principais ferramentas para describir a infraestrutura en forma de código. Ata 2013, estes estudos eran simplemente enquisas en formato pechado e sen informe público.

En 2013, apareceu IT Revolution, editora de todos os principais libros sobre DevOps. Xunto con Puppet, prepararon a primeira publicación “State of DevOps”, onde apareceron por primeira vez 4 métricas clave. Ao ano seguinte, a consultora ThoughtWorks, coñecida polos seus radares tecnolóxicos habituais sobre prácticas e ferramentas da industria, involucrouse. E en 2015 engadiuse un apartado con metodoloxía, e quedou claro como realizan a análise.

En 2016, os autores do estudo, despois de crear a súa empresa DORA (DevOps Research and Assessment), publicaron un informe anual. Ao ano seguinte, DORA e Puppet emitiron o seu informe final conxunto.

E entón as cousas foron interesantes:

En 2018, as empresas separáronse e lanzáronse dous informes independentes: un de Puppet, o segundo de DORA en colaboración con Google. DORA continuou utilizando a súa metodoloxía con métricas clave, perfís de rendemento e prácticas de enxeñería que afectan as métricas clave e o rendemento en toda a empresa. E Puppet propuxo o seu enfoque cunha descrición do proceso e da evolución de DevOps. Pero a historia non colleu; en 2019, Puppet abandonou esta metodoloxía e lanzou unha nova versión dos informes, na que enumeraba as prácticas clave e como afectan a DevOps desde o seu punto de vista. Despois pasou outra cousa: Google comprou DORA, e xuntos lanzaron outro informe. Quizais o viches.

Este ano as cousas complicáronse. Sábese que Puppet lanzou a súa enquisa. Fixérono unha semana antes ca nós, e xa estaba rematado. Participamos nel e vimos que temas lles interesaban. Puppet está agora a realizar a súa análise e prepárase para publicar o informe.

Pero aínda non hai ningún anuncio de DORA e Google. En maio, cando comezaba habitualmente a enquisa, chegou a información de que Nicole Forsgren, unha das fundadoras de DORA, mudouse a outra empresa. Polo tanto, supuxemos que non habería investigación nin informe de DORA este ano.

Como están as cousas en Rusia?

Non realizamos ningunha investigación sobre DevOps. Falamos en conferencias, contando as conclusións doutras persoas, e Raiffeisenbank traduciu o "Estado de DevOps" para 2019 (podes atopar o seu anuncio en Habré), moitas grazas a eles. E é todo.

Polo tanto, realizamos a nosa propia investigación en Rusia utilizando metodoloxías e descubrimentos DORA. Usamos o informe de compañeiros de Raiffeisenbank para a nosa investigación, incluso para sincronizar terminoloxía e tradución. E as preguntas relevantes para a industria foron tomadas dos informes DORA e do cuestionario Puppet deste ano.

Proceso de investigación

O informe é só a parte final. Todo o proceso de investigación consta de catro grandes etapas:

Durante a fase de preparación, entrevistamos expertos do sector e preparamos unha lista de hipóteses. En base a eles, recompilamos preguntas e lanzamos unha enquisa para todo o mes de agosto. Despois analizamos e elaboramos o propio informe. Para DORA, este proceso leva 6 meses. Rematámolo en 3 meses, e agora entendemos que apenas tivemos tempo: só facendo a análise entendes que preguntas hai que facer.

Participantes

Todos os informes estranxeiros comezan cun retrato dos participantes, e a maioría deles non son de Rusia. A porcentaxe de enquisados ​​rusos oscila entre o 5 e o 1% dun ano a outro, e isto non nos permite sacar ningunha conclusión.

Mapa do informe Accelerate State of DevOps 2019:

No noso estudo, puidemos entrevistar a 889 persoas - isto é bastante (DORA enquisa unhas mil persoas ao ano nos seus informes) e aquí conseguimos o noso obxectivo:

É certo que non todos os nosos participantes chegaron ao final: a porcentaxe de realización foi algo menos da metade. Pero isto foi suficiente para obter unha mostra representativa e realizar análises. DORA non revela os índices de ocupación nos seus informes, polo que non se poden facer comparacións aquí.

Industrias e postos

Os nosos enquisados ​​representan unha ducia de industrias. Medio traballo en tecnoloxía da información. Séguenlle os servizos financeiros, o comercio, as telecomunicacións e outros. Entre os postos atópanse especialistas (desenvolvedor, probador, enxeñeiro de operación) e persoal directivo (líderes de equipos, grupos, áreas, directores):

Cada segunda persoa traballa nunha mediana empresa. Cada terceira persoa traballa en grandes empresas. A maioría traballa en equipos de ata 9 persoas. Por separado, preguntamos sobre as actividades principais, e a maioría están dun xeito ou outro relacionados coa operación, e preto do 40% están implicados no desenvolvemento:

Así recompilamos información para a comparación e análise de representantes de diferentes industrias, empresas e equipos. O meu compañeiro Vitaly Khabarov falarache da análise.

Análise e comparación

Vitaly Khabarov: Moitas grazas a todos os participantes que completaron a nosa enquisa, cubriron cuestionarios e nos deron datos para analizar e probar as nosas hipóteses. E grazas aos nosos clientes e clientes, temos unha gran experiencia que nos axudou a identificar problemas que preocupan ao sector e a formular as hipóteses que probamos na nosa investigación.

Desafortunadamente, non pode simplemente tomar unha lista de preguntas por un lado e datos por outro, comparalos dalgún xeito, dicir: "Si, todo funciona así, tiñamos razón" e seguir camiños separados. Non, necesitamos metodoloxía e métodos estatísticos para estar seguros de que non nos equivocamos e de que as nosas conclusións son fiables. Despois podemos construír o noso traballo posterior a partir destes datos:

Métricas clave

Tomamos como base a metodoloxía DORA, que describiron en detalle no libro "Accelerate State of DevOps". Comprobamos se as métricas clave son adecuadas para o mercado ruso, se poden usarse do mesmo xeito que DORA usa para responder á pregunta: "Como se corresponde a industria en Rusia coa industria estranxeira?"

Métricas clave:

1. Frecuencia de implantación. Con que frecuencia se implementa unha nova versión dunha aplicación no contorno de produción (cambios planificados, excluíndo correccións e resposta a incidentes)?
2. Tempo de entrega. Cal é o tempo medio entre a realización dun cambio (escribindo a funcionalidade como código) e a implantación do cambio no contorno de produción?
3. Tempo de recuperación. Canto tempo leva de media restaurar unha aplicación nun ambiente de produción despois dun incidente, unha degradación do servizo ou a detección dun erro que afecta aos usuarios da aplicación?
4. Cambios sen éxito. Que porcentaxe de implantacións nun ambiente de produto conducen á degradación da aplicación ou a incidentes e requiren a eliminación de consecuencias (reversión de cambios, desenvolvemento dun hotfix ou parche)?

A investigación de DORA atopou unha conexión entre estas métricas e o rendemento da organización. Tamén o comprobámolo no noso estudo.

Pero para asegurarse de que as catro métricas clave poden influír en algo, cómpre comprender: ¿están relacionadas dalgún xeito entre si? DORA respondeu que si, cunha advertencia: a relación entre a taxa de fallos do cambio e as outras tres métricas é lixeiramente máis débil. Temos aproximadamente a mesma imaxe. Se o tempo de entrega, a frecuencia de implantación e o tempo de recuperación están correlacionados entre si (establecemos esta correlación a través da correlación de Pearson e a través da escala de Chaddock), entón non existe unha correlación tan forte cos cambios non exitosos.

En principio, a maioría dos enquisados ​​adoitan responder que teñen un número bastante reducido de incidentes que ocorren na produción. Aínda que veremos máis adiante que aínda existe unha diferenza significativa entre os grupos de enquisados ​​na taxa de cambios non exitosos, aínda non podemos utilizar esta métrica para esta división.

Atribuímos isto ao feito de que (como resultou no proceso de análise e comunicación con algúns dos nosos clientes) hai unha lixeira diferenza na percepción do que se considera un incidente. Se conseguimos restaurar a funcionalidade do noso servizo durante a xanela técnica, pódese considerar unha incidencia? Probablemente non, porque arranxamos todo, somos xeniais. Pódese considerar un incidente se tivésemos que volver lanzar a nosa aplicación 10 veces no modo normal e familiar? Parece que non. Polo tanto, a cuestión da relación entre os cambios non exitosos e outras métricas segue aberta. Aclararémolo máis.

O importante aquí é que atopamos unha correlación significativa entre o tempo de entrega, o tempo de recuperación e a frecuencia de implantación. Polo tanto, tomamos estas tres métricas para dividir aínda máis os entrevistados en grupos en función da produtividade.

Que hai que colgar en gramos?

Utilizamos a análise de clusters xerárquicos:

• Distribuímos os entrevistados por espazo n-dimensional, onde a coordenada de cada entrevistado é as súas respostas ás preguntas.
• Declaramos que cada entrevistado é un pequeno grupo.
• Combinamos os dous grupos máis próximos un do outro nun grupo máis grande.
• Atopamos o seguinte par de grupos e combinámolos nun grupo máis grande.

Así é como agrupamos a todos os nosos enquisados ​​no número de clusters que necesitamos. Usando un dendrograma (unha árbore de conexións entre clusters) vemos a distancia entre dous clusters veciños. Só nos queda establecer un certo límite na distancia entre estes grupos e dicir: "Estes dous grupos son bastante distinguibles entre si porque a distancia entre eles é xigantesca".

Pero aquí hai un problema oculto: non temos restricións sobre o número de clusters: podemos obter 2, 3, 4, 10 clusters. E a primeira idea foi: por que non dividir a todos os nosos enquisados ​​en 4 grupos, como fai DORA. Pero comprobamos que as diferenzas entre estes grupos fanse insignificantes e non podemos estar seguros de que o entrevistado pertenza realmente ao seu grupo e non ao veciño. Aínda non podemos dividir o mercado ruso en catro grupos. Polo tanto, optamos por tres perfís, entre os que hai unha diferenza estatisticamente significativa:

A continuación, determinamos o perfil por clúster: tomamos as medianas de cada métrica para cada grupo e elaboramos unha táboa de perfís de eficiencia. De feito, obtivéronse os perfís de rendemento resultantes para o participante medio de cada grupo. Identificamos tres perfís de eficiencia: Baixo, Medio e Alto:

Aquí confirmamos a nosa hipótese de que 4 métricas clave son adecuadas para determinar o perfil de rendemento e funcionan tanto no mercado occidental como no ruso. Hai unha diferenza entre os grupos, e é estatisticamente significativa. Gustaríame subliñar que existe unha diferenza significativa na media entre os perfís de rendemento para a métrica de cambios non exitosos, aínda que inicialmente non dividimos os entrevistados por este parámetro.

Entón xorde a pregunta: como usar todo isto?

Como usar

Se tomamos calquera equipo, 4 métricas clave e o aplicamos á táboa, entón no 85% dos casos non conseguiremos unha partida completa: este é só o participante medio e non o que é na realidade. Todos (e cada equipo) somos un pouco diferentes.

Comprobamos: tomamos os nosos enquisados ​​e o perfil de rendemento DORA, e miramos cantos entrevistados correspondían a un ou outro perfil. Descubrimos que só o 16% dos enquisados ​​caía con precisión nun dos perfís. Todo o resto están espallados nalgún lugar intermedio:

Isto significa que o perfil de rendemento ten un alcance limitado. Para obter unha primeira aproximación de onde estás, podes usar esta táboa: "Oh, parece que estamos máis preto de Medio ou Alto!" Se entendes a onde vai a continuación, pode ser suficiente. Pero se o teu obxectivo é a mellora continua e constante e queres saber con máis precisión onde desenvolver e que facer, entón son necesarios fondos adicionais. Chamámoslles calculadoras:

• Calculadora DORA
• Calculadora Express 42* (en desenvolvemento)
• O teu propio desenvolvemento (podes crear a túa propia calculadora interna).

Para que son necesarios? Entender:

• O equipo da nosa organización cumpre os nosos estándares?
• Se non, podemos axudala a aceleralo no marco da experiencia que ten a nosa empresa?
• Se é así, podemos facelo aínda mellor?

Tamén pode usalos para recoller estatísticas dentro da empresa:

• Que tipo de equipos temos?
• Dividir os equipos en perfís;
• Ver: Ah, estes equipos teñen un rendemento inferior (un pouco lento), pero son xeniais: despréganse todos os días, sen erros, o seu tempo de entrega é inferior a unha hora.

E entón podes descubrir que dentro da nosa empresa contamos coa experiencia e as ferramentas necesarias para aqueles equipos que aínda se están quedando curtos.

Ou, se entendes que te sentes moi ben dentro da empresa, que es mellor que moitos, podes ver un pouco máis amplamente. Esta é precisamente a industria rusa: podemos obter a experiencia necesaria na industria rusa para acelerarnos? A calculadora Express 42 axudarache aquí (está en desenvolvemento). Se superou o mercado ruso, mira Calculadora DORA e ao mercado mundial.

Ben. E se estás no grupo Elit segundo a calculadora DORA, que deberías facer? Non hai unha boa solución aquí. O máis probable é que esteas á fronte do sector, e é posible unha maior aceleración e melloras na fiabilidade mediante a I+D interna e o gasto de grandes recursos.

Pasemos á parte máis doce: a comparación.

Comparación

Inicialmente queriamos comparar a industria rusa coa industria occidental. Se comparamos directamente, vemos que temos menos perfís, e están un pouco máis mesturados entre si, os límites son un pouco máis borrosos:

Os nosos artistas de élite están escondidos entre os de alto rendemento, pero están aí: estes son os unicornios de elite que alcanzaron alturas significativas. En Rusia, a diferenza entre os perfís Elite e High aínda non é o suficientemente significativa. Pensamos que no futuro esta división producirase debido ao aumento da cultura da enxeñaría, a calidade da implantación das prácticas de enxeñería e a experiencia dentro das empresas.

Se pasamos á comparación directa dentro da industria rusa, vemos que os equipos de alto perfil son mellores en todos os aspectos. Tamén confirmamos a nosa hipótese de que existe unha conexión entre estas métricas e a eficacia da organización: os equipos de alto perfil teñen moito máis probabilidades non só de acadar os obxectivos, senón tamén de superalos.
Convertémonos en equipos de alto perfil e non nos quedemos aí:

Pero este ano é especial, e decidimos comprobar como as empresas están a vivir nunha pandemia: os equipos de alto perfil afrontan moito mellor e séntense mellor que a media do sector:

• Os novos produtos lanzáronse 1,5-2 veces máis a miúdo,
• Aumento da fiabilidade e/ou rendemento da infraestrutura de aplicacións dúas veces máis frecuentemente.

É dicir, as competencias que xa tiñan axudáronlles a desenvolver máis rápido, introducir novos produtos, modificar produtos existentes, conquistando así novos mercados e novos usuarios:

Que máis axudou aos nosos equipos?

Prácticas de enxeñaría

Vouvos contar os achados significativos para cada práctica que comprobamos. Quizais algo máis axudou aos equipos, pero estamos a falar de DevOps. E dentro de DevOps, vemos diferenzas entre equipos de diferentes perfís.

Plataforma como servizo

Non atopamos unha relación significativa entre a idade da plataforma e o perfil do equipo: as plataformas apareceron aproximadamente ao mesmo tempo para os equipos Baixo e Alto. Pero para estes últimos, a plataforma ofrece de media máis servizos e máis interfaces de software para o control a través do código do programa. E é máis probable que os equipos da plataforma axuden aos seus desenvolvedores e equipos a utilizar a plataforma, que resolvan os seus problemas e incidentes relacionados coa plataforma e que formen a outros equipos.

Infraestrutura como código

Todo aquí é bastante estándar. Atopamos unha relación entre a automatización do código de infraestrutura e a cantidade de información almacenada no repositorio de infraestrutura. Os equipos de alto perfil almacenan máis información nos repositorios: isto inclúe a configuración da infraestrutura, a canalización de CI/CD, a configuración do ambiente e os parámetros de compilación. Almacenan esta información con máis frecuencia, funcionan mellor co código de infraestrutura e automatizaron máis procesos e tarefas para traballar co código de infraestrutura.

Curiosamente, non vimos unha diferenza significativa nas probas de infraestrutura. Atribúo isto ao feito de que os equipos de alto perfil xeralmente teñen máis automatización de probas. Quizais non deberían distraerse por separado coas probas de infraestrutura, senón que as probas que utilizan para comprobar as aplicacións son suficientes, e grazas a elas poden ver que e onde romperon.

Integración e Entrega

A sección máis aburrida, porque confirmamos: canto máis automatización teñas, mellor traballes co código, máis probabilidades tes de obter mellores resultados.

Arquitectura

Queriamos ver como afectan os microservizos no rendemento. Para ser honesto, non o fan, xa que o uso de microservizos non está asociado a un aumento dos indicadores de eficiencia. Os microservizos son utilizados tanto por equipos de perfil alto como baixo.

Pero o significativo é que para High-teams, a transición a unha arquitectura de microservizos permítelles desenvolver de forma independente os seus servizos e implementalos. Se a arquitectura permite aos desenvolvedores actuar de forma autónoma, sen esperar a alguén externo ao equipo, entón esta é unha competencia clave para aumentar a velocidade. Aquí é onde axudan os microservizos. Pero simplemente a súa implementación non xoga un papel importante.

Como descubrimos todo isto?

Tiñamos un plan ambicioso para replicar completamente a metodoloxía DORA, pero carecíamos dos recursos. Se DORA utiliza moito patrocinio e o estudo leva seis meses, realizamos o noso estudo en pouco tempo. Queriamos construír un modelo DevOps como fai DORA, e farémolo no futuro. Polo momento limitámonos a mapas de calor:

Analizamos a distribución das prácticas de enxeñería entre os equipos de cada perfil e descubrimos que os equipos de alto perfil, de media, usan prácticas de enxeñería con máis frecuencia. Podes ler máis sobre todo isto no noso informe.

Para cambiar, imos cambiar de estatísticas complexas a outras simples.

Que máis descubrimos?

Ferramentas

Observamos que a familia de sistemas operativos Linux usa máis comandos. Pero Windows aínda está en tendencia: polo menos unha cuarta parte dos nosos enquisados ​​sinalaron o uso dunha ou outra versión del. O mercado parece ter esta necesidade. Polo tanto, pode desenvolver estas competencias e realizar presentacións en congresos.

Entre os orquestadores, non é ningún segredo que Kubernetes lidera (52%). O seguinte orquestrador na fila é Docker Swarm (un 12%). Os sistemas CI máis populares son Jenkins e GitLab. O sistema de xestión de configuración máis popular é Ansible, seguido do noso querido Shell.

Entre os provedores de hospedaxe na nube, Amazon ocupa actualmente a posición de liderado. A proporción de nubes rusas está aumentando gradualmente. O próximo ano será interesante ver como se sentirán os provedores de nube rusos e se aumentará a súa cota de mercado. Existen, pódense usar, e iso é bo:

Dou a palabra a Igor, que dará máis estatísticas.

Difusión de prácticas

Igor Kurochkin: Por separado, pedimos aos entrevistados que indicasen como se distribúen na empresa as prácticas de enxeñería consideradas. A maioría das empresas teñen un enfoque mixto que consiste nun conxunto diferente de patróns e os proxectos piloto son moi populares. Tamén vimos unha lixeira diferenza entre os perfís. Os representantes do alto perfil usan con máis frecuencia o patrón "Iniciativa desde abaixo", cando pequenos equipos de especialistas cambian os procesos de traballo, as ferramentas e comparten desenvolvementos exitosos con outros equipos. En Medium, trátase dunha iniciativa top-down que afecta a toda a empresa a través da creación de comunidades e centros de excelencia:

Agile e DevOps

A relación entre Agile e DevOps adoita discutirse na industria. Esta cuestión tamén aparece no Informe sobre o estado de Agile para 2019/2020, polo que decidimos comparar como se relacionan as actividades Agile e DevOps nas empresas. Descubrimos que DevOps sen Agile é raro. Para a metade dos enquisados, a propagación de Agile comezou notablemente antes e preto do 20% observou un inicio simultáneo, e un dos signos dun perfil baixo será a ausencia de prácticas Agile e DevOps:

Topoloxías de equipo

A finais do ano pasado o libro “Topoloxías de equipo", que propón un marco para describir topoloxías de equipo. Preguntámonos se se aplicaría ás empresas rusas. E fixemos a pregunta: "Que patróns ves?"

Obsérvanse equipos de infraestrutura na metade dos entrevistados, así como equipos de desenvolvemento, probas e operacións separados. Os equipos individuais de DevOps observaron un 45%, entre os que os altos representantes son máis comúns. A continuación veñen os equipos multifuncionais, que tamén son máis habituais en High. Os comandos SRE separados aparecen nos perfís alto e medio e raramente se atopan no perfil baixo:

Relación DevQaOps

Vimos esta pregunta en FaceBook do xefe do equipo da plataforma Skyeng: estaba interesado na proporción de desenvolvedores, probadores e administradores das empresas. Preguntámolo e analizamos as respostas tendo en conta os perfís: os representantes do perfil alto teñen un número menor de enxeñeiros de probas e operacións para cada desenvolvedor:

Plans para o ano 2021

Nos seus plans para o próximo ano, os entrevistados sinalaron as seguintes actividades:

Aquí podes ver a intersección coa conferencia DevOps Live 2020. Revisamos coidadosamente o programa:

• Infraestrutura como produto
• Transformación DevOps
• Distribución de prácticas de DevOps
• DevSecOps
• Clubs de casos e debates

Pero a nosa charla non terá tempo suficiente para tratar todos os temas. Detrás das cámaras:

• Plataforma como servizo e como produto;
• Infraestrutura como código, ambientes e nubes;
• Integración e entrega continuas;
• Arquitectura;
• Patróns DevSecOps;
• Plataforma e equipos interfuncionais.

Informe O noso é voluminoso, ten 50 páxinas, e podedes miralo con máis detalle.

Resumindo

Agardamos que a nosa investigación e informe o inspiren a experimentar con novos enfoques para o desenvolvemento, as probas e as operacións, así como que che axuden a orientarte, compararte cos demais participantes no estudo e identificar áreas nas que podes mellorar os teus propios enfoques. .

Resultados do primeiro estudo do estado de DevOps en Rusia:

• Métricas clave. Descubrimos que as métricas clave (tempo de entrega, taxa de implantación, tempo de recuperación e fallos de cambio) son adecuadas para analizar a eficacia dos procesos de desenvolvemento, probas e operacións.
• Perfís Alto, Medio, Baixo. A partir dos datos recollidos, é posible identificar estatisticamente diferentes grupos: Alto, Medio, Baixo, con características distintivas en función de métricas, prácticas, procesos e ferramentas. Os representantes do perfil Alto mostran mellores resultados que os de Baixo. Son máis propensos a acadar e superar os seus obxectivos.
• Indicadores, pandemia e plans para 2021. Un indicador especial deste ano é como as empresas afrontaron a pandemia. High desempeñou mellor, experimentou un aumento da actividade dos usuarios e as principais razóns do éxito foron procesos de desenvolvemento eficientes e unha forte cultura de enxeñería.
• Prácticas, ferramentas e desenvolvemento de DevOps. Os principais plans das empresas para o próximo ano inclúen o desenvolvemento de prácticas e ferramentas DevOps, a introdución de prácticas DevSecOps e cambios na estrutura organizativa. E a implantación e desenvolvemento efectivos das prácticas DevOps realízase mediante proxectos piloto, formación de comunidades e centros de competencias, iniciativas nos niveis superiores e inferiores da empresa.

Estaremos encantados de escoitar os teus comentarios, historias e comentarios. Agradecemos a todos os que participaron no estudo e esperamos a vosa participación o próximo ano.

Fonte: www.habr.com