$30 off During Our Annual Pro Sale. View Details »

Lições Aprendidas das 4 Key Metrics (DORA Metrics)

Lições Aprendidas das 4 Key Metrics (DORA Metrics)

Apresentação ministrada no Meetup DevOps Porto.

Vídeo aqui.
https://youtu.be/uQtktPNLu3Y

Fernando ike

April 23, 2022
Tweet

More Decks by Fernando ike

Other Decks in Technology

Transcript

  1. Deploy Frequency For the primary application or service you work

    on, how often does your organization deploy code to production or release it to end users? https://pixabay.com/photos/moto-motorcycling-sport-motorcycles-3406328/
  2. Lead time for changes For the primary application or service

    you work on, what is your lead time for changes (in production) https://pixabay.com/photos/motocycle-racing-race-track-moto-2101565/
  3. Time to restore service For the primary application or service

    you work on, how long does it generally take to restore service when a service incident or a defect that impacts users occurs (unplanned outage) https://pixabay.com/photos/running-marathon-people-sports-6660186/
  4. Change failure rate For the primary application or service you

    work on, what percentage of changes to production or released to users result in degraded service and subsequently require remediation? https://pixabay.com/photos/marathon-competition-sports-running-7111384/
  5. DevOps - 4 Key Metrics Throughput • Deployment frequency •

    Lead time for changes https://pixabay.com/photos/cheetah-animal-wildlife-leopard-2560006/
  6. DevOps - 4 Key Metrics Stability • Time to restore

    service • Change failure rate https://pixabay.com/photos/turtle-reptile-walk-walking-shell-1850190/
  7. DORA Metrics - Exemplo 1 Normal Incidente 1 Deploy Frequency

    3 dias 3/dia Lead Time for Changes 2 dias 90 minutos Time to Restore Service 12 horas 1,5 dia Change Failure Rate 60% 83%
  8. DORA Metrics - Exemplo 2 Backend Release Train Deploy Frequency

    1,2/dia 1/semana Lead Time for Changes 78 minutos 8 horas Time to Restore Service 122 minutos 52 minutos Change Failure Rate 19% 12%
  9. O que não são as 4 Keys Metrics Não são

    um objetivo em si Não são as únicas métricas a serem utilizadas Só implementar Kubernetes Só implementar Jenkins como CI/CD
  10. Os desafios para obter as 4 key metrics Visibilidade do

    Value Stream das equipes e/ou da organização Padrão mínimo Ciclo de Desenvolvimento de Software (Systems Development Life Cycle) Padrão mínimo de Infraestrutura (Ops)
  11. Os desafios para obter as 4 keys metrics Padrão mínimo

    de arquitetura de software ou componentes* Não há incentivo pela liderança de tecnologia em olhar indicadores e métricas de engenharia de software Baixa autonomia para coletar as dados para 4 Keys Metrics
  12. AI Company - Contexto 100% dos deploys falhavam 90 horas

    MTTR Deploy a cada 15 dias 102 dias para o primeiro release para um cliente Alto acoplamento entre os serviços Sobrecarga de trabalho em parte da equipe
  13. AI Company Critérios de aceitação para cada tarefa Testes automatizado

    para nova funcionalidade Implementação de CI/CD automatizado Roadmap de desenvolvimento dos componentes da plataforma “Framework” Migrations Implementação de observabilidade (Distributed Tracing)
  14. AI Company Arquitetura de software baseada em Domain-Driven Design Trunk-Based

    Development Gerenciamento visual (Kanban) Redistribuição da carga de trabalho para toda equipe Postmortem Premissas ◦ Tornar o onboading mais rápido de novos clientes ◦ Diminuir o Lead Time de novas funcionalidades ◦ Visibilidade de custos por cliente
  15. AI Company - Resultado Crescimento de 500% 30 dias para

    um protótipo funcional 60 dias para o primeiro release para um cliente MTTR == 90 minutos Lead Time for Changes => Ondemand Deploy Frequency => + 1 por dia 25 milhões de reais na rodada de investimento De 11 para 41 itens do backlog em 30 dias com 80% de certeza
  16. EdTech - Contexto Desenvolver uma plataforma de acompanhamento educacional Contratar

    uma equipe Definir a stack tecnológica Indicadores de performance Criar uma cultura de engenharia e produto do zero
  17. EdTech Contratar uma equipe para desenvolver a plataforma Gerenciamento visual

    Arquitetura e stack “viável” baseado no conhecimento da equipe ◦ Containers, Django, PostgreSQL, Nextjs, IaC ◦ CI/CD ◦ Testes unitários, testes de sistema Dojos para aumentar a cobertura de testes Trunk-Based Development
  18. EdTech Framework e Migrations Limitação do WIP Small Batches Identificação

    do “trabalho estocado” Delimitação das restrições Autonomia (atos de liderança) Cadência de release a cada 15 dias
  19. EdTech - Resultado Desenvolvimento plataforma de cadastro para + 1

    milhão de usuários em 15 dias Identificado o trabalho em estoque (bloqueado) com um total de +500 dias Implementação da plataforma base de gestão e acompanhamento de performance dos estudantes
  20. EdTech - Resultado Deploy Frequency == +1 por dia MTTR

    == 2 Horas Lead Time for Changes == 2 dias
  21. Muito tempo em trabalho operacional Falta de padronização de stack,

    processos, CI/CD, etc. Silos de equipes e serviços (Conway's law) Ciclos perpétuo de formas de trabalho, tecnologia e buzzwords Instituição "Regulada" - contexto
  22. Instituição "Regulada" Reestruturação das equipes (Inverse Conway Manoeuvre) Identificação dos

    principais gargalos Formação de equipes de plataforma Documentação Fornecer serviços Self-service Obter métricas de Engenharia Obter métricas de uso da Plataforma
  23. Instituição "Regulada" - Resultados Templates de Frameworks, libs e projetos

    Internal Developer Platform (CLI, Portais…) Implementação de guard-rails padronizados Desenvolvimento de uma Plataforma de CI/CD Padronização da observabilidade Automação (shift-left) dos processos de conformidade
  24. DORA Metrics da equipe Antes Agora Deploy Frequency 0,5/dia 1,60/dia

    Lead Time for Changes 10 horas 5 horas Change Failure Rate 26% 17%
  25. O que mudaram Diminuição de cerimônias síncronas Adoção de Design

    Docs Mudança de Scrum para Método Kanban Mudanças pequenas de código por deploy
  26. Técnicas, recursos e capacidades Loosely coupled architecture Trunk-based development Continuous

    testing Continuous integration Use of open source technologies Monitoring and observability practices
  27. Management of database changes Deployment automation Small Batches Visual management

    capabilities Liderança Técnicas, recursos e capacidades
  28. Onde a organização está? Consegue coletar as 4 keys metrics

    facilmente? Consegue utilizá-las com outros indicadores? ◦ Cycle Time ◦ Blocked Time ◦ Work Item Age ◦ Percentual de trabalho não planejado ◦ Bugs/Defeitos que geram incidentes em produção Qual a dívida técnica principal da organização? Tem mapeado os processos atuais?
  29. Para onde vai? Direcionamento claro do "Futuro" Liderança está patrocinando

    o direcionamento para o futuro? Conceitos e fundamentos como fundação das ferramentas, serviços e plataformas adotadas ou em desenvolvimento
  30. Está na direção certa? (A cada ciclo há) revisão dos

    processos, automações, e funcionalidade As hipóteses e decisões são baseadas em dados? A organização entende (evolução) que hoje está melhor que ontem?
  31. Conway Law é “…organizações que projetam sistemas (no sentido amplo

    usados aqui) restringem o desenvolvimento dos projetos como cópias da estrutura de comunicação dessas organizações”
  32. Equipes autônomas => Aprendizado Contínuo Feedback Loops ◦ Scrum, Kanban…

    ◦ 3 Way, CAMS… ◦ Postmortem Reviews ◦ PDSA/PDCA
  33. Equipes autônomas => Aprendizado Contínuo % de tempo para aprendizado

    ◦ Dojos ◦ Hackathons ◦ GameDay ◦ Aprendizado Individual ◦ Colaboração com projetos externos (OpenSource) e/ou internos
  34. Equipes autônomas => Aprendizado Contínuo Restrições da organização ◦ Pessoas

    ◦ Estrutura Organizacional ◦ Orçamento (Dinheiro) ◦ Leis, Procedimentos, Normas, etc.
  35. Referências DORA Research Program DevOps State Report 2021 Accelerate: The

    Science of Lean Software and DevOps Continuous Delivery Kanban DevOps Capabilities Conway Law The Goal PixBay