Como Utilizar Métricas de DevOps para Escalar o Seu Negócio

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Criei uma visão geral das métricas de DevOps para garantir que compreende o que deve medir e porquê, que consegue definir KPIs de desempenho relevantes e que sabe como utilizá-los para escalar o seu negócio de forma eficaz.

Scale your business with DevOps metrics

Enquanto líder tecnológico ou proprietário de uma empresa, compreende que manter-se à frente da concorrência exige mais do que apenas ambição — exige uma tomada de decisões baseada em dados. É aí que entram as ferramentas DevOps.

Com apenas alguns dados, pode melhorar o desempenho da equipa, a eficiência dos processos e a satisfação dos clientes.

Isso não significa que seja fácil. A implementação de DevOps tem os seus desafios. Exige uma mentalidade estratégica, uma cultura colaborativa e um compromisso com a melhoria contínua. No entanto, os resultados são fluxos de trabalho e processos otimizados, sobre os quais pode construir uma base sólida para expandir a sua empresa.

Este artigo irá explorar as principais métricas de DevOps e a forma de as medir para definir KPIs de desempenho relevantes. Em seguida, iremos descobrir como utilizar estas métricas para expandir a sua empresa de forma eficaz.

Os 5 pilares da maturidade dos processos

O DevOps combina e automatiza processos, práticas e ferramentas utilizados no desenvolvimento e nas operações de software para aumentar a qualidade e a velocidade dos ciclos de vida do desenvolvimento.

A implementação de processos empresariais tem cinco pilares fundamentais, conhecidos como Modelo de Maturidade das Capacidades (CMM). Este modelo centra-se em cinco níveis de maturidade para a implementação e melhoria contínua do desenvolvimento de serviços ou produtos no seu modelo empresarial.

Os cinco pilares têm muitas variações, mas inicial, repetível, definido, capaz e eficiente são as etapas originais. Uma alternativa é cultura, automação, medição, partilha e retorno. Cada etapa tem o mesmo conceito; apenas os seus nomes evoluíram.

Eis um exemplo dos cinco pilares da maturidade dos processos, com breves descrições de cada um:

Um modelo que mostra o que acontece em cada etapa da maturidade em DevOps
Cinco etapas do modelo de maturidade.

Existem várias métricas e estruturas que podem ser utilizadas para implementar e medir o sucesso do DevOps na sua equipa. Vamos explorá-las nesta secção.

Estruturas de DevOps baseadas em princípios

Existem três estruturas principais baseadas em princípios no DevOps. Baseado em princípios refere-se a uma abordagem prática com orientações amplas, em oposição a uma abordagem baseada em regras, com etapas prescritivas.

A estrutura Acelerar

Os autores Dr. Nicole Forsgren, Jez Humble e Gene Kim exploram o que distingue as empresas tecnológicas de elevado desempenho no seu livro, ‘Acelerar: A ciência do software enxuto e do DevOps: construir e expandir organizações tecnológicas de elevado desempenho’.

Foi neste livro que teve origem a estrutura DevOps Acelerar, que se centra nas práticas técnicas e de gestão das equipas DevOps de organizações tecnológicas de elevado desempenho. Pode considerá-la um estudo das melhores práticas de uma equipa DevOps.

As três principais áreas de enfoque nas práticas técnicas são:

  • Entrega contínua: A entrega contínua inclui áreas como o controlo de versões, a integração contínua, a implementação e automatização de testes e a gestão de dados de teste. Embora a entrega contínua seja um princípio autónomo, é utilizada como um conceito abrangente na estrutura Acelerar. A razão por detrás desta abordagem é que as equipas DevOps de nível superior executam estes elementos em simultâneo, em vez de os executarem isoladamente.
  • Arquitetura: Verificou-se que as equipas DevOps de elevado desempenho realizam a maioria dos testes sem necessitarem de um ambiente integrado, implementam novas aplicações de forma independente das aplicações das quais dependem e dão prioridade aos testes e à capacidade de implementação em detrimento da tecnologia mais recente.
  • Produto e processo: O retorno dos clientes é procurado regularmente ao longo do desenvolvimento, trabalhando em pequenos lotes, fazendo experiências e otimizando continuamente os processos. Verificou-se que isto permite fornecer valor, corrigir erros rapidamente e criar um ciclo de retorno dos clientes.

Existem duas áreas principais de enfoque nas práticas de gestão. São elas:

  • Gestão Lean e monitorização: A estrutura Acelerar concluiu que processos de aprovação mínimos melhoram o desempenho da entrega de software em comparação com equipas que necessitam da aprovação de terceiros. A monitorização das capacidades com limites de trabalho em curso e ferramentas visuais de gestão de projetos também melhora o desempenho.
  • Cultura: A estrutura atribui grande importância à criação do ambiente de trabalho adequado para melhorar o desempenho de DevOps. A colaboração e a aprendizagem são dois ingredientes fundamentais para tal, juntamente com uma abordagem de trabalho em equipa baseada no apoio e no incentivo. Estas equipas devem ser apoiadas por uma liderança transformacional. As pessoas nesta posição tendem a ser motivadoras, intelectualmente estimulantes e a reconhecer as conquistas da sua equipa.

O «tempo de entrega das alterações» é uma métrica de DevOps que exploraremos com mais detalhe abaixo. Mede o tempo que uma alteração de código demora desde o momento em que é submetida por um programador até ser implementada com sucesso em produção. Ao aplicar esta métrica no âmbito do modelo Acelerar, pode medir e melhorar a velocidade e a eficiência do processo de entrega de software, conduzindo a implementações mais rápidas e fiáveis.

O modelo dos Três Princípios

Apresentado em O Projeto Fénix, da autoria de Gene Kim, Kevin Behr e George Spafford, e abordado em O Manual de DevOps, o modelo dos Três Princípios melhora o desempenho de DevOps ao centrar-se nos princípios do fluxo, do feedback e da aprendizagem contínua.

Setas que mostram como funciona cada um dos Três Princípios
O modelo dos Três Princípios para melhorar o desempenho de DevOps.

Eis uma visão geral do modelo dos Três Princípios:

  • Primeiro Princípio: Pensamento orientado para o fluxo:

O primeiro princípio consiste em alcançar um fluxo de trabalho ininterrupto desde o desenvolvimento até às operações e entregar valor aos clientes de forma rápida e fiável.

O «tempo de entrega para produção» é uma métrica que pode utilizar neste caso, medindo o tempo que uma alteração de código demora desde a submissão inicial até ser implementada no ambiente de produção e procurando reduzir esse tempo através da otimização do fluxo de entrega, da automatização de processos e da minimização das intervenções manuais.

  • Segundo Princípio: Reforçar os ciclos de feedback

O segundo princípio estabelece ciclos de feedback rápidos e eficazes ao longo de todo o processo de entrega de software, permitindo a aprendizagem contínua, a melhoria e a garantia da qualidade.

Ao utilizar a métrica «tempo médio de deteção (MTTD)», calcula o tempo médio necessário para detetar um problema ou uma anomalia depois de uma alteração de código ser implementada em produção. Procure reduzir o MTTD melhorando a monitorização, os sistemas de alertas e os ciclos de feedback, de modo a identificar e resolver rapidamente os problemas.

  • Terceiro Princípio: Cultura de experimentação e aprendizagem contínuas

O terceiro e último princípio promove uma cultura de aprendizagem contínua, experimentação e assunção de riscos para impulsionar a inovação, a adaptabilidade e o crescimento organizacional.

A métrica «taxa de falhas das alterações» é ideal para aplicar neste caso. Deve acompanhar a percentagem de alterações de código que resultam em falhas ou problemas após a implementação. Crie uma cultura de experimentação estabelecendo um ambiente seguro para testar, aprender com as falhas e melhorar continuamente os processos, de modo a reduzir a taxa de falhas das alterações.

O modelo CALMS

O modelo CALMS incorpora os princípios de cultura, automatização, metodologia Lean, medição e partilha. É uma opção ideal para as equipas que pretendem transitar para uma abordagem DevOps ao desenvolvimento de software e eliminar o trabalho isolado das equipas de desenvolvimento e operações.

Já ouviu falar do criador do modelo CALMS, uma vez que foi coautor de Acelerar e O Manual de DevOps, onde são detalhados, respetivamente, os modelos Acelerar e dos Três Princípios. Jez Humble criou o modelo CALMS como uma avaliação de adequação para determinar se as empresas estão preparadas e aptas para implementar processos DevOps.

À semelhança do CMM, mas especificamente para a administração de DevOps, pode utilizar o modelo CALMS para testar se a sua empresa está preparada.

Estes são os cinco pilares a seguir:

  • Cultura: As suas equipas de desenvolvimento e operações têm trabalhado dentro dos respetivos grupos, cada um com os seus próprios processos e estilos de comunicação. Deve promover um sentido de responsabilidade partilhada para garantir uma cultura preparada para DevOps.
  • Automatização: DevOps diz respeito à simplificação de processos, à rapidez e à eficiência. A chave? A automatização. As suas equipas devem preparar-se para automatizar tarefas e procedimentos manuais sempre que possível. Este passo apoiará a criação, os testes, a implementação e a monitorização contínuas das versões de software que compõem o ciclo de vida de DevOps.
  • Lean: Os princípios da metodologia Lean, uma abordagem de gestão empresarial e de projetos, são utilizados para minimizar o desperdício e otimizar os fluxos de valor. Deve manter as capacidades de trabalho realistas e visualizar o estado dos projetos para acelerar os processos.
  • Medição: A sua empresa poderá estar preparada para implementar DevOps se chegou até aqui e as suas equipas estiverem empenhadas em recolher e analisar dados para melhorar os processos.
  • Partilha: Além de uma cultura de responsabilidade partilhada, as suas equipas devem estar abertas e dispostas a partilhar dados e informações, garantindo que todos estão alinhados com os mesmos objetivos comuns e não estão em competição. Este ponto final da avaliação garante transferências de trabalho fluidas e um crescimento rápido.
Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

Desafios da implementação de DevOps

Um dos maiores desafios da implementação de DevOps é a resistência à mudança cultural. Existem duas equipas, cada uma com os seus próprios processos, ferramentas e estilos de comunicação. Transformá-las numa unidade coesa, com objetivos, responsabilidades e métricas partilhados, é uma transformação significativa. Manter o moral elevado e uma abordagem transparente em cada etapa do processo de implementação é vital para garantir que tudo decorra sem problemas. Também é necessário considerar o custo das novas ferramentas e métodos.

Se a sua equipa prefere seguir estruturas baseadas em regras, pode ser uma mudança considerável começar a trabalhar com estruturas baseadas em princípios. O ritmo é acelerado e estas estruturas evoluem frequentemente com a equipa, pelo que pode ser complexo para os trabalhadores que utilizam abordagens tradicionais há muitos anos, ou para os novos membros da equipa que têm de se adaptar a esta dinâmica.

Por fim, o fluxo contínuo de trabalho pode originar várias vulnerabilidades, com lançamentos de software implementados sem encriptação ou autenticação de dados e com transbordamentos de buffer. Isto pode colocar as equipas de DevOps em risco de violações de segurança, pelo que é essencial reforçar os processos neste âmbito enquanto a sua equipa de DevOps amadurece. É também por isso que a implementação não deve começar antes de utilizar a estrutura CALMS para avaliar se está preparado.

Porque são importantes as métricas de DevOps?

Como se constatou acima, os objetivos e as métricas partilhados podem ser um desafio para as equipas que implementam DevOps numa empresa. Sem métricas de DevOps, não haveria testes nem medições, e não haveria melhorias no desenvolvimento. Seriam apenas iterações do mesmo software baseadas em palpites e ideias, lançando-o para o desconhecido e tentando depois algo novo. Sem feedback ou métricas de sucesso do produto que permitam compreender o desempenho de algo, não há orientação.

Um gráfico circular de métricas de DevOps que mostra como um programador típico passa o seu tempo
Razões pelas quais precisa de métricas de DevOps.

Por exemplo, os departamentos financeiros querem manter os custos tão baixos quanto possível, enquanto os programadores querem manter o desempenho tão elevado quanto possível. Estes dois objetivos podem não estar alinhados, a menos que os riscos tenham sido avaliados e as equipas compreendam os objetivos umas das outras.

Embora os seus programadores possam optar por lançar um produto incompleto e lidar com isso mais tarde, o custo deste impacto dá origem a dívida técnica. A implementação de DevOps pode alinhar os objetivos e as estratégias de ambas as equipas, e pode ajudar os seus programadores a compreender o impacto financeiro das suas decisões técnicas.

Esta é apenas uma pequena parte de DevOps e da importância das métricas partilhadas.

Compreender as métricas de DevOps

Implementar DevOps e compreender as estruturas baseadas em princípios é uma coisa, mas é nas métricas de DevOps que começa realmente a ver os benefícios desta abordagem colaborativa ao ciclo de vida do desenvolvimento de software. Tal como acontece com a maioria das estratégias empresariais, existem inúmeras métricas que pode escolher medir para promover o crescimento, dependendo do seu setor, público e objetivos.

A equipa de Investigação e Avaliação de DevOps (DORA) da Google Cloud é a equipa de investigação em atividade há mais tempo do seu género. Inicialmente, identificou quatro métricas essenciais para medir o desempenho dos profissionais de elite em DevOps. No entanto, entretanto foi adicionada uma quinta métrica essencial e a sua análise de agrupamentos deteta apenas três níveis de equipas de DevOps: elevado, médio e baixo, sendo o nível de elite algo do passado.

As 4 principais métricas DORA

Eis uma análise mais detalhada das quatro métricas DORA:

1. Frequência de implementação (DF)

A DF mede a frequência com que faz lançamentos com êxito em produção. Esta métrica diz respeito à consistência e é um excelente indicador da conclusão de objetivos.

As equipas da categoria de elite implementariam consistentemente em produção várias vezes por dia, enquanto as equipas com baixo desempenho estariam mais próximas de uma vez a cada seis meses.

Melhorar a DF é tão simples como lançar várias atualizações pequenas. A principal vantagem de o fazer é destacar quaisquer impedimentos de processos, estrangulamentos ou projetos complexos que exijam atenção. As equipas maiores podem preferir implementar em intervalos regulares através da criação de comboios de lançamentos ágeis; isto ajudará a reduzir a sobrecarga causada por um ritmo extremo e por um elevado número de pessoas.

2. Tempo de execução das alterações (LTC)

A LTC refere-se ao tempo que uma alteração confirmada demora a chegar à produção. Esta métrica é um bom indicador da capacidade de resposta e agilidade da equipa, uma vez que mede a rapidez com que esta consegue responder às necessidades e exigências dos utilizadores.

O padrão ‘elite’ histórico teria como objetivo menos de um dia para o LTC, enquanto as equipas com pior desempenho poderiam demorar mais de seis meses. Um desempenho na extremidade inferior da escala para o LTC deve-se provavelmente a processos ineficientes.

Pode melhorar esta métrica melhorando os processos de automatização, especialmente os testes. Ao aperfeiçoar o seu pipeline de integração contínua e entrega contínua (CI/CD), poderá disponibilizar atualizações em produção mais rapidamente. No entanto, há um risco a ter em conta: a sustentabilidade. Se a sua equipa não conseguir manter este ritmo melhorado, poderá enfrentar uma má experiência do utilizador e potenciais vulnerabilidades de segurança.

3. Taxa de falhas de alterações (CFR)

O CFR é a percentagem de implementações que causam uma falha em produção. A falha pode consistir em indisponibilidade, reversões ou degradação do serviço. Esta métrica mostra a eficácia da sua equipa ao implementar alterações.

Os valores de referência do desempenho de elite são de 0-15%, enquanto os níveis de desempenho alto, médio e baixo se situam todos entre 16-30%.

Melhorar o CFR significa privilegiar a qualidade em detrimento da quantidade. As empresas lançam números variáveis de alterações e, por isso, têm números variáveis de falhas. No entanto, as modificações da mais alta qualidade resultarão em menos falhas, quer implementem alterações duas vezes por ano ou duas vezes por dia.

4. Tempo médio de recuperação (MTTR)

O MTTR corresponde ao tempo que a sua equipa demora a restaurar o serviço após uma falha ou interrupção. Esta métrica não só mede a agilidade da sua equipa, como também constitui um bom indicador da estabilidade do seu software.

Se pretende atingir um nível ‘elite’, terá de procurar obter um MTTR inferior a uma hora. As equipas com pior desempenho podem demorar mais de seis meses.

Pode reduzir o MTTR concentrando-se em lançamentos pequenos e rápidos, tornando as falhas mais fáceis de encontrar e corrigir. Poderá também explorar sinalizadores de funcionalidades para dar à sua equipa mais controlo — especialmente se forem experimentais.

Uma tabela que apresenta as métricas DORA divididas por velocidade e qualidade
As quatro métricas DORA incluem DF, LTC, CFR e MTTR.

Há mais uma métrica a abordar.

5. Fiabilidade

A quinta métrica de bónus é a fiabilidade. Esta métrica foi descoberta mais tarde pela equipa DORA (2021), uma vez que anteriormente se media a disponibilidade como referência para software fiável. No entanto, decidiu-se que a fiabilidade abrange melhor a disponibilidade, a latência, o desempenho e a escalabilidade. Essencialmente, consiste em incluir a medição do desempenho operacional juntamente com o desenvolvimento.

Outras métricas DevOps relevantes

  • Tempo de ciclo: O tempo de ciclo é o tempo total desde o início de uma tarefa até à entrega final. À primeira vista, acompanha a velocidade de trabalho da sua equipa. No entanto, pode analisar esta métrica mais detalhadamente para encontrar estrangulamentos, como tempos de espera longos e pedidos de integração de longa duração.
  • Tempo médio entre falhas (MTBF): O MTBF mede o tempo médio decorrido entre falhas do sistema, períodos de indisponibilidade ou incidentes. Esta métrica avalia a fiabilidade e a estabilidade dos seus sistemas de software, destacando a eficácia das suas estratégias de manutenção preventiva e mitigação de erros.
  • Tempo médio de deteção (MTTD): Este é o tempo médio que a sua equipa demora a reconhecer uma falha. Um MTTD baixo indica sistemas eficientes de monitorização e alertas, permitindo uma resposta e resolução rápidas dos incidentes.
  • Tempo de mitigação (TTM): O tempo necessário para corrigir um problema depois de este ser detetado corresponde ao TTM. Esta métrica ajuda a avaliar os processos de resposta e resolução de incidentes, indicando a eficiência das suas equipas na abordagem e recuperação de problemas.
  • Tempo de execução da alteração (CLT): O CLT fornece uma referência para o processo de implementação de alterações de ponta a ponta, incluindo desenvolvimento, testes, revisão e implementação. Um CLT mais curto significa ciclos de entrega mais rápidos e maior agilidade.
  • Taxa de defeitos escapados: A taxa de defeitos escapados corresponde ao número de erros que não são detetados durante os testes e são lançados em produção — isto é, o número de erros que ‘escaparam’. Esta métrica é ideal para acompanhar o progresso se pretender melhorar os processos de testes e automatização.

Como definir KPIs com métricas DevOps

Agora que já compreende bem as métricas que pode utilizar para implementar e otimizar o DevOps na sua empresa, deverá explorar os indicadores-chave de desempenho (KPIs) para definir algumas metas e referências para a sua equipa.

Métricas em comparação com KPIs

Poderá estar a perguntar-se qual é a diferença entre métricas e KPIs. Uma métrica é aquilo que mede. É uma medição quantificável que fornece dados sobre um aspeto específico do desempenho. Nem todas as métricas estão necessariamente associadas a objetivos ou metas específicos.

Por outro lado, os KPIs são um tipo de métrica selecionada e definida estrategicamente para refletir os aspetos mais críticos do desempenho e do progresso em direção aos objetivos estratégicos. Os KPIs estão normalmente associados a objetivos e têm frequentemente metas, limiares ou referências associadas que precisam de ser alcançados.

Definir KPIs para a sua equipa de DevOps

O primeiro passo para definir KPIs para a sua equipa de DevOps é associar as métricas de DevOps à estratégia e aos objetivos da sua empresa. Ao dar prioridade às métricas mais essenciais a acompanhar, pode começar a estabelecer metas e referências para uma melhoria contínua. A seleção das métricas certas requer que considere a dimensão da sua empresa, o produto e o mercado. Concentre-se naquilo que fornecerá os conhecimentos mais úteis para a tomada de decisões, evitando a armadilha comum do excesso de métricas.

A monitorização dos seus KPIs é tão importante como a sua definição. Explore ferramentas de visualização de dados para fornecer à sua equipa dados em tempo real através de painéis intuitivos. Isto garante uma visibilidade completa, promove a responsabilização e permite que todos trabalhem em conjunto para alcançar objetivos partilhados, alinhando as equipas de desenvolvimento e operações e apoiando a adoção e a maturidade de DevOps.

Uma tabela que apresenta os KPIs de referência para as métricas DORA de DevOps
KPIs de referência para as métricas DORA de DevOps.

Considerando as métricas principais DORA, podemos observar as referências para cada métrica com base nas equipas de desempenho excecional, elevado, médio e baixo. Esta tabela pode ajudá-lo a definir KPIs para a sua própria empresa, dependendo daquilo que considerar uma prioridade.

Ao definir os seus KPIs, é preferível considerar cuidadosamente a sua equipa e a sua empresa, sem as comparar com outras empresas. Se analisarmos a CFR como exemplo, a referência é a mesma para um desempenho elevado, médio e baixo. Isto dependerá em grande medida da sua frequência de implementação, mas também pode afetá-la no sentido inverso. Se a sua equipa passar todo o tempo a corrigir falhas, terá menos tempo para desenvolver e lançar atualizações. Os KPIs também podem mudar à medida que a sua equipa de DevOps amadurece. Processos de automatização e teste rigorosos devem significar automaticamente que pode elevar o nível das suas metas.

More Articles

Como utilizar as métricas de DevOps para crescer

Com a expectativa de que o mercado global de DevOps atinja 24.71 mil milhões de dólares até 2027  (uma taxa de crescimento anual composta de 22.9%, com base na dimensão do mercado de 10.84 mil milhões de dólares em 2023), considere isto um sinal caso esteja à procura da melhor altura para começar a implementá-lo na sua empresa.

DevOps não só acelera o desenvolvimento, reduzindo o tempo de colocação no mercado, como também melhora a colaboração ao eliminar silos, aumenta a qualidade através de testes contínuos e ciclos de feedback e utiliza os recursos de forma eficiente, o que permite poupar dinheiro. Por fim, é facilmente escalável, apoiando o crescimento da empresa até novos limites, com 83% dos responsáveis pela tomada de decisões de TI a obterem maior valor empresarial através da implementação de DevOps em 2021.

Medição do desempenho e melhoria contínua

A monitorização do desempenho é essencial para fazer crescer uma empresa que utiliza DevOps. Trata-se de uma abordagem dinâmica, com um fluxo de produção constante, pelo que a medição e os relatórios devem ser igualmente frequentes. As métricas de DevOps permitem acompanhar o desempenho dos seus processos de desenvolvimento e entrega. Ao quantificar aspetos fundamentais, como a frequência de implementação, o tempo de execução e a taxa de falhas de alterações, pode identificar estrangulamentos, ineficiências e áreas de melhoria. Isto permite-lhe otimizar frequentemente os fluxos de trabalho e os processos.

Um ciclo que mostra como as equipas de desenvolvimento e operações integram responsabilidades
Otimize os fluxos de trabalho com DevOps.

O acompanhamento de métricas como a taxa de falhas de alterações e o tempo médio de recuperação ajuda-o a identificar tendências que permitem detetar problemas numa fase inicial. Esta abordagem proativa significa que pode tomar medidas corretivas e minimizar o impacto nos clientes, proporcionando fiabilidade – outro ingrediente fundamental para crescer mantendo uma elevada qualidade.

Por fim, a utilização de métricas de DevOps ajudará a amadurecer a sua equipa de DevOps, promovendo uma cultura de melhoria contínua. Os ciclos de feedback promovem a aprendizagem e o crescimento; deve haver sempre espaço para experimentar abordagens diferentes.

Que métricas de DevOps apoiam o crescimento da empresa?

Ao definir KPIs, a maioria das métricas deve ser considerada no contexto da sua equipa e orientada para o crescimento, em vez de ser comparada com outras empresas e grupos em diferentes níveis de maturidade.

Por exemplo, um LTC baixo pode demonstrar que a sua equipa é eficiente, mas, se não conseguir manter o ritmo, não é sustentável e poderá eventualmente afetar a experiência do utilizador. Esta métrica deve ser medida ao longo do tempo, em vez de se definir um KPI para corresponder a uma equipa DevOps madura de elevado desempenho, ou mesmo de desempenho de elite. Definir KPIs para reduzir o LTC mês após mês, trimestralmente ou anualmente demonstra crescimento dentro da sua equipa e empresa.

O CFR é uma métrica valiosa porque nem todos têm o mesmo número de falhas ou problemas, mas, ao atribuir uma percentagem a este indicador, pode medir o sucesso das suas implementações. A sua equipa poderá ter muito poucas falhas se lançar alterações com pouca frequência, mas, se cada lançamento causar um problema, o CFR será muito elevado. Se seguir práticas de CI/CD, poderá observar um número maior de falhas, mas, se o seu CFR for baixo, terá uma vantagem, porque dispõe de velocidade e qualidade para apoiar o crescimento. O MTTR também deve ser medido ao longo do tempo para garantir um crescimento constante.

A DORA descobriu que as equipas de todos os níveis de desempenho no desenvolvimento obtiveram melhores resultados quando se concentraram no desempenho operacional. Isto pode significar definir KPIs para relatórios de incidentes ou tickets abertos, tempo de atividade das aplicações e disponibilidade.

Um número elevado de tickets abertos pode representar um problema com a satisfação dos seus clientes, mas procurar uma redução ao longo do tempo reflete crescimento nesta área. Poderá aprofundar a análise e medir os tempos de resposta e de espera em fila para acelerar a melhoria desta métrica.

A única métrica que combina integralmente o desenvolvimento e as operações numa equipa DevOps é o tempo de ciclo. Isto cria oportunidades para construir uma cultura de feedback e crescimento. À medida que as outras métricas melhoram e a automação amadurece, deverá esperar uma redução do tempo de ciclo. Se o seu serviço de apoio ao cliente for de elevada qualidade e as falhas de desenvolvimento forem reduzidas, terá encontrado uma combinação vencedora para expandir o seu negócio.

Adote uma cultura orientada por métricas para alcançar o sucesso a longo prazo

Descobrimos como a tomada de decisões baseada em dados pode ser implementada através do acompanhamento e da medição de métricas DevOps adequadas. A abordagem correta pode beneficiar o desempenho da equipa, a eficiência dos processos e a satisfação dos clientes.

Embora todas as estruturas DevOps se baseiem na cultura, na colaboração e na melhoria contínua, identificar a estrutura e as métricas aplicáveis à sua estratégia de crescimento ajudará a sua empresa a expandir-se da forma mais eficaz.

Lembre-se de subscrever a nossa newsletter para se manter atualizado sobre todas as novidades dos nossos especialistas do setor.

Paulo Gardini Miguel
Paulo is the Director of Technology at the rapidly growing media tech company BWZ. Prior to that, he worked as a Software Engineering Manager and then Head Of Technology at Navegg, Latin America’s largest data marketplace, and as Full Stack Engineer at MapLink, which provides geolocation APIs as a service. Paulo draws insight from years of experience serving as an infrastructure architect, team leader, and product developer in rapidly scaling web environments. He’s driven to share his expertise with other technology leaders to help them build great teams, improve performance, optimize resources, and create foundations for scalability.
Follow the author:

You may also like