O documento discute DevOps em grandes empresas, argumentando que é uma realidade e não um mito. Apresenta os principais mitos sobre DevOps e como as empresas podem adotar práticas DevOps através de três caminhos: pensamento sistêmico, ampliação de loops de feedback e cultura de experimentação contínua. Finalmente, mostra dados de pesquisas que indicam que empresas de alto desempenho adotam práticas DevOps.
4. CLOUDMOT ION
Por quê falar de
DevOps?
DEVOPS EM GRANDES EMPRESAS: MITO OU REALIDADE?
5. “50% das empresas na Fortune 500
no ano 2000 foram substituídas por
organizações que usam tecnologia
para entregar valor a seus clientes
mais rápido, melhor, e mais barato.
As Fortune 500 de hoje encontrarão
o mesmo desafio amanhã”
Innosight | Corporate Longevity: Turbulence Ahead
for Large Organizations
Por quê falar de DevOps?
19. 1º. Caminho: “Systems Thinking”
◦ Entender o fluxo de trabalho
(“Understand the flow of work”)
◦ Buscar sempre aumentar o fluxo
(“Always seek to increase flow”)
◦ Nunca passe defeitos conhecidos para a frente
(“Never pass known defects downstream”)
◦ Nunca permitir que otimização local crie
degradação global
(“Never allow local optimization to create global
degradation”)
◦ Alcançar uma compreensão profunda do
sistema
(“Achieve profound understanding of the system”)
20. 2º. Caminho: “Amplify feedback loop”
◦ Encurtar e amplificar os loops de
feedback
(“Shorten and amplify feedback loops”)
◦ Compreender e atender às
necessidades do cliente
(“Understand and meet the needs of the
customer”)
◦ Assegurar-se de que as pessoas têm a
informação que precisam
(“Make sure that people have the information
they need”)
21. 3º. Caminho: "Continual experimentation/Learning”
◦ Cultura de experimentação contínua
(“Culture of continual experimentation”)
◦ Aprendizagem do fracasso
(“Learning of failure”)
◦ A repetição é o pré-requisito para o
domínio
(“Repetition is the prerequisite for mastery”)
22. As quatro métricas-chave
LEAD TIME DEPLOYMENT
FREQUENCY
MEAN TIME TO
RESTORE (MTTR)
CHANGE FAIL
PERCENTAGE
https://www.thoughtworks.com/radar/techniques/four-key-metrics
24. Cultura DevOps
The five keys to a successful Google Team
https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/
DevOpsCulture
https://martinfowler.com/bliki/DevOpsCulture.html
26. Accelerate State
of DevOps
O relatório “Accelerate State of DevOps”
representa seis anos de pesquisa e dados de
mais de 31.000 profissionais em todo o
mundo. É a maior e mais longa pesquisa de
seu tipo, proporcionando uma visão
independente das práticas e capacidades que
impulsionam o alto desempenho.
Disruption affects every industry and no company is safe – we all have heard about the now classic examples of Blockbuster being ousted by Netflix, Lyft & Uber disrupting the traditional taxi industry, and even Twitter changing how we consume news and media.
Half of the companies that were on the Fortune 500 in 2000 are now gone, replaced by organizations that deliver value faster, better, and cheaper than the incumbents did – and the current Fortune 500 very much faces the same fate.
Technology plays a central role in the disruptors‘ ability to execute and out innovate their competition.
Traditional methods of delivering and operating software need re-thinking, especially in a cloud based world.
A business needs to move fast and innovate
But because of the manual nature of deployments and the siloed organizational structures, processes and tools – human error is inevitably introduced which leads to:
High failure rates when changes are implemented and
Long times to recover from outages
In a bid to improve reliability in these situations, we traditionally implement further controls – via more manual processes, and approval gates.
But, this doesn’t improve overall system reliability, and merely introduces:
Long lead times for changes and
Low deployment frequency
DevOps não é algo novo. A palestra que marca o “nascimento” do movimento DevOps é de 2009. Conceitos como o Movimento Lean, o Manifesto Ágil, Agile Infrastructure e outros, nos quais DevOps está amparado, são ainda mais antigos.
DevOps já esteve no pico do “hype” do Gartner, sim. Mas em 2015.
Hoje DevOps é um modelo estabelecido e usado em empresas dos mais diversos segmentos e tamanhos em todos o mundo.
Os princípios e práticas de DevOps são compatíveis com o Agile, com muitos observando que o DevOps é uma continuação lógica da jornada ágil iniciada em 2001. O Agile geralmente serve como um facilitador efetivo do DevOps, devido ao seu foco em equipes pequenas que entregam continuamente código de alta qualidade aos clientes.
Muitas práticas de DevOps emergem se continuarmos a gerenciar nosso trabalho além do objetivo de "código potencialmente implantável" no final de cada iteração, estendendo-o para ter nosso código sempre em um estado implantável.
Muitos vêem DevOps como um golpe no ITIL ou ITSM (IT Service Management), originalmente publicado em 1989. ITIL tem influenciado amplamente várias gerações de praticantes de operações, e é uma biblioteca de práticas em constante evolução destinada a documentar processos e práticas que sustentam as operações de TI.
As práticas de DevOps podem ser feitas de modo a serem compatíveis com o processo ITIL. No entanto, para dar suporte aos prazos de execução mais curtos e às freqüências de implantação mais altas associadas ao DevOps, muitas áreas dos processos ITIL se tornam totalmente automatizadas, resolvendo muitos problemas associados aos processos de configuração e gerenciamento de Release (por exemplo, manter o CMDB atualizado).
E como o DevOps requer detecção e recuperação rápidas quando ocorrerem incidentes de serviço, as disciplinas ITIL de design de serviço, incidente e gerenciamento de problemas permanecem tão relevantes quanto sempre.
A ausência de controles tradicionais (por exemplo, segregação de responsabildiade, processos de aprovação de mudanças, revisões de segurança manual no final do projeto) podem espantar os profissionais de segurança e conformidade da informação.
No entanto, isso não significa que as organizações de DevOps não tenham controles efetivos. Em vez de atividades de segurança e conformidade apenas sendo executadas no final do projeto, os controles são integrados em todas as fases do trabalho diário no ciclo de vida de desenvolvimento de software, resultando em melhores resultados de qualidade, segurança e conformidade.
Muitos interpretam DevOps como a eliminação completa da função Operações de TI (Infraestrutura). No entanto, isso raramente é o caso. Embora a natureza do trabalho de Infraestrutura possa mudar, ele permanece tão importante quanto sempre. O pessoal de Infraestrutura passa a a colaborar muito mais cedo no ciclo de vida do software com os Desenvolvedores, que por sua vez continuam a trabalhar com Infraestrutura muito tempo depois que o código foi implantado em produção.
Em vez de a Infraestrutura fazer trabalho manual que vem de tickets de suporte, DevOps oferece a produtividade aos times por meio de APIs e plataformas de autoatendimento que criam ambientes, testam e implantam código, monitoram e exibem a telemetria de produção e assim por diante.
Ao fazer isso, a equipe de Infraestrutura se torna mais próxima do desenvolvimento (como QA e INFOSEC) e envolvidos no desenvolvimento de produtos, onde o produto é a plataforma que os desenvolvedores usam para testar, implantar e executar seus serviços de ti em produção de forma segura, rápida e segura.
Embora muitos dos modelos de trabalho de DevOps exijam automação, o DevOps também requer normas culturais e uma arquitetura que permitam que as metas compartilhadas sejam alcançadas em todo o fluxo de valor de TI. Isso vai muito além de apenas automação.
Como Christopher Little, um executivo de tecnologia e um dos primeiros cronistas do DevOps, escreveu, "o DevOps não é sobre automação, assim como a astronomia não é sobre telescópios."
Embora muitas histórias de sucesso de DevOps tenham lugar em organizações que usam softwares como o stack LAMP (Linux, Apache, MySQL, PHP), alcançar resultados de DevOps é independente da tecnologia que está sendo usada.
Inúmeros casos de sucesso em .NET, COBOL, Assembly de mainframe (!), SAP e sistemas embarcados (ex.: firmware HP LaserJet).
“Unicórnios” da internet (Google, Amazon, Netflix, Etsy etc.) são pioneiros nas práticas de DevOps
Ainda assim correram o risco, em algum momento, de ficarem para trás por causa dos problemas associados com organizações mais tradicionais:
Lançamentos de código altamente perigosos e propensos a falhas catastrófica
Incapacidade de liberar recursos rápido o suficiente para vencer a concorrência
Incapacidade de escala, altos níveis de desconfiança entre Desenvolvimento e Operações, e assim por diante.
No entanto, cada uma dessas organizações foi capaz de transformar sua arquitetura, práticas técnicas e cultura para criar os resultados incríveis que associamos ao DevOps.
Systems thinking
O primeiro caminho enfatiza o desempenho de todo o sistema, versus o desempenho de um silo específico de trabalho ou departamento. O trabalho pode ser tão grande quanto uma divisão (desenvolvimento ou infraestrutura) ou tão pequeno quanto um contribuidor individual (um desenvolvedor ou um administrador de sistemas).
O foco é em todos os fluxos de valor de negócios, desde quando os requisitos são identificados, passando por desenvolvimento e, em seguida, chegando em produção, onde o valor é entregue ao cliente na forma de um serviço.
Os resultados do primeiro caminho incluem:
Nunca passar um defeito conhecido para centros de trabalho posteriores no processo
Nunca permitir que otimização local crie degradação global
Sempre procurar aumentar o fluxo
Sempre tentar entender profundamente o sistema
Amplify feedback loop
O segundo caminho trata de criar os loops de feedback da direita para a esquerda. Como em quase qualquer iniciativa de melhoria de processo, o objetivo é encurtar e amplificar os loops de feedback, para que as correções necessárias possam ser feitas continuamente.
Os resultados do segundo caminho incluem:
Entender e responder a todos os clientes, internos e externos
Diminuir e amplificar todos os loops de feedback
Integrar conhecimento onde é necessário
Culture of continual experimentation and learning
O terceiro caminho envolve a criação de uma cultura que promove:
Experimentação contínua, que exige correr riscos e aprender com o sucesso e com o fracasso
Entender que repetição e prática são pré-requisitos para dominar algo
Os dois itens acima têm a mesma importância e necessidade. Ambos garante. que você continua se esforçando para melhorar, mesmo que isso signifique entrar na zona de perigo. E você precisa dominar as qualificações que podem ajudar a sair da zona de perigo quando tiver ido fundo demais nela.
Os resultados do terceiro caminho incluem:
Alocar tempo para melhorar o trabalho diário
Criar rituais que recompensam a equipe por correr riscos
Introduzir falhas no sistema para aumentar a resiliência