Estado do DevOps na Rússia 2020

Como você entende o estado de alguma coisa?

Você pode confiar na sua opinião, formada a partir de diversas fontes de informação, por exemplo, publicações em sites ou experiência. Você pode perguntar a seus colegas e amigos. Outra opção é olhar os temas das conferências: o comitê do programa é formado por representantes ativos da indústria, por isso confiamos neles na escolha dos temas relevantes. Uma área separada é pesquisa e relatórios. Mas há um problema. Pesquisas sobre o estado do DevOps são realizadas anualmente em todo o mundo, relatórios são publicados por empresas estrangeiras e quase não há informações sobre o DevOps russo.

Mas chegou o dia em que tal estudo foi realizado e hoje contaremos a vocês os resultados obtidos. O estado do DevOps na Rússia foi estudado em conjunto pelas empresas "Expresso 42"E"Ontico" A empresa Express 42 ajuda empresas de tecnologia a implementar e desenvolver práticas e ferramentas DevOps e foi uma das primeiras a falar sobre DevOps na Rússia. Os autores do estudo, Igor Kurochkin e Vitaly Khabarov, atuam em análise e consultoria na Express 42, possuindo formação técnica de operação e experiência em diversas empresas. Ao longo de 8 anos, colegas analisaram dezenas de empresas e projetos – desde startups a empreendimentos – com diferentes problemas, bem como diferentes maturidades culturais e de engenharia.

Em seu relatório, Igor e Vitaly explicaram quais problemas surgiram durante o processo de pesquisa, como os resolveram, bem como como a pesquisa DevOps é conduzida em princípio e por que o Express 42 decidiu conduzir a sua própria. Você pode ver o relatório deles aqui.

Pesquisa DevOps

Igor Kurochkin iniciou a conversa.

Perguntamos regularmente ao público em conferências de DevOps: “Você leu o relatório State of DevOps deste ano?” Apenas alguns levantam a mão, mas a nossa investigação mostrou que apenas um terço os estuda. Se você nunca viu esses relatórios, digamos imediatamente que são todos muito semelhantes. Na maioria das vezes há frases como: “Em comparação com o ano passado...”

Aqui temos nosso primeiro problema, seguido por mais dois:

1. Não temos dados do ano passado. Ninguém está interessado no estado do DevOps na Rússia;
2. Metodologia. Não está claro como testar hipóteses, como construir questões, como conduzir análises, comparar resultados, encontrar conexões;
3. Terminologia. Todos os relatórios estão em inglês, é necessária tradução, uma estrutura comum para DevOps ainda não foi inventada e cada um cria a sua própria.

Vejamos como as análises do estado do DevOps no mundo foram geralmente realizadas.

Informação histórica

A pesquisa DevOps é conduzida desde 2011. O primeiro a conduzi-los foi o Puppet, desenvolvedor de sistemas de gerenciamento de configuração. Naquela época, era uma das principais ferramentas para descrever infraestrutura em forma de código. Até 2013, estes estudos eram simplesmente inquéritos em formato fechado e sem divulgação pública.

Em 2013 surgiu a IT Revolution, editora de todos os principais livros sobre DevOps. Juntamente com o Puppet, prepararam a primeira publicação “State of DevOps”, onde apareceram pela primeira vez 4 métricas principais. No ano seguinte, a empresa de consultoria ThoughtWorks, conhecida por seus radares tecnológicos regulares sobre práticas e ferramentas do setor, se envolveu. E em 2015 foi acrescentada uma seção com metodologia, e ficou claro como eles realizam a análise.

Em 2016, os autores do estudo, tendo criado a sua empresa DORA (DevOps Research and Assessment), publicaram um relatório anual. No ano seguinte, DORA e Puppet publicaram o seu relatório final conjunto.

E então as coisas ficaram interessantes:

Em 2018, as empresas se separaram e foram divulgados dois relatórios independentes: um da Puppet, o segundo da DORA em colaboração com o Google. A DORA continuou a utilizar a sua metodologia com métricas-chave, perfis de desempenho e práticas de engenharia que impactam as principais métricas e desempenho em toda a empresa. E o Puppet propôs sua abordagem com uma descrição do processo e da evolução do DevOps. Mas a história não pegou: em 2019, a Puppet abandonou essa metodologia e lançou uma nova versão dos relatórios, na qual listava as principais práticas e como elas afetam o DevOps do seu ponto de vista. Aí aconteceu outra coisa: o Google comprou a DORA e juntos divulgaram outro relatório. Talvez você tenha visto isso.

Este ano as coisas ficaram complicadas. Sabe-se que o Puppet lançou sua pesquisa. Eles fizeram isso uma semana antes de nós e já estava concluído. Participamos e vimos quais temas os interessavam. O Puppet está agora realizando sua análise e se preparando para publicar o relatório.

Mas ainda não há nenhum anúncio da DORA e do Google. Em maio, quando normalmente começava a pesquisa, chegou a informação de que Nicole Forsgren, uma das fundadoras da DORA, havia se mudado para outra empresa. Portanto, presumimos que não haveria nenhuma pesquisa ou relatório da DORA este ano.

Como estão as coisas na Rússia?

Não conduzimos nenhuma pesquisa sobre DevOps. Conversamos em conferências, recontando as conclusões de outras pessoas, e o Raiffeisenbank traduziu o “Estado do DevOps” para 2019 (você pode encontrar o anúncio no Habré), muito obrigado a eles. E é tudo.

Portanto, conduzimos a nossa própria investigação na Rússia utilizando metodologias e resultados DORA. Usamos o relatório de colegas do Raiffeisenbank para nossa pesquisa, inclusive para sincronizar a terminologia e a tradução. E as questões relevantes para a indústria foram retiradas dos relatórios DORA e do questionário Puppet deste ano.

Processo de pesquisa

O relatório é apenas a parte final. Todo o processo de pesquisa consiste em quatro grandes etapas:

Durante a fase de preparação, entrevistamos especialistas do setor e preparamos uma lista de hipóteses. Com base neles, compilamos perguntas e lançamos uma pesquisa para todo o mês de agosto. Depois analisamos e preparamos o próprio relatório. Para DORA, esse processo leva 6 meses. Concluímos em 3 meses e agora entendemos que mal tivemos tempo: só fazendo a análise você entende quais perguntas precisam ser feitas.

Участники

Todas as reportagens estrangeiras começam com um retrato dos participantes, e a maioria deles não é da Rússia. A percentagem de entrevistados russos varia de 5 a 1% de ano para ano, o que não nos permite tirar quaisquer conclusões.

Mapa do relatório Accelerate State of DevOps 2019:

No nosso estudo, conseguimos entrevistar 889 pessoas - isto é bastante (a DORA entrevista cerca de mil pessoas anualmente nos seus relatórios) e aqui atingimos o nosso objetivo:

É verdade que nem todos os nossos participantes chegaram ao fim: o percentual de conclusão foi um pouco menos da metade. Mas isso foi suficiente para obter uma amostra representativa e realizar análises. A DORA não divulga as taxas de ocupação nos seus relatórios, pelo que não podem ser feitas aqui comparações.

Indústrias e posições

Nossos entrevistados representam uma dúzia de setores. Metade trabalha em tecnologia da informação. Seguem-se os serviços financeiros, comércio, telecomunicações e outros. Entre os cargos estão especialistas (desenvolvedor, testador, engenheiro de operação) e pessoal de gestão (líderes de equipes, grupos, áreas, diretores):

Cada segunda pessoa trabalha em uma empresa de médio porte. Cada terceira pessoa trabalha em grandes empresas. A maioria trabalha em equipes de até 9 pessoas. Separadamente, perguntamos sobre as principais atividades, sendo que a maioria está de uma forma ou de outra relacionada à operação, e cerca de 40% estão envolvidas no desenvolvimento:

Foi assim que coletamos informações para comparação e análise de representantes de diferentes setores, empresas e equipes. Meu colega Vitaly Khabarov falará sobre a análise.

Análise e comparação

Vitaly Khabarov: Muito obrigado a todos os participantes que completaram nossa pesquisa, preencheram questionários e nos forneceram dados para análise e teste adicionais de nossas hipóteses. E graças aos nossos clientes e clientes, temos uma vasta experiência que nos ajudou a identificar questões que preocupam a indústria e a formular as hipóteses que testamos em nossa pesquisa.

Infelizmente, você não pode simplesmente pegar uma lista de perguntas por um lado e dados por outro, compará-los de alguma forma, dizer: “Sim, tudo funciona assim, estávamos certos” e seguir caminhos separados. Não, precisamos de metodologia e de métodos estatísticos para ter a certeza de que não nos enganamos e de que as nossas conclusões são fiáveis. Então podemos construir nosso trabalho futuro com base nestes dados:

Métricas principais

Tomamos como base a metodologia DORA, que eles descreveram detalhadamente no livro “Accelerate State of DevOps”. Verificámos se as principais métricas são adequadas para o mercado russo, se podem ser utilizadas da mesma forma que a DORA utiliza para responder à pergunta: “Como é que a indústria na Rússia corresponde à indústria estrangeira?”

Métricas principais:

1. Frequência de implantação. Com que frequência uma nova versão de um aplicativo é implantada no ambiente de produção (alterações planejadas, excluindo hotfixes e resposta a incidentes)?
2. Prazo de entrega. Qual é o tempo médio entre a confirmação de uma alteração (gravação de funcionalidade como código) e a implantação da alteração no ambiente de produção?
3. Tempo de recuperação. Quanto tempo leva, em média, para restaurar um aplicativo em um ambiente de produção após um incidente, degradação de serviço ou detecção de um erro que afeta os usuários do aplicativo?
4. Mudanças sem sucesso. Qual porcentagem de implantações em um ambiente de produto leva à degradação ou incidentes de aplicativos e exige a eliminação de consequências (reversão de alterações, desenvolvimento de hotfix ou patch)?

A pesquisa da DORA encontrou uma ligação entre estas métricas e o desempenho organizacional. Também verificamos isso em nosso estudo.

Mas para ter certeza de que as quatro métricas principais podem influenciar alguma coisa, você precisa entender: elas estão de alguma forma relacionadas entre si? DORA respondeu que sim, com uma ressalva: a relação entre a Taxa de Falha na Mudança e as outras três métricas é um pouco mais fraca. Temos quase a mesma imagem. Se o tempo de entrega, a frequência de implantação e o tempo de recuperação estiverem correlacionados (estabelecemos essa correlação por meio da correlação de Pearson e da escala de Chaddock), então não existe uma correlação tão forte com alterações malsucedidas.

Em princípio, a maioria dos entrevistados tende a responder que há um número bastante pequeno de incidentes ocorrendo na produção. Embora veremos mais tarde que ainda existe uma diferença significativa entre grupos de entrevistados na taxa de mudanças malsucedidas, ainda não podemos usar esta métrica para esta divisão.

Atribuímos isto ao facto de (como se verificou no processo de análise e comunicação com alguns dos nossos clientes) existir uma ligeira diferença na percepção do que é considerado um incidente. Se conseguimos restaurar a funcionalidade do nosso serviço durante a janela técnica, isso pode ser considerado um incidente? Provavelmente não, porque consertamos tudo, estamos ótimos. Pode ser considerado um incidente se tivermos que rolar novamente nosso aplicativo 10 vezes no modo normal e familiar? Parece que não. Portanto, a questão da relação entre mudanças malsucedidas e outras métricas permanece em aberto. Iremos esclarecer melhor.

O importante aqui é que encontramos uma correlação significativa entre o tempo de entrega, o tempo de recuperação e a frequência de implantação. Portanto, utilizamos essas três métricas para dividir ainda mais os entrevistados em grupos com base na produtividade.

Quanto pendurar em gramas?

Usamos análise de cluster hierárquica:

• Distribuímos os respondentes pelo espaço n-dimensional, onde a coordenada de cada respondente são suas respostas às perguntas.
• Declaramos que cada respondente é um pequeno cluster.
• Combinamos os dois clusters mais próximos um do outro em um cluster maior.
• Encontramos o próximo par de clusters e os combinamos em um cluster maior.

É assim que agrupamos todos os nossos entrevistados no número de clusters que precisamos. Usando um dendograma (uma árvore de conexões entre clusters) vemos a distância entre dois clusters vizinhos. Tudo o que nos resta é estabelecer um certo limite para a distância entre estes aglomerados e dizer: “Estes dois grupos são bastante distinguíveis um do outro porque a distância entre eles é gigantesca”.

Mas há um problema oculto aqui: não temos restrições quanto ao número de clusters - podemos obter 2, 3, 4, 10 clusters. E a primeira ideia foi: porque não dividir todos os nossos entrevistados em 4 grupos, como faz a DORA. Mas descobrimos que as diferenças entre estes grupos tornam-se insignificantes e não podemos ter a certeza de que o entrevistado realmente pertence ao seu grupo e não ao grupo vizinho. Ainda não podemos dividir o mercado russo em quatro grupos. Portanto, optamos por três perfis, entre os quais existe uma diferença estatisticamente significativa:

A seguir, determinamos o perfil por cluster: pegamos as medianas de cada métrica de cada grupo e compilamos uma tabela de perfis de eficiência. Na verdade, foram obtidos os perfis de desempenho resultantes para o participante médio de cada grupo. Identificamos três perfis de eficiência: Baixo, Médio, Alto:

Aqui confirmamos a nossa hipótese de que quatro métricas principais são adequadas para determinar o perfil de desempenho e funcionam tanto no mercado ocidental como no russo. Há uma diferença entre os grupos e é estatisticamente significativa. Gostaria de enfatizar que há uma diferença significativa na média entre os perfis de desempenho para a métrica de mudanças malsucedidas, embora inicialmente não tenhamos dividido os respondentes por esse parâmetro.

Aí surge a pergunta: como usar tudo isso?

Como usar

Se pegarmos qualquer equipe, 4 métricas principais e aplicá-las à mesa, então em 85% dos casos não obteremos uma correspondência completa - este é apenas o participante médio, e não o que é na realidade. Somos todos (e cada equipe) um pouco diferentes.

Verificamos: pegamos nossos entrevistados e o perfil de desempenho da DORA e verificamos quantos entrevistados correspondiam a um ou outro perfil. Descobrimos que apenas 16% dos entrevistados se enquadraram com precisão em um dos perfis. Todo o resto está espalhado em algum lugar entre:

Isto significa que o perfil de desempenho tem um alcance limitado. Para obter uma primeira aproximação de onde você está, você pode usar esta tabela: “Ah, parece que estamos mais perto de Médio ou Alto!” Se você entender para onde vai a seguir, isso pode ser suficiente. Mas se o seu objetivo é a melhoria constante e contínua e você deseja saber com mais precisão onde desenvolver e o que fazer, serão necessários fundos adicionais. Nós os chamamos de calculadoras:

• Calculadora DORA
• Calculadora Express 42* (em desenvolvimento)
• Seu próprio desenvolvimento (você pode criar sua própria calculadora interna).

Para que eles são necessários? Para entender:

• A equipe de nossa organização atende aos nossos padrões?
• Caso contrário, podemos ajudá-la - agilizar isso dentro da expertise que nossa empresa possui?
• Se sim, podemos fazer ainda melhor?

Você também pode usá-los para coletar estatísticas dentro da empresa:

• Que tipo de equipes temos?
• Divida as equipes em perfis;
• Veja: Ah, esses times estão com baixo desempenho (um pouco lentos), mas são ótimos: eles implantam todos os dias, sem erros, seu lead time é de menos de uma hora.

E então você poderá descobrir que dentro de nossa empresa temos o conhecimento e as ferramentas necessárias para aquelas equipes que ainda estão aquém.

Ou, se você entende que se sente bem dentro da empresa, que é melhor que muitos, então pode olhar de forma um pouco mais ampla. Esta é precisamente a indústria russa: conseguiremos obter a experiência necessária na indústria russa para nos acelerarmos? A calculadora Express 42 vai ajudar aqui (está em desenvolvimento). Se você superou o mercado russo, dê uma olhada Calculadora DORA e para o mercado mundial.

Multar. E se você está no grupo Elit de acordo com a calculadora DORA, o que deve fazer? Não há uma boa solução aqui. Muito provavelmente, você está na vanguarda do setor e novas melhorias de aceleração e confiabilidade são possíveis por meio de pesquisa e desenvolvimento interno e do gasto de grandes recursos.

Vamos para a parte mais fofa: a comparação.

Comparação

Inicialmente queríamos comparar a indústria russa com a indústria ocidental. Se compararmos diretamente, vemos que temos menos perfis, e eles estão um pouco mais confusos entre si, os limites ficam um pouco mais confusos:

Nossos artistas de elite estão escondidos entre os de alto desempenho, mas eles estão lá - são a elite, os unicórnios que alcançaram níveis significativos. Na Rússia, a diferença entre os perfis Elite e Alto ainda não é suficientemente significativa. Acreditamos que no futuro esta divisão ocorrerá devido ao aumento da cultura de engenharia, da qualidade de implementação das práticas de engenharia e da expertise dentro das empresas.

Se passarmos à comparação direta dentro da indústria russa, veremos que as equipes de alto perfil são melhores em todos os aspectos. Também confirmamos a nossa hipótese de que existe uma ligação entre estas métricas e a eficácia organizacional: as equipas de alto perfil têm uma probabilidade significativamente maior não só de atingir metas, mas também de as superar.
Vamos nos tornar equipes de alto perfil e não parar por aí:

Mas este ano é especial e decidimos verificar como as empresas estão a viver uma pandemia: Equipas de alto nível lidam significativamente melhor e sentem-se melhor do que a média da indústria:

• Novos produtos foram lançados 1,5 a 2 vezes mais frequentemente,
• Maior confiabilidade e/ou desempenho da infraestrutura de aplicativos com frequência 2 vezes maior.

Ou seja, as competências que já possuíam ajudaram-nos a desenvolver-se mais rapidamente, a introduzir novos produtos, a modificar produtos existentes, conquistando assim novos mercados e novos utilizadores:

O que mais ajudou nossas equipes?

Práticas de engenharia

Vou falar sobre descobertas significativas para cada prática que verificamos. Talvez algo mais tenha ajudado as equipes, mas estamos falando de DevOps. E dentro do DevOps, vemos diferenças entre equipes de perfis diferentes.

Plataforma como serviço

Não encontramos uma relação significativa entre a idade da plataforma e o perfil da equipe: as plataformas apareceram aproximadamente ao mesmo tempo para as equipes Baixa e Alta. Mas para este último, a plataforma oferece, em média, mais serviços e mais interfaces de software para controle através de código de programa. E as equipes de plataforma são mais propensas a ajudar seus desenvolvedores e equipes a usar a plataforma, mais propensas a resolver seus problemas e incidentes relacionados à plataforma e a treinar outras equipes.

Infraestrutura como código

Tudo aqui é bastante normal. Encontramos uma relação entre a automação do código da infraestrutura e a quantidade de informações armazenadas no repositório da infraestrutura. Equipes de alto perfil armazenam mais informações em repositórios: isso inclui configuração de infraestrutura, pipeline de CI/CD, configurações de ambiente e parâmetros de construção. Eles armazenam essas informações com mais frequência, trabalham melhor com código de infraestrutura e automatizam mais processos e tarefas para trabalhar com código de infraestrutura.

Curiosamente, não vimos uma diferença significativa nos testes de infraestrutura. Atribuo isso ao fato de que equipes de alto perfil geralmente possuem mais automação de testes. Talvez eles não devam se distrair separadamente com testes de infraestrutura, mas sim os testes que usam para verificar as aplicações são suficientes e, graças a eles, podem ver o que e onde quebraram.

Integração e Entrega

A seção mais chata, porque confirmamos: quanto mais automação você tiver, melhor você trabalha com o código, maior a probabilidade de obter melhores resultados.

Arquitetura

Queríamos ver como os microsserviços impactam o desempenho. Para ser sincero, não, pois a utilização de microsserviços não está associada ao aumento dos indicadores de eficiência. Os microsserviços são usados ​​por equipes de alto e baixo perfil.

Mas o que é significativo é que, para as equipes de alto nível, a transição para uma arquitetura de microsserviços permite que desenvolvam e implementem seus serviços de forma independente. Se a arquitetura permite que os desenvolvedores atuem de forma autônoma, sem esperar por alguém externo à equipe, então esta é uma competência fundamental para aumentar a velocidade. É aqui que os microsserviços ajudam. Mas simplesmente a sua implementação não desempenha um grande papel.

Como descobrimos tudo isso?

Tínhamos um plano ambicioso para replicar integralmente a metodologia DORA, mas faltou-nos os recursos. Se a DORA usa muito patrocínio e o estudo leva seis meses, conduzimos nosso estudo em pouco tempo. Queríamos construir um modelo DevOps como o DORA faz, e faremos isso no futuro. Por enquanto nos limitamos aos mapas de calor:

Observamos a distribuição das práticas de engenharia entre as equipes de cada perfil e descobrimos que as equipes de perfil Alto, em média, utilizam as práticas de engenharia com mais frequência. Você pode ler mais sobre tudo isso em nosso relatório.

Para variar, vamos mudar de estatísticas complexas para estatísticas simples.

O que mais descobrimos?

Ferramentas

Observamos que a família Linux OS é a que mais utiliza comandos. Mas o Windows ainda está em tendência - pelo menos um quarto dos nossos entrevistados notaram o uso de uma ou outra versão dele. O mercado parece ter essa necessidade. Portanto, você poderá desenvolver essas competências e fazer apresentações em conferências.

Entre os orquestradores, não é segredo que o Kubernetes lidera (52%). O próximo orquestrador da fila é o Docker Swarm (cerca de 12%). Os sistemas de CI mais populares são Jenkins e GitLab. O sistema de gerenciamento de configuração mais popular é o Ansible, seguido pelo nosso querido Shell.

Entre os provedores de hospedagem em nuvem, a Amazon ocupa atualmente a posição de liderança. A participação das nuvens russas está aumentando gradualmente. No próximo ano será interessante ver como os fornecedores de nuvem russos se sentirão e se a sua quota de mercado aumentará. Eles existem, podem ser usados, e isso é bom:

Passo a palavra ao Igor, que dará mais algumas estatísticas.

Difusão de práticas

Igor Kurochkin: Separadamente, pedimos aos entrevistados que indicassem como as práticas de engenharia consideradas estão distribuídas na empresa. A maioria das empresas tem uma abordagem mista que consiste num conjunto diferente de padrões, e os projetos-piloto são muito populares. Também vimos uma ligeira diferença entre os perfis. Representantes de alto perfil usam com mais frequência o padrão “Iniciativa de baixo para cima”, quando pequenas equipes de especialistas mudam processos de trabalho, ferramentas e compartilham desenvolvimentos bem-sucedidos com outras equipes. Na Medium, esta é uma iniciativa de cima para baixo que atinge toda a empresa através da criação de comunidades e centros de excelência:

Ágil e DevOps

A relação entre Agile e DevOps é frequentemente discutida na indústria. Esta questão também é levantada no Relatório sobre o Estado do Agile 2019/2020, por isso decidimos comparar como as atividades Agile e DevOps nas empresas estão relacionadas. Descobrimos que DevOps sem Agile é raro. Para metade dos entrevistados, a disseminação do Agile começou visivelmente mais cedo, e cerca de 20% observaram um início simultâneo, e um dos sinais de um perfil Baixo será a ausência de práticas Agile e DevOps:

Topologias de equipe

No final do ano passado o livro “Topologias de equipe", que propõe uma estrutura para descrever topologias de equipe. Perguntámo-nos se isso se aplicaria às empresas russas. E fizemos a pergunta: “Que padrões você vê?”

Metade dos entrevistados possui equipes de infraestrutura, assim como equipes separadas de desenvolvimento, testes e operações. As equipes individuais de DevOps registraram 45%, entre as quais os representantes de alto nível são mais comuns. Em seguida vêm as equipes multifuncionais, que também são mais comuns no High. Comandos SRE separados aparecem nos perfis Alto e Médio e raramente são encontrados no perfil Baixo:

Taxa de DevQaOps

Vimos essa pergunta no Facebook do líder da equipe da plataforma Skyeng - ele estava interessado na proporção de desenvolvedores, testadores e administradores nas empresas. Perguntamos e analisamos as respostas levando em consideração os perfis: representantes do perfil Alto possuem um número menor de engenheiros de testes e operações para cada desenvolvedor:

Planos para o ano 2021

Nos seus planos para o próximo ano, os entrevistados apontaram as seguintes atividades:

Aqui você pode ver a interseção com a conferência DevOps Live 2020. Revisamos cuidadosamente o programa:

• Infraestrutura como produto
• Transformação DevOps
• Distribuição de práticas DevOps
• DevSecOps
• Clubes de casos e discussões

Mas nossa palestra não terá tempo suficiente para cobrir todos os tópicos. Por trás das cenas:

• Plataforma como serviço e como produto;
• Infraestrutura como código, ambientes e nuvens;
• Integração e entrega contínuas;
• Arquitetura;
• Padrões DevSecOps;
• Equipes de plataforma e multifuncionais.

Relatório O nosso é volumoso, tem 50 páginas e você pode vê-lo com mais detalhes.

Resumindo

Esperamos que nossa pesquisa e relatório inspirem você a experimentar novas abordagens de desenvolvimento, testes e operações, bem como ajudem você a se orientar, comparar-se com outros participantes do estudo e identificar áreas onde você pode melhorar suas próprias abordagens. .

Resultados do primeiro estudo sobre o estado do DevOps na Rússia:

• Métricas principais. Descobrimos que as principais métricas (tempo de entrega, taxa de implantação, tempo de recuperação e falhas nas alterações) são adequadas para analisar a eficácia dos processos de desenvolvimento, testes e operações.
• Perfis Alto, Médio, Baixo. Com base nos dados coletados é possível identificar grupos estatisticamente distintos: Alto, Médio, Baixo, com características distintivas baseadas em métricas, práticas, processos e ferramentas. Representantes de alto perfil apresentam melhores resultados do que baixos. Eles têm maior probabilidade de atingir e superar seus objetivos.
• Indicadores, pandemia e planos para 2021. Um indicador especial este ano é a forma como as empresas lidaram com a pandemia. A High teve melhor desempenho, experimentou um aumento na atividade dos usuários e os principais motivos do sucesso foram processos de desenvolvimento eficientes e uma forte cultura de engenharia.
• Práticas DevOps, ferramentas e seu desenvolvimento. Os principais planos das empresas para o próximo ano incluem o desenvolvimento de práticas e ferramentas DevOps, a introdução de práticas DevSecOps e mudanças na estrutura organizacional. E a efetiva implementação e desenvolvimento de práticas DevOps é realizada por meio de projetos piloto, formação de comunidades e centros de competência, iniciativas nos níveis superiores e inferiores da empresa.

Teremos o maior prazer em ouvir seus comentários, histórias e comentários. Agradecemos a todos que participaram do estudo e aguardamos sua participação no próximo ano.

Fonte: habr.com