DevOps: Genesis

Introdução

First of all, it’s all about Agile.

A metodologia DevOps foi criada utilizando os conceitos dos métodos Ágeis, para entregar um grande valor durante o processo de desenvolvimento de software, automatizando o release de features com pipelines, para conseguir provar hipóteses mais rápido e assim se adaptar mais rápido às mudanças por meio de uma abordagem “fail-fast”. Essas mudanças são mais culturais do que técnicas, portanto é comum dizer que DevOps é cultura.

A implementação de DevOps acontece por meio da automação de processos, tendo muito forte dentro dessa implementação a reengenharia de processos da empresa. A implementação da parte técnica é simples e fácil se comparada com a mudança de comportamento das pessoas. Portanto, é bastante confuso o papel que um “Engenheiro/Analista DevOps” desempenharia, no meio dessa confusão, existem muitos SysAdmins e Analistas de Infra assumindo o papel de “DevOps”.

First things first, Lean é a base do Agile

A realidade não é tão feliz quanto parece. Depois da segunda guerra mundial, o Japão estava destruído e com poucos recursos, após ter perdido a guerra. Com uma quantia limitada de recursos, o país precisou se reinventar e sobreviver após uma época de forte depressão, durante essa época dois caras ficaram famosos pelo trabalho realizado dentro de uma empresa, que mais tarde teve o nome dedicado ao modelo que foi criado.

Esses caras eram Eiji Toyoda e Taiichi Ohno, que trabalhavam para a Toyota Motor Corporation. Foram os fundadores do modelo de produção Toyota, também conhecido como Toyotismo.

Toyota deu origem ao Lean

Lean é uma metodologia que ensina a otimizar os processos da empresa; end-to-end, para dar mais atenção às tarefas que entregam valor ao consumidor final, incentivando ao máximo a remoção de bottlenecks no processo, assim como a análise de tarefas que são desperdício (definidas pelos 3M) para que sejam identificadas e removidas.

Essas tarefas consideradas desperdício são classificadas como 3M dentro do Lean que representam: Muda, Mura, e Muri. Outro ponto importante a destacar no processo é a utilização do método nomeado Kaizen (continuous improvement), com foco em melhorar continuamente buscando atingir um nível de excelência em qualidade.

A qualidade faz parte da cultura japonesa, pois existe a crença de que um produto de qualidade traz o cliente de volta, mesmo que os produtos demorem mais para estragar, os clientes serão fiéis a eles, pois terão uma boa experiência. Antes mesmo de falarmos sobre user experience, eles já estavam pensando nisso.

Kaizen

Um mindset que ajuda a olhar para cada parte do processo exclusivamente e pensar nas melhorias, envolvendo as pessoas que fazem parte do processo, assim incentiva que haja a inclusão dessas pessoas nas decisões de mudança, já que:

  • Fica muito mais fácil de aceitar uma mudança quando ela não é imposta (top-down);
  • Há uma absorção maior das mudanças pelas pessoas, quando elas são incluídas no processo;
  • As pessoas que são incluídas no processo trazem as suas preocupações e sugestões, que contribuem positivamente com a evolução da mudança, tornando as ideias propostas mais robustas devido ao incentivo em relação à contribuição.

O processo de definição das melhorias por meio de Kaizen acontece (normalmente) na seguinte ordem:

círculo PDCA

  1. Definir objetivos com base em dados;
  2. Revisar o estado atual e desenvolver um plano de melhoria;
  3. Implementar a melhoria;
  4. Revisar a implementação e corrigir o que não funciona;
  5. Reportar os resultados e determinar os itens a serem monitorados.

Esse processo é bastante chamado de PDCA: Plain-Do-Control-Act, que se resume em:

  • Plan (desenvolver a hipótese);
  • Do (executar um experimento);
  • Check (validar os resultados);
  • Act (refinar o experimento e recomeçar).

3M: Muda, Mura, Muri

Muda (desperdício)

Qualquer atividade que consuma tempo sem agregar valor ao consumidor final. Como por exemplo:

  • produção em excesso;
  • tempo parado (ocioso) no processo;
  • defeito nos produtos.

É importante lembrar que existem níveis diferentes de Muda que podem ser ou não removidos com rapidez, e a classificação depende do tempo para remoção.

Um exemplo de Muda mais demorado é a descontinuação de um software legado que acaba tendo ciclos mais longos de release, causando tempo ocioso nos times, muitas vezes uma rotina de testes longa e manual.

Mura (desigualdade)

Atividades que são muito variáveis e imprevisíveis, gerando resultados diferentes em todas as execuções. Por exemplo: a execução de tarefas que não foram bem planejadas e acabam chegando com prazos rígidos. São executadas na correria, gerando um desgaste, desespero, e ainda por cima, ao terminar deixam as pessoas que executaram essas tarefas esperando (seja um feedback, ou então a confirmação de que está finalizado).

Muri (sobrecarga)

Exigir que as pessoas (ou os equipamentos) trabalhem além do limite, para atingir algum tipo de meta ou expectativa, gerando cansaço e consequentemente falhas durante o processo. Essas falhas são geralmente erros humanos causados pelo cansaço durante o trabalho excessivo.

Voltando ao Agile…

No ano 2000 um grupo de 17 pessoas se encontrou em um resort em Oregon para conversar sobre ideias que poderiam melhorar o fluxo de desenvolvimento de software. Depois de um ano de amadurecimento das ideias, essas pessoas se encontraram de novo e publicaram as ideias, que hoje conhecemos como: Agile Manifesto.

Os principais pontos são:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Vou me restringuir a explicação desses pontos com o ponto de vista DevOps, para não fugir (mais) do tema.

Individuals and interactions

over processes and tools

As pessoas devem receber o kit de ferramentas (tooling) apropriado para trabalhar e então serem empoderados para realizar seu trabalho. As interações entre pessoas é extremamente incentivada, para o compartilhamento de conhecimento e também para facilitar o fluxo criativo dentro dos times de desenvolvimento.

Um excelente exemplo de interação incentivada por meio de DevOps é o hábito de code review. Considerando que pequenas partes do software serão iteradas e aprovadas no pipeline passando por diferentes ambientes, de maneira automática, o melhor jeito de prevenir defeitos é por meio de code review.

Esse hábito traz benefício como:

  • Compartilhamento de conhecimento no time;
  • Observação do problema em diferentes pontos de vista;
  • Engajamento no time;
  • Redução no número de bugs.

Working software

over comprehensive documentation

Aqui existe um trick na questão do working software, um software que funciona não é “compilou, tá funcionando”. O software que funciona é o que atende aos requisitos do usuário; i.e. o software que resolve o problema e as dores do usuário.

Como o mercado é muito dinâmico, e evolui com grande velocidade, muitas vezes durante o projeto de desenvolvimento de software os requisitos mudam devido a fatores externos. Portanto, sabendo que não é possível prever todos os fatores, muitas gambiarras são feitas no meio do caminho e documentadas, para que o usuário final aprenda a lidar com as falhas, e executar os workarounds, gastando mais esforço do que seria necessário para realizar as tarefas por meio do software.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo

Incentivando assim que hajam deployments tanto quanto o possível, para que as falhas aconteçam o mais cedo possível, permitindo assim que o impacto delas seja bem menor.

Fail-fast!

As falhas são compreendidas e incentivadas, pois faz parte do mindset entender que:

  • Só erra quem faz;
  • Falhar é o melhor jeito de aprender e evoluir;
  • Shit happens.

Nada como citar a Lei de Murphy para melhor contextualizar

“Se algo pode dar errado, dará.”

Portanto é melhor que as falhas ocorram cedo, enquanto o custo de correção ainda é baixo. Falhar em um ambiente controlado de testes, permite que a correção seja muito mais rápida (e barata) do que seria caso a correção acontecesse já em produção.

Para que essa abordagem tenha sucesso, existe a premissa de que os ambientes sejam cópias de produção, ou pelo menos que seja o mais próximo possível. Do contrário, haverão mudanças de comportamento no software entre os ambientes, inviabilizando o ambiente de testes.

Caso os ambientes sejam divergentes, a promoção de bugs para produção será muito frequente, causando falhas tarde, que são falhas caras.

Customer collaboration

over contract negotiation

Também é possível que haja um má levantamento de requisitos durante o início do projeto, pois muitas vezes o próprio cliente/usuário não conseguiu prever todas as funcionalidades necessárias.

Podemos descrever essa situação como:

  • Do ponto A é possível ver apenas o ponto B;
  • Do ponto B é possível ver o ponto C;

Portanto há um grande incentivo para que o software seja entregue em partes, continuamente. Colhendo assim os feedbacks do usuário sobre os próximos passos, seguindo os conceitos de prototipação evolutiva, que foram muito divulgados por meio do livro The Lean Startup.

Esse ponto faz muito contraste com o anterior, em relação à entrega contínua (continuous release), para que seja possível apresentar o protótipo e evoluir ele ao longo do projeto.

Saiba quem é o seu cliente/consumidor/usuário, e para quem você está fazendo o software, pois esse é o único jeito de conseguir entregar valor para esse cliente. Parte importante do processo de desenvolvimento de software é ser empático com os problemas do usuário, e entender de verdade qual é o problema a ser resolvido, e o resultado causado pelo impacto no desenvolvimento do software (geração do valor para o usuário).

Responding to change

over following a plan

Fazer um redesign dos requisitos durante o projeto é parte crucial para o sucesso do projeto. Será o único jeito de conseguir trazer para a mesa todos os problemas do usuário, e criar a melhor solução para todos esses problemas, pois só o usuário sabe dos reais problemas que ele enfrenta no dia-a-dia lidando com o software.

Com a entrega contínua de software junto com o monitoramento dos resultados, o processo de coleta dos feedbacks fica muito mais simples e rápido.

DevOps, DevOps, DevOps

Com a divulgação da palavra DevOps, existe muita gente falando sobre DevOps por aí. Existindo muita divergência no que é falado, e criando uma confusão grande sobre o tema. Acaba sendo muito comum se deparar com diferentes interpretações sobre o que é DevOps. Existe muito eufemismo na área, e gourmetização em cima do LinkedIn, com muitos SysAdmins por aí se dizendo DevOps, pois aprenderam a codar shell script dentro do Python.

Tá afim de continuar lendo? Dá uma olhada nos benefícios de implementar DevOps.

Matheus Cunha
Matheus Cunha
Engenheiro de Sistemas e Mágico

Apenas um amante de tecnologia empoderando empresas com computação “high-tech” para ajudar na inovação (:

comments powered by Disqus