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

Apresentação ministrada no Meetup DevOps Porto.

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

Transcript

1. Insights sobre 4 Key Metrics
2. Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com
4. 4 Keys Metrics https://unsplash.com/photos/C1P4wHhQbjM
5. 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/
6. 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/
7. 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/
8. 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/
9. DevOps - 4 Key Metrics Throughput • Deployment frequency • Lead time for changes https://pixabay.com/photos/cheetah-animal-wildlife-leopard-2560006/
10. DevOps - 4 Key Metrics Stability • Time to restore service • Change failure rate https://pixabay.com/photos/turtle-reptile-walk-walking-shell-1850190/
11. Quando a organização não é de Elite Performance?
12. 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%
13. 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%
14. https://pixabay.com/pt/photos/puzzle-quebra-cabe%c3%a7a-textura-2204615/ O que as 4 Keys Metrics não são…
15. 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
16. O desafio para coletar as 4 Key Metrics https://pixabay.com/pt/photos/corredor-obst%c3%a1culo-corre-esporte-555074/
17. 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)
18. 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
19. Casos
20. 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
21. 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)
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. EdTech - Resultado Deploy Frequency == +1 por dia MTTR == 2 Horas Lead Time for Changes == 2 dias
29. 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
30. 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
31. 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
32. Uma equipe usando a DORA Metrics e DevOps Capabilities
33. 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%
34. Antes
35. Depois
36. Cumulative Flow Diagram
37. 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
38. Técnicas, recursos e capacidades https://pixabay.com/pt/photos/m%c3%a3os-megaminx-cubo-de-rubik-cubo-5762539/
39. Técnicas, recursos e capacidades Loosely coupled architecture Trunk-based development Continuous testing Continuous integration Use of open source technologies Monitoring and observability practices
40. Management of database changes Deployment automation Small Batches Visual management capabilities Liderança Técnicas, recursos e capacidades
42. DevOps Capabilities
43. https://pixabay.com/pt/photos/biblioteca-la-trobe-estude-alunos-1400313/ Outros insights
44. 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?
45. 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
46. 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?
47. Equipe autônomas
48. 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”
49. Equipes autônomas => Aprendizado Contínuo Feedback Loops ◦ Scrum, Kanban… ◦ 3 Way, CAMS… ◦ Postmortem Reviews ◦ PDSA/PDCA
50. Equipes autônomas => Aprendizado Contínuo % de tempo para aprendizado ◦ Dojos ◦ Hackathons ◦ GameDay ◦ Aprendizado Individual ◦ Colaboração com projetos externos (OpenSource) e/ou internos
51. Equipes autônomas - Restrições https://pixabay.com/photos/caravan-desert-safari-dune-camels-339564/ Quais as restrições aqui?
52. Equipes autônomas - Quais as restrições?
53. Equipes autônomas - Restrições https://pixabay.com/photos/freight-trains-industrial-metal-846093/ Quais as restrições aqui?
54. Equipes autônomas => Aprendizado Contínuo Restrições da organização ◦ Pessoas ◦ Estrutura Organizacional ◦ Orçamento (Dinheiro) ◦ Leis, Procedimentos, Normas, etc.
55. 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
56. Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com