6 min de leitura
Medição de Métricas DORA
Recolha de Dados: Manual vs. Automatizada
A recolha automatizada de dados é a melhor forma de evitar métricas imprecisas que conduzem subsequentemente a decisões de negócio incorretas. No entanto, a automatização de todos os parâmetros envolvidos no cálculo de uma métrica pode não ser possível devido a restrições. Nestes casos, estabeleça um acordo sobre uma abordagem manual que seja razoável e esteja alinhada com as normas da indústria.
Tempo de Atravessamento:
Medido com base no tempo despendido por uma funcionalidade para transitar de um pedido de negócio para a produção. Isto pode ser medido através da utilização de várias ferramentas em cada etapa.
- Automatize os testes e as implementações (pipelines CI/CD).
- Reduza a dimensão dos lotes (alterações mais pequenas e frequentes).
- Melhore os processos de revisão e aprovação de código.
- Monitore os estrangulamentos (por exemplo, ciclos de QA longos, aprovações manuais).
Método manual:
Quando as ferramentas/suplementos necessários não estão disponíveis para o cálculo automatizado do Tempo de Atravessamento, pode ser adotada uma abordagem manual. Pode calcular manualmente o Tempo de Atravessamento no Azure DevOps (ADO) ou em sistemas semelhantes utilizando extratos de dados brutos. Apresenta-se uma abordagem passo a passo:
Extração de Dados
- Origem: Consulta de Itens de Trabalho do ADO ou API.
Âmbito:
- Filtre para Funcionalidades/Histórias de Utilizador assinaladas como Concluídas (ou seja, implementadas em Produção).
Extrair:
- Data de Criação (quando o item de trabalho foi solicitado).
- Data de Fecho/Conclusão (quando marcado como "Concluído").
Fórmula para o tempo de espera de Funcionalidade/História de utilizador:
- Tempo de Espera (por item) = Data de Fecho - Data de Criação
Fórmula para a Média a Nível de Projeto
- Tempo de Espera Médio = Soma (Tempo de Espera por item) ÷ Número Total de Itens
* Nota: Nos casos em que as funcionalidades planeadas são criadas antecipadamente, a métrica de tempo de espera não refletirá fielmente a realidade e, nesses casos, o Tempo de Ciclo pode ser utilizado como uma métrica alternativa.
Frequência de Implementação:
- Contar o número de implementações em produção num determinado período (por exemplo, por dia, semana ou mês).
Extração de Dados:
- Utilizar ferramentas de CI/CD (por exemplo, GitHub Actions) para registar a contagem de implementações.
Fórmula para a Frequência de Implementação:
- Número total de implementações / Número de meses
Fórmula para a Média a Nível de Projeto:
- Número de implementações do projeto / Número de meses
*Nota: De acordo com a definição da indústria, as implementações de correções rápidas são excluídas da contagem de implementações.
Taxa de falhas de alterações:
O que conta como uma "Implementação com falha"?
- Reversões (reverter uma versão devido a problemas).
- Correções rápidas (patches urgentes após a implementação).
Método de acompanhamento:
- Integre com falhas de implementação do pipeline de CI/CD (por exemplo, Jenkins, GitHub Actions) para sinalizar falhas.
- Utilize ferramentas de gestão de incidentes (por exemplo, ADO, Jira, ServiceNow).
Fórmula para a taxa de falhas de alterações:
- Número de alterações com falha ÷ Número total de alterações × 100.
Método manual:
Para calcular o número de alterações com falhas, pode ser utilizado o número de incidentes de suporte categorizados como "Erro de software". Ao dividir este valor pelo número total de alterações lançadas, obtemos a CFR.
As organizações precisam de ter os incidentes classificados periodicamente para que a métrica seja exata.
Tempo médio de recuperação (MTTR):
O que conta como "Tempo de recuperação"?
- Início: Quando o erro é detetado (alerta acionado).
- Fim: Quando o sistema estiver totalmente restaurado (por exemplo, reversão concluída, correção rápida implementada).
Método de acompanhamento:
- Ferramentas de gestão de incidentes (por exemplo, ADO, Jira).
- Sistemas de monitorização (por exemplo, CloudWatch, Prometheus) para registar os tempos de resolução.
Fórmula para calcular o MTTR:
- Soma dos Tempos de Restauração ÷ Número de Falhas
Método manual:
A soma dos Tempos de Restauração pode ser obtida com base nos incidentes de suporte classificados como "Erro de Software". A diferença entre a "Data de Criação" e a "Data de Fecho" em dias pode ser utilizada como numerador.
A utilização da contagem de incidentes classificados como "Erro de Software" pode ser utilizada como denominador.
Ligar ADO, CI/CD e Sistemas de Monitorização
A recolha destas métricas periodicamente e a sua otimização ajudam as organizações a alcançar eficiência na forma como lançam o software.
Dispor de ferramentas eficazes, plugins e integrá-los ajuda a automatizar a maioria destas tarefas e a geração de métricas, permitindo tomar decisões adequadas.
O Azure DevOps (ADO) fornece os Metadata necessários para capturar os dados brutos para o cálculo destas métricas. A equipa de DevOps necessita de uma avaliação cuidadosa, tendo em conta as necessidades futuras do negócio.
Ferramentas de Visualização e Painéis
O Azure DevOps (ADO) disponibiliza funcionalidades de painel com estes Metadata e widgets para capturar algumas destas métricas. No entanto, garantir que os Metadata são atualizados para cada item de trabalho é essencial para gerar métricas precisas.
Ferramentas alternativas como Power BI, Grafana podem ser utilizadas para uma melhor visualização e relatórios para as partes interessadas.
Desafios e Considerações para as Organizações
Recolha de Dados e Utilização de Ferramentas
Integridade dos Dados e Limitações das Ferramentas
Desafios:
- Fontes de Dados Inconsistentes: Os pipelines de DevSecOps extraem dados de ferramentas díspares (sistemas CI/CD, scanners, gestores de incidentes), resultando em cronogramas desfasados, falsos positivos ou lacunas.
- Viés de Relatórios Manuais: Métricas curadas por humanos (por exemplo, relatórios de incidentes) carecem frequentemente destandardização, distorcendo tendências como o MTTR (Tempo Médio de Recuperação).
Solução:
- Impor Rastreabilidade: Utilize Metadata imutável (por exemplo, IDs de pipeline do Azure DevOps, commits do Git) para extrair dados relacionados com alterações de código.
- Validar com Correlação entre Ferramentas: Combine dados do SonarQube (qualidade do código), ADO para sinalizar anomalias e normas da indústria para validar os dados de métricas.
Disponibilidade de Ferramentas e Plugins
Desafio:
- As organizações podem não ter acesso a ferramentas de DevSecOps integradas (por exemplo, scanners SAST/DAST, rastreadores de implementação) ou enfrentar dificuldades com os custos de licenciamento.
Solução:
- Aproveite o Azure DevOps Marketplace para obter plugins (por exemplo, OWASP ZAP, SonarQube).
- Utilize alternativas de código aberto quando os orçamentos forem limitados.
Configurar o ADO para Capturar Metadata
Desafio:
- Os dados brutos do ADO (compilações, lançamentos, itens de trabalho) exigem uma etiquetagem/associação adequada para gerar métricas como Tempo de Espera ou Frequência de Implementação.
Solução:
- Impor campos obrigatórios em itens de trabalho e atualizações periódicas.
- Utilize Vistas do ADO Analytics ou conectores do Power BI para consultar os dados de metadata do pipeline.
Atualizações Eficazes em Alterações de Estado de Itens de Trabalho
Desafio:
- As atualizações manuais de estado (por exemplo, Concluído → Aprovado) atrasam métricas como o Tempo de Ciclo.
Solução:
- Automatizar transições utilizando webhooks do ADO ou Azure Functions (por exemplo, atualização automática quando os PRs são fundidos).
- Mapeie estados para portas de DevSecOps (por exemplo, estado de Revisão de Segurança antes da implementação).
Dados Insuficientes para Gerar Métricas
Desafio:
- Dados escassos (por exemplo, implementações pouco frequentes, baixo número de incidentes por projeto) que distorcem as tendências.
Solução:
- Definir limiares mínimos (por exemplo, "Monitorizar apenas se >5 incidentes da categoria de erro de software").
Métricas Inconclusivas para Tomada de Decisão
Desafio:
- As métricas de vaidade (por exemplo, "MTTR de 120 dias") não motivam a ação.
Solução:
- Concentre-se em métricas orientadas para resultados apoiadas por dados suficientes.
Resistência Organizacional e Utilização Inadequada
Resistência Organizacional
Desafios:
- Medo de Exposição: As equipas podem resistir a métricas que evidenciam ineficiências (por exemplo, uma Taxa de Falha de Alteração elevada devido a rejeições de segurança).
- Excesso de Ferramentas: A introdução de novas ferramentas de DevSecOps, metadata a ser recolhida e suplementos (por exemplo, analisadores SAST) pode gerar resistência se for considerada disruptiva ou desnecessária.
- Incentivos Desalinhados: A liderança valoriza uma métrica em detrimento de outra. O "Tempo de Atravessamento" isoladamente pode induzir em erro.
Estratégias de Mitigação:
- Enquadre as Métricas como Ferramentas de Melhoria:
- Enfatize a forma como estas métricas ajudam a Organização a longo prazo e a comparar ou medir o desempenho.
- Métricas Piloto:
- Comece por projetos não críticos para demonstrar o valor antes de uma implementação a nível organizacional e concentre-se nas métricas que oferecem valor de negócio.
Objetivos de longo prazo da organização vs. Resultados derivados de métricas
Desafio:
- Desalinhamento: A otimização de métricas a curto prazo (por exemplo, melhorar a Frequência de Implementação) pode entrar em conflito com objetivos de longo prazo (por exemplo, redução da dívida técnica, maturidade de conformidade).
- Métricas de vaidade vs. Entrega de valor: As equipas podem dar prioridade a métricas que parecem boas em detrimento de resultados significativos.
Solução:
Agrupar Métricas por Temas Estratégicos:
- Mapear métricas (por exemplo, Tempo de Espera) para objetivos de negócio (por exemplo, "Tempo de colocação no mercado mais rápido para produtos críticos para a conformidade").
Desafio:
Armadilha de métricas ao definir o roteiro: O foco excessivo numa métrica (por exemplo, MTTR) pode ignorar problemas sistémicos (por exemplo, automação de testes inadequada).
Solução:
Portfólios de Métricas Ponderadas:
- Equilibrar as métricas com os objetivos de longo prazo da organização (por exemplo, Frequência de Implementação), estabilidade (Taxa de Falha de Alteração), em relação ao tempo de espera
Equilibrar as Métricas com a Cultura da Equipa
Os Riscos Culturais do Excesso de Métricas
Desafios:
- Medo da medição: As equipas podem percecionar as métricas como vigilância, o que gera stresse e esgotamento.
- Manipulação do sistema: A pressão para atingir metas (por exemplo, Frequência de implementação) pode incentivar atalhos (por exemplo, omitir análises de segurança).
- Sufocação da inovação: O foco excessivo nas métricas pode desincentivar a experimentação (por exemplo, o receio de que falhas nas implementações afetem a Taxa de falhas de alterações).
Solução:
- A segurança psicológica em primeiro lugar:
- Enfatize que as métricas são ferramentas de diagnóstico e não avaliações de desempenho.
- Celebre a "aprendizagem com os erros" (por exemplo, análises pós-incidente que melhoram o MTTR).
- Conceção de métricas liderada pela equipa:
- Envolva os engenheiros na seleção de métricas (por exemplo, permita-lhes escolher entre o Tempo de espera ou o Tempo de ciclo como prioridade em detrimento da Taxa de falhas de alterações).
Métricas vs. capacidade da equipa e necessidades de formação
Lacunas de Capacidade que Bloqueiam as Métricas
Desafio:
As equipas não têm competências para melhorar as métricas principais (por exemplo, Tempo de Espera lento devido à falta de familiaridade com ferramentas de segurança)
Soluções:
- Segmentação de Métricas Baseada em Competências:
- Exemplo: Monitorizar o Tempo de Espera separadamente para as equipas que adotam novas ferramentas SAST
- Formação Just-in-Time:
- Automatizar acionadores de formação (por exemplo, se a Taxa de Falhas no Pipeline Devido à Segurança >15%, atribuir formação modular).
- Métricas de Tutoria:
- Medir a % de Sessões de Programação em Par para potenciar a partilha de conhecimentos.
Métricas que Ignoram o Crescimento da Equipa
Desafio:
- A sobrevalorização de métricas de resultados (por exemplo, Frequência de Implementação) desvaloriza a construção de capacidades.
Soluções:
- Equilibrar Métricas de Resultados e de Crescimento:
- Combine a Frequência de Implementação com a % de Equipa Contribuidora para o Código do Pipeline.
- Métricas de Percurso Profissional:
- Exemplo: Acompanhe a % de Engenheiros a Liderar Revisões de Segurança para incentivar a responsabilização.
Referências
- Accelerate por Forsgren, Humble & Kim
- Documentação do Azure DevOps
- Relatórios de Investigação e Avaliação de DevOps (DORA)
