Conteúdo


DevOps explicado, parte 1

Os três princípios subjacentes

Conteúdos da série:

Esse conteúdo é a parte # de # na série: DevOps explicado, parte 1

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:DevOps explicado, parte 1

Fique ligado em conteúdos adicionais dessa série.

Introdução

Eu estudo organizações de TI com alto desempenho desde 1999. Após fazer um comparativo com mais de 1.500 organizações de TI com alto desempenho, descobri que tinham produtividade 5 a 7 vezes maior que as demais. Esta viagem me levou ao coração do movimento DevOps, sem dúvida um dos acontecimentos mais animadores dos últimos 30 anos na maneira como organizações de TI trabalham.

DevOps geralmente significa o movimento profissional emergente que defende uma colaboração maior entre desenvolvimento e operações de TI. DevOps resulta em um fluxo rápido do trabalho planejado (por exemplo, altas taxas de implementação) e ao mesmo tempo aumenta a confiabilidade, a estabilidade e a segurança do ambiente de produção. Desenvolvimento e operações de TI representam geralmente o fluxo de valor entre os negócios (em que os requisitos são definidos) e o cliente (em que o valor é entregue).

O movimento DevOps teve origem em torno de 2009, durante a convergência de vários movimentos adjacentes que se reforçavam mutuamente:

  • O movimento Velocity Conference, especialmente a importante apresentação 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (consulte Recursos).
  • O movimento "infraestrutura como código" (Mark Burgess e Luke Kanies), o movimento "infraestrutura Agile" (Andrew Shafer) e o movimento de administração do sistema Agile (Patrick DeBois).
  • O movimento de Inicialização Lean (Eric Ries).
  • O movimento de integração e release contínuos (Jez Humble).
  • A ampla disponibilidade de tecnologias de nuvem e de plataforma como serviço (PaaS), como por exemplo Amazon Web Services).

DevOps e Agile

Muitas pessoas se perguntam qual a diferença entre DevOps e desenvolvimento Agile. Um princípio do processo de desenvolvimento Agile é oferecer software funcional em pequenas quantidades e mais frequentes, em vez da abordagem "big bang" do método cascata. Isso fica mais evidente no objetivo Agile de fornecer recursos que podem ser distribuídos ao final de cada sprint — geralmente a cada duas semanas.

Altas taxas de implementação muitas vezes resultam em uma pilha de trabalho a ser implementado por operações de TI. A frase a seguir é atribuída a Clyde Logue, fundador da StreamStep:

"Agile foi essencial para que o desenvolvimento ganhasse novamente a confiança dos negócios, mas sem querer deixou operações de TI para trás. DevOps é uma maneira de os negócios ganharem novamente confiança na organização de TI como um todo."

DevOps complementa especialmente o processo de desenvolvimento do software Agile. DevOps estende e completa o processo contínuo de integração e release garantindo que o código está pronto para produção e que irá proporcionar valor para o cliente.

DevOps permite um fluxo de trabalho muito mais contínuo para Operações de TI. Quando o código não é promovido para produção conforme é desenvolvido, as implementações se acumulam para operações de TI. Se o desenvolvimento gera um código a cada duas semanas, mas ele é implementado apenas a cada dois meses, os clientes não recebem o valor e as implementações resultam muitas vezes em caos e interrupção.

Existe um componente inerente de mudança cultural em DevOps; ele modifica o fluxo de trabalho e as medições locais de desenvolvimento e operações de TI.

DevOps e ITIL/ITSM

Embora muitas pessoas vejam DevOps como reação a IT Infrastructure Library (ITIL) ou gerenciamento de serviço de TI (ITSM), minha opinião é diferente. ITIL e ITSM ainda são as melhores codificações dos processos de negócios que fundamentam operações de TI. Eles descrevem muitos dos recursos necessários para que as operações de TI sustentem um fluxo de trabalho no estilo DevOps.

Agile e integração e release contínuos são as saídas do desenvolvimento, que são as entradas para operações de TI. Para acomodar a cadência mais rápida de releases do DevOps, muitas áreas dos processos ITIL precisam de automação, especificamente em torno de processos de mudança, configuração e release.

O objetivo do DevOps não é apenas aumentar a taxa de mudança. Também pode implementar com êxito recursos na produção sem causar caos e interrupções em outros serviços e, ao mesmo tempo, detectar e corrigir incidentes quando eles ocorrem. Isso traz as disciplinas ITIL de design de serviço e gerenciamento de incidentes e problemas.

Princípios subjacentes do DevOps

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (veja Recursos) descreve os princípios básicos do DevOps, a partir do qual podem ser derivados todos os padrões do método, como "os três caminhos". Eles descrevem os valores e filosofias que enquadram os processos, os procedimentos, as práticas e as etapas prescritivas. A Figura 1 mostra o primeiro caminho, que é o pensamento de sistemas.

Figura 1. O primeiro caminho

O primeiro caminho enfatiza o desempenho de todo o sistema, ao contrário do desempenho de um silo específico de trabalho ou de um departamento. O trabalho pode ser tão grande quanto uma divisão (desenvolvimento ou operações de TI) 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 que a TI permite. Começa quando requisitos são identificados por negócios ou TI, são construídos no desenvolvimento e, em seguida, passam para operações de TI, 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 (segundo Demind)

O segundo caminho, mostrado na Figura 2, trata de criar os loops de feedback da direita para a esquerda. Com quase qualquer iniciativa de melhoria de processo, o objetivo é diminuir e amplificar os loops de feedback, para que as correções necessárias possam ser feitas continuamente.

Figura 2. O segundo caminho

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

O terceiro caminho, mostrado na Figura 3, envolve a criação de uma cultura que promove duas coisas:

  • 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. Experimentar e correr riscos é o que garante que você continua se esforçando para melhorar, mesmo que isso signifique entrar mais do que nunca 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.

Figura 3. O terceiro caminho

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

Conclusão

Na primeira parte desta série, você aprendeu um pouco sobre a história do DevOps, os três princípios subjacentes do movimento e como ele complementa estruturas atuais.

A seguir, continue com a Parte 2, na qual é discutido um padrão específico de DevOps, que garante que código e ambientes funcionem juntos em sprint zero e gerem releases previsíveis e seguros.

Leia mais sobre a história de DevOps, contada por duas pessoas com importante papel na catalisação do movimento: John Willis e Damon Edwards. Leia mais também em The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.


Recursos para download


Temas relacionados

  • The Convergence of DevOps: Veja como DevOps é o ápice de três movimentos impressionantes e significativos.
  • The History of DevOps: Leia um relato em primeira mão da história do DevOps.
  • The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win: Saiba como reconhecer problemas que acontecem em organizações de TI, como esses problemas prejudicam quase qualquer compromisso que os negócios fazem e como técnicas DevOps podem solucioná-los.
  • 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr: A importante apresentação de John Allspaw e Paul Hammond que conta como Flickr alcançou um fluxo maior de recursos e, ao mesmo tempo, manteve um alto nível de estabilidade, confiabilidade e segurança. Os autores falam sobre os benefícios dessa alta taxa de mudança, além da cultura e da tecnologia necessárias para que fosse possível.
  • W. Edwards Deming: Leia sobre Deming na Wikipédia.
  • Avalie produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto online, use-o em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo como implementar Arquitetura Orientada a Serviços eficientemente.
static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=
ArticleID=969499
ArticleTitle=DevOps explicado, parte 1: Os três princípios subjacentes
publish-date=04252014