DevOps: Motivo e como fazer
- Motivo
- O que é
- Agir
- Fluxo
- Feedback
- Melhoria continua
- Conclusão
Motivo
Muitas empresas e muitos colegas de profissão tem falado sobre a cultura DevOps nas organizações e resolvi estudar o assunto para entender o motivo e como fazer isto acontecer. Engraçado que o motivo é bem simples porém desafiador:
Entregar valor para o cliente em uma velocidade maior e com qualidade.
Mas porque então adotar a cultura DevOps? Minha empresa já entrega e tem velocidade:
Empresas que adotam DevOps entregam mais rápido, entregam mais e são mais competitivas que empresas que não adotam, ou seja ganham mais $$.
Então já sabemos o motivo, agora vamos saber o que é DevOps.
O que é??
DevOps é a junção da sigla desenvolvimento e operações de sistemas. O desenvolvimento é a construção do sistema, do levantamento da necessidade até o sistema ficar pronto e depois este pacote é passado para o time de operações para implantar nos ambientes de testes, homologação e produção e manter em produção.
Até então não vi nenhum problema nisto, normal este fluxo. Mas se formos analisar com calma temos:
Um único produto que dois times com atribuições distintas trabalham de forma isolada para entregar valor para o cliente. Então de quem é a responsabilidade da entrega para o cliente?
Neste formato, quando acontece qualquer problema no ambiente, operações fala que a culpa é de desenvolvimento e desenvolvimento fala que a culpa é de operações pois afinal de quem é a responsabilidade do produto?
Desta forma a cada iteração deste tipo entre as equipes gera um tempo maior para entregar valor para o cliente, que gera custo, que gera stress…
E você deve está se perguntando, opa se é DevOps é sinal que perceberam que se tanto dev quanto operações trabalhassem em conjunto e a responsabilidade do produto fosse de ambos, geraria valor mais rápido, entregas e menos custo.
Masss, isso não é fácil? É só chamar o pessoal de dev e operações e colocar na mesma sala e falar: O produto é nosso e vamos entregar juntos, estamos juntos nessa!
Você acha mesmo que empresas que trabalham anos em silos entre operação e desenvolvimento vão mudar sua cultura assim?
Você entra na casa da sua vó que usa forno a lenha a 20 anos e fala pra ela que existe o forno elétrico que faz a comida bem mais rápido, ela vai acreditar tão fácil assim? Acho que você vai ter que convence-la fazendo alguns pratos!
É isto que vamos fazer agora, vamos fazer um prato, ops!! Vamos demonstrar que desenvolvimento e operações atuando em conjunto em prol do produto, gera produtos mais rapidamente e com qualidade.
Agir
O DevOps é uma cultura e deste modo temos um conjunto de valores, técnicas e filosofias para que isto de fato aconteça. DevOps é:
- Colaboração entre desenvolvimento e operação.
- Adotar as três maneiras: fluxo, feedback e melhoria continua.
Para iniciar a aplicação desta cultura em uma organização precisamos escolher um fluxo que esteja gerando desperdício e que aconteça entre desenvolvimento e operações ou pode ser entre outras áreas da empresa, no inicio da prática escolha um fluxo mais simples e com o tempo pegue outros para melhorar. Comece pequeno e logo que organização ver algum ganho, outros maiores podem ser feitos.
Agora vamos desenhar nosso mapa de fluxo de valor, ou seja vamos desenhar todas as atividades que ocorrem entre as áreas para que o produto seja entregue para o cliente, após isto vamos identificar onde estão os gargalos, eficiência deste fluxo.
Após esta identificação vamos adotar a cultura e valores DevOps neste fluxo para diminuir desperdícios e agregar valor para o cliente.
O fluxo que escolhi para melhorarmos:
Entrega de uma funcionalidade nova em produção de um sistema.
A ideia é identificarmos cada vez mais fluxos que gerem desperdício na organização e ir adotando as práticas DevOps para realizar a melhoria.
Então fiz o mapeamento das atividades deste fluxo e ficou assim:

Agora vamos identificar neste processo:
Lead time: O tempo total que o cliente enviou a solicitação da funcionalidade e foi entregue pra ele. Neste caso vamos somar o work time que é o tempo efetivamente trabalhado na atividade mais o tempo de espera em cada atividade. Neste caso:
50 dias de lead time.
19 dias de tempo trabalhado(work time)
Percentual de precisão: Quando o trabalho passa de uma atividade para outra no fluxo, qual o feedback deste input(trabalho realizado) ?
Por exemplo: 10% das vezes o time de operações recebe o pacote para implantar sem nenhum erro, ou seja a equipe de operações constantemente volta o pacote para desenvolvimento corrigir. Isto é desperdício, gera tempo! Precisa ser melhorado.
Percentual de eficiência: É a divisão entre (process time/lead time) * 100. Com isto chegamos ao percentual de eficiência, ou seja:
(19/50) * 100 = 38% de eficiência
Acho que podemos melhorar este fluxo!
E agora, sabendo do percentual de eficiência deste fluxo, onde está o gargalo, agora é hora de aplicar as “maneiras” de fazer DevOps no nosso fluxo de valor para melhorar, precisamos conhece-las primeiro e adotar o que diminuiria os gargalos no nosso fluxo. Vamos la!
Maneira: Fluxo

O fluxo é uma das maneiras para se adotar DevOps e ela representa a fase da passagem do código de desenvolvimento para operações e de que maneira isto deve ser executado para que não gere desperdício e não gere gargalos. Nesta maneira envolve as técnicas:
- Controle de versão: Repositório que contém nosso código fonte e possui todas as alterações feitas pelos desenvolvedores. É o ponto de partida para iniciar nosso fluxo de entrega.

- Testes automatizados: Sem testes fica difícil e até mesmo inviável adotar as praticas DevOps, como vamos ter confiança no fluxo automático sem testes automatizados? Se tivermos uma equipe de QA vamos gerar lentidão no processo.

- Tratar infraestrutura como código: Quando desenvolvimento pede uma máquina para operação existe um tempo para que operação crie esta máquina, é alocada uma pessoa para realizar este trabalho e com isto demora dias até que o ambiente fique pronto e entregue para desenvolvimento utilizar. Com a infra como um código o desenvolvedor pode versionar o código que monta a infraestrutura, deste modo o ambiente pode ser recriado de forma fácil pelo próprio dev. Se sua máquina for invadida por alguém? Simples reconstrua o ambiente a partir do código de infra! Se alguém de operação precisa criar muitas máquinas ao mesmo tempo? Será na mão? Não, usa infra como um código. Beleza não?
- Integração continua: Processo que gera o pacote da aplicação de forma automática executando testes unitários, caso o teste unitário não passe, este pacote é desconsiderado e o desenvolvedor recebe o feedback rápido.

- Entrega continua: Utiliza do pacote gerado na integração continua para realizar a entrega no ambiente.
- Implantação continua: Realiza o deploy do pacote gerado direto em produção automaticamente.
- Pipeline de implantação: Todas as etapas do fluxo para levar seu software para produção são automatizadas, ou seja com essa automatização é possível executar mais deploys pois se está tudo automatizado existe confiança no processo, feedback mais rápido, quando isto é feito de forma manual gera mais preocupações e mais etapas, o pipeline de implantação utiliza a integração continua, entrega continua e implantação continua. Abaixo está um exemplo de um pipeline de implantação:

E quais praticas vamos adotar no nosso fluxo de valor para a maneira Fluxo?
Na atividade que dev passa o pacote para operação que demora 5 dias para ser atendido na fila em teste e 3 dias para colocar em homologação podemos aplicar o pipeline de implantação utilizando Jenkins, GitLab que são ferramentas que permitem a construção do pipeline automatizado. Deste modo dev pode aplicar o pacote sem abrir uma solicitação para operação e recebe o feedback no momento em que inicia o pipeline.
Na atividade de teste manual do dev ou do usuário em homologação é possível a criação de teste automatizados para gerar feedback rápido de problemas que podem ser tratados logo no inicio do processo, quando a atividade precisa ser refeita no processo isto gera tempo e custo.
Dev ou operação podem criar o código de infraestrutura e deste modo a criação de um ambiente novo de teste ou hmg pode ser feito em menos tempo.
Maneira: Feedback

Legal, temos um fluxo automatizado para entregar funcionalidade para o nosso cliente bem mais rápido do que estava antes, fazemos mais deploy em produção e ganhamos bastante confiança, mas recebemos uma noticia ruim, nossa funcionalidade recebeu muitos ataques e a máquina caiu! Recebemos a noticia da queda através dos nossos clientes, fomos reativos, ou seja só depois que aconteceu o problema atuamos nele. O que isso gera? Insatisfação do cliente, serviço fora = dinheiro perdido, desperdício. A maneira feedback possui práticas para recebemos feedback de forma proativa, ou seja, neste caso quando a máquina atingisse um aumento de requisições fora do padrão, deveríamos ter sido notificados e atuado de maneira tranquila sem indisponibilidade do serviço. Quais praticas podemos usar:
Telemetria: O produto deve ser monitorado e são enviadas informações para algum serviço de visualização destas informações, para que tanto devs quanto ops possam ver como aplicação se comporta e ser proativo a determinados eventos. Esta visualização deve ser pública para ambos e o que medir deve ser conversado também, pode ser monitorado cpu, memoria dentre outros.
Contextual inquiry: É observar como o cliente está usando a aplicação, afim de coletar feedbacks relacionados ao uso da aplicação, problemas de usabilidade, lentidões, impressões. Deste modo, podemos ver grau de insatisfação e adotamos uma postura mais proativa de resolver os problemas, pois vimos os usuários de fato com problemas e não é um ticket em uma fila. Realmente vimos a necessidade e damos nosso melhor!
Revisão de código: Com esta prática outros desenvolvedores revisão seu código em busca de problemas e enviam a correção, gerando feedback rápido no processo.
Programação por pares: Pratica adotada onde dois programadores, um escreve e o outro guia.
Teste A/B: Técnica utilizada para medir o nível de aceitação do usuário, liberamos um conjunto de funcionalidades pra determinados usuários e medimos se foi bem aceito.
Podemos adotar feedback no nosso fluxo de valor? Como?
Quando colocarmos a nova funcionalidade em produção precisamos a checar a sáude da aplicação, memoria, cpu, métricas referente a aplicação pra isso podemos utilizar a ferramenta Nagios que faz este tipo de monitoramento da aplicação.

Maneira: Aprendizado e experimentação continua

Esta maneira é relacionada a capacidade da aplicação se recuperar após acontecer determinado incidente, por exemplo, uma queda, uma determinada funcionalidade parou de funcionar e agora? Ou seja nossas aplicações devem ser resilientes. Nossa aplicação consegue identificar o problema e executar uma determinada ação sem que deixe de gerar valor para o nosso cliente?
Imagine se o carrinho de compras de um e-commerce parar de funcionar e toda loja caísse? Neste caso muitos e-commerce aprenderam que isto pode acontecer e tornaram esse serviço resiliente, mas como? Podem ter adotado algum tipo de cache, o importante é que aprenderam e foram resilientes e conseguiram manter seus preciosos clientes navegando. Mas quais são as práticas DevOps para esta maneira?
Reuniões de lições aprendidas: A cada queda de um serviço ou erro em produção, não culpe e julgue, marque uma reunião e aprenda em conjunto com a equipe qual foi o erro e como foi tratado.
Dias de jogo: É marcado um dia no qual a equipe tenta quebrar e identificar problemas na aplicação de alguma maneira e se conseguir quebrar o sistema? que bom! Mais aprendizado!
Conclusão
Vimos que DevOps não é só criar um pipeline de implantação no Jenkins, ter o código versionado no git, existe um conjunto de práticas como mapear fluxo de valor, reuniões de lições aprendidas, dias de jogos, contextual inquiry, definir a telemetria em conjunto e que no final o objetivo é entregar valor para o cliente mais rápido, com qualidade e mais vezes.
