The Three Ways – princípio das três maneiras

Em continuação aos posts sobre DevOps, o Three Ways é outro importante princípio (mencionado nos principais livros), descrevendo valores e filosofias que estruturam processos, práticas DevOps, bem como as etapas prescritivas. E assim, segue abaixo um resumo do princípio das três maneiras.

Primeira Maneira – Systems Thinking

primeira-maneira

Objetivo: acelerar o fluxo dos desenvolvedores (esquerda) para operações e clientes (direita). 

O foco é na performance do sistema como um todo, não em um específico departamento – silo. E em fluxos de valor de negócios que são ativados pela TI, desde a concepção até o valor entregue ao cliente.

Princípios

  • Tornar o trabalho visível
  • Reduzir os lotes de trabalho
  • Remover desperdícios e foco no cliente
  • Automatização das etapas manuais
  • Limitar WIP
  • Infra as code
  • Práticas de desenvolvimento

Os resultados do The First Way incluem:

  • Não passar um defeito conhecido ao downstream
  • Não permitir a otimização local p/ degradação global
  • Sempre buscar o aumento do fluxo
  • Sempre buscar um conhecimento profundo do sistema

Segunda Maneira – Amplify Feedback Loops
segunda-maneira

Objetivo: estabelecer um processo de feedback em todos os estágios do fluxo de valor (direita para esquerda).

A comunicação forte e monitoramento de infra e aplicações podem eliminar o finger-pointing. Os resultados incluem:

  • Compreender e responder a todos os clientes
  • Feedback loops amplificados e menores
  • Incorporando conhecimento onde é necessário

Princípios

  • GEMBA – management by walking around
  • Telemetria e informação disponível a todos
  • Desenvolvimento por hipóteses e testes A/B
  • Pair programming

Onde em seu processo existe demora desnecessária? Por que precisamos refazer um passo específico?

  • Telemetria
  • Feedback
  • SRE
  • Desenv. por hipóteses e testes A/B
  • Pull request e pair programming

Terceira Maneira – Continual Experimentation and Learning
terceira-maneira

Após dominar as duas primeiras maneiras, você pode agora experimentar e assumir riscos. Envolve a criação de uma cultura que promova:

  • Experimentação contínua (requer assumir riscos e aprendizado com os resultados)
  • Compreensão que repetição e prática são essenciais para o domínio

O propósito é óbvio: você não pode melhorar sem cometer nenhum erro. Os resultados incluem:

  • Dedicação a melhorias no trabalho diário
  • Rituais de recompensas aos times que assumem riscos
  • Introdução de falhas no sistema para aumentar a resiliência
  • Reunião de blameless post-mortem
  • Aprendizado com falhas
  • Chaos Monkey
  • Post Mortem
  • Game Days
  • Descobertas (chat automatizado, etc.)

Práticas de sucesso em DevOps

Nos últimos posts, venho compartilhando fundamentos essenciais de DevOps, tais como: O que é DevOps? Definição, visão e antipatterns | Timeline DevOps e Gartner Hype Cycle | Adotando o DevOps e CALMS | Os benefícios do DevOps | Aprendizagem contínua, cultura livre de culpa e Blameless Postmortems | CI / CD – Continuous integration, delivery and deployment. Vale a leitura destes artigos acima, antes de dar continuidade a leitura deste post.

Já familiarizado com os conceitos acima, outra recomendação que posso compartilhar é o entendimento detalhado de algumas práticas de sucesso em DevOps, das quais resumo abaixo:

  • Blameless postmortemsBlameless é não culpar as pessoas pessoas pelas falhas, sabendo das responsabilidades inerentes da função. Veja mais no artigo.
  • Developers on call: cria um mecanismo de alinhamento, decisão e feedback muito rápido com o time. O artigo de Organizações Exponenciais explora as tecnologias sociais e como escalar rapidamente informações nos times.
  • Andon Cords: conceito utilizado pela Toyota – corda física para parada de linha (empodera qualquer um na linha de produção a parar em caso de problema). Ajuda a formar o senso de qualidade no time.
  • Infra as code: ajuda muito no planejamento do deploy e disaster recovery. Também permite que outras mudanças em DevOps aconteçam em alta velocidade.
  • Blue/Green Deployment: a ideia é ter duas versões idênticas do ambiente de produção (Blue e Green) e assim mitigar o risco em publicações de releases. O resumo do livro Continuous Delivery traz mais detalhes.
  • Incident Command System: o artigo Incident Command for IT: What We Can Learn from the Fire Department aborda como os processos de emergência podem ser aplicáveis a TI – em pequenos e grandes incidentes, já que incidentes acontecem em nossos serviços.
  • Public status pages: serviços vão cair – isso acontece na vida real. A comunicação pode ajudar em melhorar a satisfação do cliente (e manter a confiança) durante as indisponibilidades. Pense nisso!
  • Embedded Teams: gestão do conflito de interesse entre Dev e Ops. Mantenha o time responsável por todo o seu trabalho, ao invés de jogar requisições por cima do muro. Isso permite disciplina e coordenação muito mais próxima para o sucesso do serviço.
  • Dependencie and injection: conexões com serviços externos (database, rest services, etc.) são a fonte da maioria dos problemas de runtime – o Design Pattern “Dependency Injection” foca em como remover estas dependências.
  • Chaos Monkey: oriunda do Simian Army (Netflix) – a autonomia para resolução de problemas dos times, desde o código até a operação de servidores, permite resolver constantemente os problemas com rapidez e precisão. O Simian Army é um software que gera falhas propositalmente (de forma aleatória), criando uma cultura de prontidão a resolução em qualquer questão. E assim, nenhum problema pode ser ignorado.

DevOps Playbook e aplicabilidade organizacional

Metodologias e DevOps

Assim como na gestão ágil, onde podemos utilizar frameworks de apoio as implementações, ou em gestão tradicional, onde podemos utilizar guias de boas práticas para orientar a governança de projetos, em DevOps algumas metodologias vem emergindo para ajudar a sua implementação:

1. Pessoas sobre processos e ferramentas
Elaborada por Alex Honor, recomenda inicialmente definir o responsável por cada atribuição e então definir o processo que precisa acontecer em torno dele. Após isso, selecionar a ferramenta de implementação para realizar o processo.

2. Continuous delivery
Prática de codificar, testar e liberar software frequentemente. Visa melhorar a qualidade e velocidade das entregas.

3. Lean Management
Utilizando pequenos batches de trabalho e limite de WIP (work in progress). O feedback loop e visualização direcionam a organização a melhorar a saída, estabilidade e throughput.

4. Change control
O livro Visible OPS aborda uma forma leve e prática de controle da mudança. Foca em eliminar artefatos frágeis, criar um processo repetível, gerenciar dependências e criar um ambiente de melhoria contínua

5. Infrastructure as code
Em Infra as code, os sistemas são tratados como código nas configurações e automações para provisionar a infraestrutura em seu ambiente corporativo. Trata-se de habilitar a escala, load balance, disponibilidade e performance exigidas por aplicações modernas.

 

Onde se aplica

Gartner já anotava em 2016 que o DevOps irá evoluir para uma estratégia mainstream aplicada por 25% do Global 2000. Michael Cote criou a noção de três grupos que o DevOps se aplica a (e explica esta curva de adoção):

1. Unicorns
Compreende startups, early adopters e trendsetters.

2. Horses
Organização de TI com budget alto, times grandes e escala de problemas.

3. Donkeys
São os profissionais de TI que possuem os problemas em seus processo e adotam o DevOps para ajudar a resolver. Geralmente em times menores e budgets limitados.

O que é DevOps? Definição, visão e antipatterns

Em posts anteriores, compartilhei o Timeline DevOps com os principais marcos que ajudaram na alavancagem das práticas DevOps, também um resumo da Jornada DevOps e seus principais benefícios. Neste post, vamos abordar conceitos iniciais importantes e como evitar algumas “armadilhas” nas implementações.

O ponto inicial é a definição sobre DevOps. Aqui sempre há confusão em relação ao que será implementado, o problema a ser resolvido, as ferramentas utilizadas (DevOps não é somente uso de ferramentas), etc. É importante começar certo! Abaixo, compartilho a definição O que é DevOps de duas das maiores empresas do mundo – Microsoft e AWS.

O que é DevOps

devops-microsoft

By Microsoft

É a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais. A contração de “Dev” e “Ops” refere-se à substituição do Desenvolvimento e Operações em silos para criar equipes multidisciplinares que agora trabalham em conjunto com práticas e ferramentas compartilhadas e eficientes. As práticas essenciais do DevOps incluem planejamento ágil, integração contínua, entrega contínua e monitoramento de aplicativos.

DevOps-AWS

By AWS: é a combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma empresa de distribuir aplicativos e serviços em alta velocidade: otimizando e aperfeiçoando produtos em um ritmo mais rápido do que o das empresas que usam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura. Essa velocidade permite que as empresas atendam melhor aos seus clientes e compitam de modo mais eficaz no mercado.

Em resumo, gosto de compartilhar a seguinte visão consolidada sobre DevOps:

Colaboração e comunicação

Melhorar a colaboração e comunicação entre as equipes de Dev e Ops

Qualidade e segurança

Entrega frequente de valor aos clientes com qualidade e segurança


O que não é DevOps

E como cada área da organização até então entendia DevOps? Tudo isso (desenho abaixo) representa uma visão muito segmentada, ou parcial, sobre o entendimento de DevOps. Por isso, a visão consolidada (comentada anteriormente) é tão importante. É comum, por exemplo, equipes de desenvolvimento associarem práticas DevOps apenas com a automação de tarefas como de build e release.

Leia mais sobre os três pilares DevOps (Pessoas, Processos e Ferramentas): Link 1 | Link 2 | Link 3.

o-que-nao-e-devops

DevOps Tricks

Entre as principais armadilhas das implementações DevOps estão:

  • “I Know DevOps”: como DevOps vai muito além do uso de ferramentas, a cultura organizacional (aprendizado contínuo) e o desenvolvimento do time são essenciais para evitar problemas técnicos e com pessoas (ambiente colaborativo e sem silos).
  • “Immigration is a lot like DevOps, you need containers”: outro erro clássico é simplesmente buscar soluções sem antes verificar a aplicabilidade ao seu ambiente ou até mesmo o nível de maturidade do time para utilizá-las.
  • “What if I told you, DevOps and Agile are not the same thing”: é comum ver em alguns eventos a associação do ciclo Ágil ao DevOps. É uma combinação que pode funcionar muito bem sim, mas não confunda com um depender do outro.
  • “Worked fine in Dev – ops problem now”: o típico erro de gestão de configuração, ambientes e integração contínua. Na máquina do desenvolvedor sempre funciona!

devops-tricks.png


Pipeline de implantação

O termo pipeline é muito utilizado em DevOps, pois é onde está o foco em automatizar os processos e garantir a entrega contínua de aplicações em produção com eficiência e confiabilidade. Em geral, o processo na empresa para lançamento de um produto (ou nova funcionalidade) é:

  1. Visão do produto: o que é esta nova funcionalidade
  2. Time de Dev: realizar o desenvolvimento iterativo e incremental de uma nova versão a cada iteração
  3. Área de operação: implementação e manutenção
  4. Geração de valor para o cliente

pipeline-implantacao.png

O Fluxo de valor cobre desde a concepção do produto até a geração de valor para a empresa. A última milha é extremamente importante neste contexto, pois considera aspectos da entrega do produto, tais como a configuração de ambientes e automação de testes.

As práticas DevOps são essenciais para criar o pipeline de implantação, disponibilizando novas versões de software o tempo todo ao cliente. O Feedback contínuo vai guiando a estratégia da empresa, eliminando barreiras entre os departamentos. Isso permite a colaboração entre as pessoas para gerar valor ao cliente.

Antipatterns DevOps

Antipatterns do Deploy Manual

continuous-delivery
Livro
Continuous
Delivery
(Jez Humble
David Farley)

  • Documentação extensa com os passos a serem seguidos e procedimento de rollback em caso de falha
  • Confiança em testes manuais p/ confirmar o funcionamento das aplicações
  • Correções frequentes na implementação da release
  • Ambientes em cluster com configurações diferentes (por exemplo: servidores de aplicação com diferente connection pool settings, etc.)
  • Releases com resultado imprevisível (e necessitam de frequentes rollbacks para resolver problemas)

Antipatterns de Gestão da Configuração Manual

continuous-deliveryLivro
Continuous
Delivery
(Jez Humble
David Farley)
  • Deploy frequentemente bem sucedido em staging, mas falha no ambiente de produção
  • Demora na preparação de ambiente
  • Impossibilidade de retornar a uma configuração anterior da aplicação (OS, application server, RDBMS, etc).

“In software, when something is painful, the way to reduce the pain is to do it more frequently, not less. So instead of integrating infrequently, we should integrate frequently”.

 

Timeline DevOps e Gartner Hype Cycle

Nos posts recentes, descrevemos alguns cenários de Transformação digital – análise e tendências e os Desafios organizacionais em entrega contínua – time-to-market e exponencial. Evoluir em práticas DevOps é uma prioridade comum para as empresas com foco em crescimento e inovação.

E como surgiu o uso do DevOps nas empresas? Qual era o problema a ser resolvido com a adoção destas práticas? Criei então um timeline com os principais marcos e evoluções que fizeram o DevOps estar presente no Gartner Hype Cycle (em 2015) e na agenda de estratégia das principais empresas.

timeline-devops

  • 2007: primeiras iniciativas em um projeto de migração de data center. Patrick Dubois (Bélgica) propõe a criação de um time de DevOps para melhorar a integração e eficiência entre o time de desenvolvimento e operações, pois havia um grande gargalo um problema na cadeia de entrega.
  • 2008: Patrick Debois apresenta na Agile Conference (Toronto/CA) um modelo para solucionar os conflitos entre as áreas de desenvolvimento e operações de TI, com foco em dar mais agilidade à área de infraestrutura.
  • 2009: Allspaw & Paul Hammond apresentam no Velocity (San Jose/CA) 10+ Deploys per daypropondo um novo modelo operacional para atender as mudanças nos negócios. E assim, mudar a forma: Dev’s job is to add new features; Ops job it to keep the site stable and fast”.
  • 2011-2012: líderes do setor de software (IBM, CA Technologies, etc.) aumentam a presença de DevOps tools no mercado empresarial.
  • 2013: o livro The Phoenix Project, entre outros, traz conceitos de CI (Continuous Integration), CD (Continuous Delivery e Deployment), fundamentais para a propagação das práticas até hoje.
  • 2014: começa a gerar impacto positivo na área de TI – benefícios do DevOps.
  • 2015: presença no Gartner Hype Cycle.

Gartner Hype Cycle
O hype cycle identifica cinco estágio no ciclo de vida tecnológico. Em 2015, o DevOps estava em Peak of Inflated Expectations, fase caracterizada pelo uso de early adapters. E com projeção de 5-10 anos para atingir Plateau of Productivity e assim ser largamente implementada.

hype-cicle-devops

State of DevOps Report
O Report Puppet Labs indica que times utilizando práticas DevOps:

  • Aumentaram a frequência dos deploys em 30 x
  • Com lead time reduzido em 200 x
  • Qualidade: redução em 60 x de falhas
  • Recuperação de problemas 168 x mais rápido

state-of-report-devops-2015.jpg.png* esta pesquisa considerou empresas de diferentes tamanhos e segmentos.

Por que as empresas investem em DevOps? E o problema a ser resolvido

Além de lidar com os Desafios organizacionais em entrega contínua – time-to-market e exponencial, as empresas também recorrem as práticas DevOps para manterem-se competitivas em Continuous Delivery, disponibilizando novas releases o tempo todo no mercado para validação de hipóteses (conceito explorado no Build-Measure-Learn-Loop do Lean Startup).

Mesmo em cenários completamente diferentes, as startups e as empresas grandes realizam análise financeira (de acordo com o seu modelo) para justificar o investimento em novas iniciativas. Para criar novos produtos, o racional geralmente é justificado pela aquisição de novos clientes, aumento de receita, market share, entre outros.

Já em investimentos que visam melhorias nos processos internos, como por exemplo, métodos ágeis e práticas DevOps, as empresas se deparam com a seguinte pergunta: qual o problema a ser resolvido? Muitas vezes são retornos qualitativos, necessários para aumentar o valor do negócio.

O problema a ser resolvido
As empresas tradicionalmente possuíam na área de TI uma equipe de operações com a responsabilidade de manter os ambientes estáveis e resilientes (qualquer alteração deve ser feita com muito cuidado). E outra equipe de desenvolvimento que precisa responder rapidamente às necessidades do negócio. E ambas precisam contribuir para o sucesso do negócio!

devops-problema-ser-resolvido

Entre os principais problemas de equipes que não adotaram DevOps estão:

bug-fix▫Erro manual é comumente identificado com causa raiz

▫Defeitos são liberados a produção, causando interrupções

▫Incapacidade de diagnosticar problemas em produção rapidamente

▫Problemas em um ambiente específico

▫Blame shifting / finger pointing

▫Dificuldade em colocar releases em produção

E por que as empresas investem em DevOps?
O  TechValidate traz alguns estudos de caso de grandes empresas, tais como Grupo Boticário, Santander e HMS. Ele descreve os desafios e resultados de cada organização ao adotar práticas DevOps. Na imagem abaixo, os principais motivos do Boticário e Santander estarem investindo em transformação com DevOps:

investimento-devops
Fonte: https://www.techvalidate.com/product-research/ca-devops/case-studies

Diagrama de Kano

No último post, abordamos os desafios organizacionais em entrega contínua – time-to-market e exponencial, e conceitos importantes das organizações exponenciais, tais como  PMT (Propósito Máximo de Transformação) e Value Vs Waste.

Ainda sobre os conceitos de crescimento exponencial e entrega contínua de valor, o Diagrama de Kano, famosa teoria de  desenvolvimento de produtos e satisfação do cliente, encoraja a abordagem “menos é mais”.

O ponto é que a adição de novos recursos (para um produto) pode ser dispendiosa e apenas aumentar a complexidade sem aumentar a satisfação do cliente. Então, o Diagrama de Kano ajuda a categorizar e priorizar os diferentes atributos de desempenho de um produto ou serviço.

diagrama-kano.jpg

Esta análise é muito poderosa para a priorização, pois ajuda a identificar o nível de importância de cada funcionalidade para o seu cliente. Entre as categorias de desempenho estão:

  • Funcionalidades Obrigatórias: normalmente o cliente já considera como parte do produto ou serviço. A ausência destas funcionalidades deixa o cliente insatisfeito ou sem sentido o uso.

  • Funcionalidades Lineares: a satisfação do cliente é proporcional à quantidade de funcionalidades disponíveis. E assim, a satisfação do cliente é maior com mais funcionalidades deste tipo.
  • Funcionalidades Atrativas: influenciam mais na satisfação do cliente, porém dificilmente são explicitados pelo cliente. Representam um diferencial para a fidelização do cliente, pois proporcionam uma maior satisfação.

Pergunte aos clientes o que realmente eles valorizam. Um brainstorming de todos os recursos (do produto ou serviço) é uma boa dinâmica, classificando em:

  • Must to have
  • Quanto mais melhor
  • Atributos encantadores
  • Não relevante

Em suma, vimos como o Diagrama de Kano pode ajudar na priorização do desenvolvimento de novas funcionalidades. Em organizações que vivem transformação digital, com entregas contínuas de valor (benefícios obtidos com DevOps), isso é essencial para colocar no pipeline funcionalidades que aumentam a satisfação do cliente.