Baixar para ler offline
Carregado porGustavo Chaves
DevOps
O documento discute práticas de DevOps adotadas por empresas como Amazon, Google e Netflix que levam a deployments frequentes, menor tempo de implantação e maior estabilidade. Ele também apresenta métricas para medir o desempenho de TI e práticas correlacionadas como controle de versão e entrega contínua. Finalmente, discute práticas técnicas e organizacionais como equipes multidisciplinares e cultura organizacional para permitir a colaboração entre Dev e Ops.
![[DevOps Summit Brasil] Procura-se: DevOps!](https://cdn.slidesharecdn.com/ss_thumbnails/devopssummitbrasilprocura-sedevopsv1-160516050715-thumbnail.jpg?width=640&height=640&fit=bounds)
DevOps
- 1.
- 2.
- 3. Amazon entre 2006-2011 ●300 deployments por hora ● 4x menos falhas de deployment ● 10x menos indisponibilidade ● ~0,0001% dos deployments falham ● Rollback automático e instantâneo ● Processo simplificado https://www.youtube.com/watch?v=dxk8b9rSKOo
- 4.
- 5. 2015 State ofDevOps Report “Organizações de alto-desempenho fazem 30x mais deployments com um lead time 200x menor; sofrem 60x menos falhas e se recuperam 168x mais rápido.” puppetlabs.com/2015-devops-report
- 6. 2015 State ofDevOps Report Entregam valor mais rápido aplicando práticas de Lean management e de continuous delivery. Conseguem isso em aplicações novas ou legadas. Os gestores têm papel crítico em qualquer iniciativa DevOps. puppetlabs.com/2015-devops-report
- 7. Como Medir oDesempenho de TI? Métricas de Fluxo Métricas de Estabilidade Frequência de Deploys Lead Time de Mudança Taxa de Falhas Tempo de Recuperação puppetlabs.com/2014-devops-report
- 8. Práticas DevOps Correlacionadas Métricasde Fluxo Métricas de Estabilidade Frequência de Deploys ❏ Controle de Versões ❏ Continuous Delivery Lead Time de Mudança ❏ Controle de Versões ❏ Testes Automáticos Taxa de Falhas Tempo de Recuperação ❏ Controle de Versões ❏ Monitoração Proativa puppetlabs.com/2014-devops-report
- 9. 1990 1995 20002005 2010 2015 ITIL ITILv2 ITILv3 DevOps Visible Ops Agile Lean Kanban XP Scrum RUP
- 10. From Concept toCash The authors used well-proven lean concepts from the 1980’s and 1990’s to help explain why agile methods are a very effective approach to software development, …, offering basic ideas and practices, building blocks which a team can use to incrementally build an exceptional process over time. This book is written for anyone who wants a more effective development process - managers, project leaders, senior developers, and architects in enterprise IT and software companies alike.
- 11. A Novel AboutIT, DevOps, and Helping Your Business Win ABOUT THE BOOK ❏ how to recognize problems that happen in IT organizations ❏ how these problems jeopardize nearly every commitment the business makes: Development, IT Operations and Information Security ❏ how DevOps techniques can fix the problem to help the business win “It's a gripping read that captures brilliantly the dilemmas that face companies which depend on IT, and offers real-world solutions. As Deming reminds us, "It is not necessary to change. Survival is not mandatory." The Phoenix Project will have a profound effect on IT, just as The Goal did for manufacturing.” –Jez Humble, co-author of the Jolt award winning book "Continuous Delivery," and Principal at ThoughtWorks Studios
- 13. Desperdícios no Desenvolvimentode Software ● Funcionalidade extra ● Trabalho incompleto ● Retrabalho (“churn”)
- 15. Prática fundamental deDevOps Continuous Deployment commit unit tests integration tests acceptance tests deploy to production
- 16. Prática: Infraestrutura éCódigo commit unit tests integration tests acceptance tests deploy to production version control
- 17. Prática: Tudo sobreControle de Versão ● Código da aplicação ● Configuração da aplicação ● Configuração do sistema ● Scripts de teste ● Scripts de deployment ● Manifestos de infraestrutura
- 19.
- 20.
- 21.
- 23. “Se seus testesrotineiramente encontram defeitos é porque o seu processo de desenvolvimento é defeituoso.” “Há dois tipos de teste: os que encontram defeitos e os que previnem defeitos. Os primeiros são puro desperdício. O objetivo é prevenir a inserção de defeitos no código em primeiro lugar e a ferramenta pra fazer isso é test-driven development.” -- Mary e Tom Poppendieck Prática: Test-Driven Development
- 24. Prática: Revisão deCódigo Todo commit é revisado por um colega e validado por checks automáticos antes de ser integrado. Elimina código “porco” Elimina “feudos” e “órfãos” no código Maneira mais barata de treinar novatos Melhor investimento pra evitar que o código “apodreça”
- 26. Arquitetura Monolítica simples quandopequeno baixa latência repositório único difícil coordenar quando grande difícil manter modularizado impossível escalar horizontalmente builds demoradas deploy “tudo ou nada” UI Business Logic Data Access Layer Database
- 27. Prática: Arquitetura deMicro-serviços UI Microservice Microservice Database Microservice Database Microservice Database
- 28. Práticas Técnicas Put everythingunder version control Trunk-based development Code Review Automated acceptance testing Canary testing A/B testing Proactive monitoring Microservices architecture Peer-reviewed change approval process Infrastructure configuration management Ops using Dev tools ...
- 30. Alto custo decomunicação entre equipes UI Business Logic Data Access Layer Database requisitos arquitetura implementação testes implantação configuração infraestruturabanco de dados
- 31. Qual é oproblema?
- 32. Como Dev vêOps
- 33. Como Ops vêDev
- 34.
- 35. ♡ O quegostaríamos de ver ♡ http://devopsreactions.tumblr.com/post/51462515324/encouraging-the-usage-of-coding-standards
- 36. Prática: Equipes Multidisciplinares “Donas”de seus Serviços UI Microservice Microservice Database Microservice Database Microservice Database
- 37. “An important aspectof Facebook's development culture is the idea that developers are fully responsible for how their code behaves in production. This philosophy mirrors the "DevOps" movement, which encourages lowering the wall between software development and IT operations. If any of the code in a Facebook update causes problems in production, the developer who wrote it is on the hook for making sure that the issue gets resolved as quickly as possible.” http://arstechnica.com/business/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering/
- 39. Lei de Littleda Teoria de Filas Número médio de items no sistema Taxa média de chegada Tempo médio de espera de um item no sistema W = L ⁄ λ
- 40. Lei de Littleda Teoria de Filas aplicada ao Desenvolvimento de Software Lead Time = Tasks in Process Average Completion Rate Ocupação Eficiência Velocidade
- 41. Google 20% de tempo“livre”
- 42.
- 43. Prática: Kanban Visualizar todoo trabalho Identificar bloqueios Swarm to solve it! Garantir lead time ao invés de prazo de entrega Limitar Work In Progress (WIP)
- 45. Gestão de Comandoe Controle (C2) “O Sistema Militar de Comando e Controle (SISMC²) do Ministério da Defesa objetiva otimizar o exercício da direção, do controle e da coordenação das forças militares em operação, possibilitando o acompanhamento em tempo real das ações em curso.”
- 46. “Quando você querconstruir um navio, não diga às pessoas pra juntar madeira, cortar pranchas ou distribuir trabalho, mas desperte em cada homem o desejo pela imensidão do mar.” -- Antoine de Saint-Exupéry Prática: Gestão por Comando de Missão
- 48. Prática: Cultivar eCultuar a Cultura Organizacional Respeito Confiança Excelência Alto-desempenho Franqueza Honestidade Escute, pense e aja Dê responsabilidade e propósito Peça desculpas ao invés de permissão Great Workplace = Stunning Colleagues Hire well & fire well... https://hbr.org/2014/01/how-netflix-reinvented-hr
- 49. Referências ❏10+ Deploys PerDay ❏y2u.be/LdOe18KhtT4 ❏What Is DevOps? ❏theagileadmin.com/what-is-devops ❏2014 State of DevOps Report ❏puppetlabs.com/2014-devops-report ❏2015 State of DevOps Report ❏puppetlabs.com/2015-devops-report ❏E mais… ❏diigo.com/user/gnustavo/devops+good ❏goodreads.com/review/list/25759596?shelf=devops
- 50. Dois outros ótimoslivros!
- 51. www.cpqd.com.br Gustavo Chaves gustavo@cpqd.com.br (19) 37057003 go.cpqd.com.br/devops
Notas do Editor
- #3 2ª O’Reilly Velocity Conference. John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering at Flickr. VP de Operações e Diretor de Desenvolvimento, apresentação conjunta, mostrando as práticas técnicas e organizacionais que adotaram para conseguirem fazer 10 deploys por dia!
- #4 Velocity 2011, Jon Jenkins, Diretor de produto na Amazon.
- #5 http://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day http://aalittle.com/continuous-deployments-an-inside-look http://www.wired.com/2013/04/linkedin-software-revolution/ http://highscalability.com/blog/2011/12/12/netflix-developing-deploying-and-supporting-software-accordi.html http://techbeacon.com/10-companies-killing-it-devops
- #8 vazão = throughput latência = lead time
- #9 fluxo = throughput latência = lead time
- #10 “The Visible Ops Handbook outlines how successful technology companies like Etsy, Netflix, Facebook, Amazon.com, Twitter and Google transformed their ITIL practices to implement effective change control.” 2009 John Allspaw e Paul Hammond, 10+ Deploys per day: Dev & ops cooperation at Flicker, Velocity Conference Lean em Sofware tem raízes na Manufatura Lean, também conhecido como Sistema Toyota de produção, que revolucionou o sistema fabril na década de 1980.
- #11 2006
- #12 2013 Uma versão “pra TI” do livro A Meta do Eliyahu M. Goldratt.
- #16 Garanta que o software esteja sempre num estado “releasable”, pra que o deployment seja um “não-evento” que possa ser executado sob demanda, sem rituais complicados.
- #20 Menos Linhas de Produto
- #21 Uma linha de produto
- #24 Quando seus testes encontram um defeito, o problema não termina quando você corrige o código… ele só termina quando você corrige a falha de processo que permitiu que o defeito fosse introduzido no código.
- #27 http://pt.slideshare.net/RandyShoup/goto-aarhus2014-enterprisearchitecturemicroservices
- #28 http://pt.slideshare.net/RandyShoup/goto-aarhus2014-enterprisearchitecturemicroservices
- #32 Desenvolvedores são avaliados pela quantidade de mudanças feitas no produto. Operadores são avaliados pela estabilidade do sistema.
- #36 Todos alinhados em prol do atingimento dos objetivos do negócio.
- #37 http://pt.slideshare.net/RandyShoup/goto-aarhus2014-enterprisearchitecturemicroservices
- #40 John Little, professor do MIT, propôs a lei em 1961. Usado, por exemplo, pra estimar o número de assentos necessários num restaurante a partir da expectativa de tempo médio de refeição e taxa média de chegada de clientes.
- #41 John Little, professor do MIT, propôs a lei em 1961. (Não o Stuart Little!)
- #42 Google’s 20%! Cansei de sugerir melhorias e ouvir desculpas de que “meu time não tem alocação pra isso”... A ideia é que a tão propalada “melhoria contínua” depende de “investimento contínuo”. Nem sempre financeiro… mas certamente de tempo.
- #44 Converse com seu cliente e convença-o a abrir mão do prazo-de-entrega pra você poder lhe dar a gestão de prioridades da fila de entrada e uma garantia de lead time médio e entrega.
- #47 Reed Hastings, CEO da Netflix, diz para os seus gerentes: “Quando você fica tentado a ‘controlar” seu time, pergunte a si mesmo que tipo de ‘contexto’ você poderia lhes passar em vez disso. Você está sendo suficientemente articulado e inspirador ao explicar nossas estratégias e objetivos?”
- #49 Quando eu fui contratado pelo CPqD eu estava muito orgulhoso e satisfeito, porque a imagem que eu e a maioria dos meus colegas tínhamos do CPqD era de uma organização moderna, desenvolvendo tecnologia de ponta. Era onde todos queríamos estar. Contei a história da entrevista na IBM pro meu filho... Hoje ele está orgulhoso e satisfeito de ter sido chamado pra estagiar numa das empresas de TI de Campinas que valorizam e cultuam sua cultura “moderna”. Mas não era só uma imagem que eu tinha do CPqD… o CPqD tem no seu DNA o “desejo” de ser moderno e excelente. Meu primeiro chefe, deu pra mim e pra meu colega, enquanto ainda éramos estagiários, a responsabilidade por um dos projetos mais importantes da nossa área: desenvolver o depurador simbólico que quase todos os desenvolvedores do Trópico-RA usariam, e que usam até hoje. Ele nos fez sentir o peso da responsabilidade mas também a satisfação pela confiança recebida. E depois, quando entregamos a primeira versão do manual de usuário do depurador, com quase 100 páginas ele leu, olhou pra gente e disse com profunda e doída sinceridade: “Eu esperava muito mais de vocês. Refaçam e me tragam de novo.” Aprendemos ali que a qualidade é importante. E que temos que melhorar sempre… E aí? Vamos esperar mais de nós mesmos? http://programmers.stackexchange.com/questions/179616/a-good-programmer-can-be-as-10x-times-more-productive-than-a-mediocre-one