Baixar para ler offline
Carregado porRodrigo R Garcia, PMP
Webinar DevOps - Encontros Ágeis
O documento discute práticas ágeis de desenvolvimento de software, como DevOps. Apresenta casos em que equipes de desenvolvimento e operações precisam trabalhar juntas para resolver problemas. Também discute os benefícios de automação, integração e entrega contínuas para melhorar a velocidade e qualidade do trabalho.
Webinar DevOps - Encontros Ágeis
- 1.
- 2. Rodrigo R Garcia rodrigorgarcia @rodrigorgarcia rodrigo@rrgarcia.com.br Gestãode projetos PMO PMP, PSM, ITIL, COBIT, OCEB-F, MCP Project, DevOps-F
- 3. Nota Dado que aliteratura de referência utilizada não possui tradução oficial para o português, alguns termos foram mantidos na língua original
- 4. 6 dias depoisde uma implantação bem sucedida, o servidor começou a apresentar alto consumo de processadores Dev ou Ops?
- 5. Sábado, 3h damadrugada. A aplicação foi finalmente instalada em produção. Login não funciona Dev ou Ops?
- 6. Apenas 8 diasantes do ‘go live’, a equipe de auditoria decidiu realizar uma inspeção detalhada. Descobriram que existe uma maneira de realizar acessos irregulares Dev ou Ops?
- 7. Apenas 8 diasantes do ‘go live’, a equipe de auditoria decidiu realizar uma inspeção detalhada. Descobriram que existe uma maneira de realizar acessos irregulares Dev ou Ops?
- 8. Responder rapidamente às mudançasde negócio Prover serviços estáveis, seguros e previsíveis Dev ou Ops?
- 9. Responder rapidamente às mudançasde negócio Prover serviços estáveis, seguros e previsíveis Dev ou Ops? Débito técnico
- 10.
- 11.
- 12. Ops: Você teve6 meses pra pedir essa liberação de firewall Ops: É o seu código!!! Dev: É o seu servidor!!! Tester: O bug da semana passa voltou!! CIO: As lojas abrem em 3 horas!! Dev: É a sua configuraçãor!!!
- 13. Responder rapidamente às mudançasde negócio Prover serviços estáveis, seguros e previsíveis Dev ou Ops? The chronich deadlock
- 14. https://www.theguardian.com/world/2017/may/27/british-airways-system-problem-delays-heathrow “The computer crashaffected BA’s booking system, baggage handling, mobile phone apps and check-in desks, leaving passengers facing long queues and confusion in airports or delays while planes were held on runways” “More than 1,000 flights were affected” “Experts believe passengers will be affected for several more days”
- 15. Responder rapidamente às mudançasde negócio Prover serviços estáveis, seguros e previsíveis Dev ou Ops? The chronich deadlock
- 16. Responder rapidamente às mudançasde negócio Prover serviços estáveis, seguros e previsíveis Dev ou Ops? The chronich deadlock
- 17. Responder rapidamente às mudançasde negócio Prover serviços estáveis, seguros e previsíveis Dev ou Ops? Trust culture
- 18. Responder rapidamente às mudançasde negócio Prover serviços estáveis, seguros e previsíveis Dev ou Ops? Trust culture DevOps
- 19. 2009 O’Reilly Velocity Conference John Allspaw/ Paul Hammond “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” Devopsdays (Ghent, Belgium) Patrick Debois Termo DevOps Aparece pela 1ª vez 2010 1º US Devopsdays 2011 DevOps no Gartner 2012 Eventos Devopsdays se espalham pelo mundo 2013 Gene Kim Kevin Behr George Spafford 2014 Target, Nordstrom e LEGO adotam práticas DevOps “DevOps Enterprise: The Agile, Continuous Delivery and DevOps Transformation Summit” Primeiro evento corporativo
- 20. State of DevOpsReport 2016 https://puppet.com/resources/whitepaper/2016-state-of-devops-report
- 21. State of DevOpsReport 2016 https://puppet.com/resources/whitepaper/2016-state-of-devops-report
- 22. The three ways Osprincípios que sustentam DevOps Fist Way: The principle of flow Second Way: Amplify Feedback Loop Third Way: Culture of Continual Experimentation and Learning Valores DevOps CALMS Culture (people and process) Automation Lean Mesurement Sharing
- 23. Princípios • Torne otrabalho visível • Limite o trabalho em progresso (WIP) • Reduza o tamanho dos pacotes de trabalho • Reduza a quantidade de ‘handoffs’ • Identifique e declare as restrições: Elimine deserdícios Trabalho parcialmente pronto Processos extras Recursos que trocam de atividades Defeitos Atos heircos etc Fist Way: The principle of flow Idéia Negócio Cliente
- 24. Projetos de negócioProjetos de TI (internos) ChangesTrabalho não planejado
- 25. Princípios • Torne otralho visível • Limite o trablalho em progresso (WIP) • Reduza o tamanho dos pacotes de trabalho • Reduza a quantidade de ‘handoffs’ • Identifique e declare as restrições • Elimine deserdícios: Trabalho parcialmente pronto Processos extras Recursos que trocam de atividades Defeitos Atos heircos etc Práticas • Continuous integration • Continuous delivery • Continuous deployment • Mapa de fluxo de valor (Value stream mapping) • Kanban • Teoria das restrições (Theory of constraints) Fist Way: The principle of flow Idéia Negócio Cliente
- 26. https://xebia.github.io/cd-with-docker/#/2 Continous Integration Continous Deployment Continous Delivery IaC – Infrastructureas code – Possbilita que todas as estruturas (servidores, configurações, etc) sejam reconstruídas com nada além de um repositório de códigos, um backup da aplicação e alguns poucos recursos Ambientes sob demanda – todos os ambientes, icluindo a produção, desenvolvimento e testes precisam estar sincronizados Testes em geral – QA, performance, regressivos, etc Monitoramento preventivo dos componentes de infraestrutura, ambientes, sistemas e serviços Outras oportunidades de automação
- 27. Princípios • Torne otralho visível • Limite o trablalho em progresso (WIP) • Reduza o tamanho dos pacotes de trabalho • Reduza a quantidade de ‘handoffs’ • Identifique e declare as restrições • Elimine deserdícios: Trabalho parcialmente pronto Processos extras Recursos que trocam de atividades Defeitos Atos heircos etc Práticas • Continuous integration • Continuous delivery • Continuous deployment • Mapa de fluxo de valor (Value stream mapping) • Kanban • Teoria das restrições (Theory of constraints) Fist Way: The principle of flow Idéia Negócio Cliente Courtney Kissler - DevOps Cafe Episode 71 http://devopscafe.org/show/2017/5/25/devops-cafe-episode-71-courtney-kissler.html 00'13'00 document reality 00'14'06 (...) asking my team who all contributes to delivering that functionality into our store and let´s all get together and really document what it takes, and not what we wanted to be, what the current state of reality is so we can problem solve against it, then you catch the true baseline So for me it is literally the steps along the way, the time of those steps, so capturing like the wait time, the process time, and really coming up with what we consider to be our cycle time, like we know what it is and that enable us to say where are the biggest bottlenecks in the system in a very fact based way (…)
- 28. Princípios: • Considerar oproblema quando ele ocorre • Resolver o problema gerando novos conhecimentos • Trazer questão de qualidade e segurança o mais próximo da origem • Otimizar continuamente os núcleos de trabalho Benefícios: • Defeitos e questões de segurança corrigidos mais rápido do que nunca • ‘User stories’ originadas na operação e segurança como parte do backlog • Comunicação e coordenação dos grupos aprimorada Second Way: Amplify Feedback Loop
- 29. • Altos níveisde confiança e diminuição das fronteiras entre as funções • Adimitir que falhas irão ocorrer em ambientes complexos • Tornar natural falar sobre problemas (safe system of work) • Converter aprendizado local em global • Institucionalizar o melhoria diária Third Way: Culture of Continual Experimentation and Learning
- 30. https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116 Chaos Monkey Uma ferramentaque aletatoriamente desabilita instâncias de produção, certificando que podemos sobreviver a este tipo de falha sem nenhum impacto aos clientes Simian Army Chaos Monkey Latency Monkey Conformity Monkey Doctor Monkey Janitor Monkey 10-18 Monkey Chaos Gorilla
- 31.
- 32.
- 33. State of DevOps2017 https://puppet.com/resources/whitepaper/state-of-devops-report Tradicionalmente, era esperado que líderes fossem responsáveis por determinar os objetivos, or recursos necessários e a combinação correta de incentivos. Também deveriam determinar a atmosfera emocinal. Em outras palavras, liderar era “tomar todas as decisões corretas” No entanto, evidências mostram que a grandeza não é obtida desta forma. Na verdade o papel do líder é criar o ambiente para que o time descubra a grandeza no trabalho diário. Em outras palavras, criar grandeza requer unicidade entre líderes e liderados, onde um é mutualmente dependente do outro. DevOps Handbook, pag 44
- 34. State of DevOps2017 https://puppet.com/resources/whitepaper/state-of-devops-report Diminuição do gap entre as equipes de maior e menor performance demonstra aumento geral da velocidade de deploy. Porém a qualidade ainda não está acompanhado essa velocidade.
- 35. Nicole Forsgren @nicolefv Bridget Kromhout @bridgetkromhout PatrickDebois @patrickdebois Jez Humble @jezhumble Kelsey Hightower @kelseyhigtower GeneKim @RealGeneKim Indicações
- 36.
- 37.
Notas do Editor
- #9 Responsabilidades Dev e Ops
- #10 Quando a pressão aumenta do lado do Dev, mais e mais códigos vão sendo colocados em produção tornando cada vez mais difícil encontrar erros e criando débito técnico
- #11 Debito tecnico começa assim
- #12 e se torna isso Deploy começa a ficar cada vez mais complicado O que demorava uma ou duas horas, começa demorar 5, depois 10, depois todo o sábado Funcionalidades que estavam funcionando param de funcionar
- #13 A distância entre deploys começa a aumentar na tentativa de minimizar o risco. Porém quanto maior a distancia mais ‘moving parts’
- #14 Até que realizar um deploy se torna uma jornada épica
- #15 Responsabilidades Dev e Ops
- #16 Até que a frustração toma conta e parece que não há mais saída. E não importa mais se é Dev ou Ops, o negócio passa a sofrer as consequencias
- #18 Responsabilidades Dev e Ops
- #19 Responsabilidades Dev e Ops
- #20 Responsabilidades Dev e Ops
- #21 Responsabilidades Dev e Ops