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.
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
5. 2015 State of DevOps 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 of DevOps 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 o Desempenho 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étricas de 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
10. From Concept to Cash
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 About IT, 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
15. Prática fundamental de DevOps
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 sobre Controle 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
23. “Se seus testes rotineiramente 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 de Có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”
25.
26. Arquitetura Monolítica
simples quando pequeno
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
28. Práticas Técnicas
Put everything under 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
...
29.
30. Alto custo de comunicação entre equipes
UI
Business
Logic
Data Access
Layer
Database
requisitos
arquitetura
implementação
testes
implantação
configuração
infraestruturabanco de dados
37. “An important aspect of 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/
38.
39. Lei de Little da 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 Little da Teoria de Filas
aplicada ao Desenvolvimento de Software
Lead Time =
Tasks in Process
Average Completion Rate
Ocupação
Eficiência
Velocidade
43. Prática: Kanban
Visualizar todo o trabalho
Identificar bloqueios
Swarm to solve it!
Garantir lead time ao invés de prazo de entrega
Limitar Work In Progress (WIP)
44.
45. Gestão de Comando e 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ê quer construir 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
47.
48. Prática: Cultivar e Cultuar 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 Per Day
❏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
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!
Velocity 2011, Jon Jenkins, Diretor de produto na Amazon.
“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.
2006
2013
Uma versão “pra TI” do livro A Meta do Eliyahu M. Goldratt.
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.
Menos Linhas de Produto
Uma linha de produto
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.
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.
John Little, professor do MIT, propôs a lei em 1961. (Não o Stuart Little!)
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.
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.
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?”
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