Infrastructure as Code: como superar problemas com XP

Olá, Habr! Antes, eu reclamava sobre a vida na paradigmas de Infraestrutura como Código e não oferecia soluções para a situação. Hoje, estou de volta para compartilhar quais abordagens e práticas podem ajudar a sair do abismo do desespero e direcionar a situação para o caminho certo.

No artigo anterior Infraestrutura como Código: um primeiro contato Eu compartilhei minhas impressões sobre este campo, tentei refletir sobre a situação atual nesta área e até sugeri que as práticas padrão, conhecidas por todos os desenvolvedores, poderiam ser úteis. Pode ter parecido que havia muitas reclamações sobre a vida, mas não havia propostas para sair da situação.

Quem somos, onde estamos e quais são nossos problemas

Atualmente, estamos na Equipe de Onboarding SRE, composta por seis programadores e três engenheiros de infraestrutura. Todos nós estamos tentando escrever Infraestrutura como Código (IaC). Fazemos isso porque, em princípio, sabemos escrever código e temos um histórico como desenvolvedores de nível "acima da média".

• Temos um conjunto de vantagens: um certo background, conhecimento de práticas, habilidade em programar e vontade de aprender coisas novas.
• E há uma parte deficiente, que é a desvantagem: a falta de conhecimento técnico sobre infraestrutura.

Conjunto de tecnologias que usamos em nosso IaC.

• Terraform para criar recursos.
• Packer para construir imagens. Essas são imagens do Windows e CentOS 7.
• Jsonnet, para fazer uma poderosa compilação no drone.io, assim como para gerar JSON do Packer e nossos módulos do Terraform.
• Azure.
• Ansible na preparação das imagens.
• Python para serviços auxiliares, bem como scripts de provisionamento.
• E tudo isso no VSCode com plugins compartilhados entre os membros da equipe.

A conclusão que tirei foi a seguinte: eu tentei instilar (primeiramente em mim mesmo) otimismo, queria dizer que iríamos tentar as abordagens e práticas que conhecemos para enfrentar as dificuldades e desafios que existem neste campo. do artigo anterior Neste momento, estamos enfrentando os seguintes problemas de IaC:

Imperfeições das ferramentas e meios de desenvolvimento de código.

• Implantação lenta. A infraestrutura é uma parte do mundo real, e ele pode não ser rápido.
• Falta de abordagens e práticas.
• Nós somos novatos e não sabemos muito.
• Programação extrema (XP) vem ao nosso socorro.

A Extremal Programming (XP) vem em auxílio.

Todos os desenvolvedores estão bem familiarizados com a programação extrema (XP) e as práticas que a sustentam. Muitos de nós já trabalhamos com essa abordagem, que foi bem-sucedida. Então, por que não aproveitar os princípios e práticas estabelecidos para enfrentar as dificuldades da infraestrutura? Decidimos aplicar essa abordagem e ver o que resulta.

Verificando a aplicabilidade da abordagem XP à sua áreaApresento uma descrição do ambiente para o qual a XP se encaixa bem e como isso se relaciona conosco:

1. Requisitos de software em mudança dinâmica. Tínhamos clareza sobre qual era o objetivo final. Mas os detalhes podem variar. Nós mesmos decidimos para onde queremos ir, portanto, os requisitos mudam periodicamente (principalmente por nossa própria decisão). Quando se trata da equipe SRE, que faz a automação e também limita os requisitos e o escopo de trabalho, este ponto se aplica bem.

2. Riscos causados por projetos de tempo fixo que usam novas tecnologias. Podemos enfrentar riscos ao usar coisas que não conhecemos. E este é 100% o nosso caso. Todo o nosso projeto é o uso de tecnologias com as quais não estávamos totalmente familiarizados. Isso é um problema constante, pois muitas novas tecnologias surgem continuamente na área de infraestrutura.

3,4. Pequena equipe de desenvolvimento ampliada e co-localizada. A tecnologia que você está usando permite testes unitários e funcionais automatizados. Esses dois pontos não se aplicam totalmente a nós. Primeiro, não somos uma equipe co-localizada; segundo, somos nove pessoas, o que pode ser considerado um grande time. Embora, segundo algumas definições, uma "grande" equipe tenha mais de 14 pessoas.

Vamos considerar algumas práticas da XP e como elas afetam a velocidade e a qualidade do feedback.

O princípio do ciclo de feedback na XP

Na minha compreensão, feedback é a resposta à pergunta: estou fazendo isso corretamente? Estamos indo na direção certa? Na XP, há um esquema divino sobre isso: o ciclo de feedback em tempo. A questão interessante é que quanto mais baixo estamos, mais rapidamente conseguimos obter feedback para responder às perguntas necessárias.

Esse é um tema bastante interessante para discussão, já que na indústria de TI é possível obter feedback rapidamente. Imagine o quanto é doloroso fazer um projeto por seis meses e, só depois, descobrir que no início houve um erro. Isso acontece tanto no design quanto na construção de sistemas complexos.

No nosso caso, IaC nos ajuda com o feedback. Faço uma pequena correção no esquema acima: o plano de lançamento não é um ciclo mensal, mas acontece várias vezes ao dia. Algumas práticas estão atreladas a esse ciclo do SO, que vamos explorar com mais detalhes.

Importante: o feedback pode se tornar a solução para todos os problemas mencionados acima. Em conjunto com as práticas XP, ele pode tirar você do abismo do desespero.

Como se tirar do abismo do desespero: três práticas

Testes

Os testes são mencionados duas vezes no ciclo de feedback XP. Isso não é à toa. Eles são extremamente importantes para toda a técnica de programação extrema.

Presume-se que você tenha testes de Unidade e de Aceitação. Os primeiros oferecem feedback em poucos minutos, enquanto os últimos levam dias para serem escritos e são executados com menos frequência.

Há uma pirâmide clássica de testes que mostra que deve haver mais de certos tipos de testes.

Como esse esquema se aplica ao nosso projeto IaC? Na verdade... não se aplica.

• Embora os testes de Unidade devam ser muitos, não é possível ter um número excessivo deles. Ou eles testam algo de forma bastante indireta. Na prática, podemos dizer que não os escrevemos de fato. Mas aqui estão algumas aplicações para esses testes que nós conseguimos fazer:
  1. Teste de código em jsonnet. Por exemplo, nosso pipeline de construção no drone, que é bastante complexo. O código em jsonnet é bem coberto por testes.
     Nós usamos este Unit testing framework for Jsonnet.
  2. Testes em scripts que são executados ao iniciar o recurso. Scripts em Python, então os testes também podem ser escritos para eles.
• Potencialmente, é possível verificar a configuração nos testes, mas não fazemos assim. Também existe a possibilidade de configurar a verificação das regras de configuração de recursos através da tflint. No entanto, para o Terraform, as verificações são muito básicas, mas muitos cenários de teste foram escritos para AWS. E estamos na Azure, então novamente não serve.
• Testes de integração de componentes: aqui depende de como você os classifica e onde os categoriza. Mas, em princípio, eles funcionam.

  Assim são os testes de integração.

  
  
  Este é um exemplo ao construir imagens no Drone CI. Para alcançá-los, é preciso esperar 30 minutos enquanto a imagem do Packer é construída, depois mais 15 minutos enquanto são executados. Mas eles existem!

  Algoritmo de verificação de imagens

  1. Primeiro, o Packer deve preparar a imagem completamente.
  2. Ao lado do teste, há uma ferramenta Terraform com estado local, que usamos para implantar essa imagem.
  3. Durante a implantação, usamos um pequeno módulo próximo para facilitar o trabalho com a imagem.
  4. Quando a VM é gerada a partir da imagem, é possível iniciar as verificações. Basicamente, as verificações são realizadas na máquina. Verificamos como os scripts funcionaram no início, como os demônios operam. Para isso, acessamos a máquina recém-criada via ssh ou winrm e verificamos o estado da configuração ou se os serviços estão ativos.

• A situação é semelhante com os testes de integração nos módulos do Terraform. Aqui está uma tabela resumida que explica as características desses testes.

  
  
  O feedback no pipeline leva cerca de 40 minutos. Tudo demora muito. Pode ser utilizado para regressão, mas para novos desenvolvimentos é totalmente inviável. Se nos prepararmos muito bem, organizarmos o ambiente e os scripts, podemos reduzir para 10 minutos. Mas isso ainda não é o mesmo que testes unitários, que podem ser feitos em 5 segundos até 100 vezes.

A ausência de testes unitários na construção de imagens ou módulos Terraform leva à transferência do trabalho para serviços separados, que podem ser chamados via REST ou por scripts em Python.

Por exemplo, precisávamos garantir que, ao iniciar uma máquina virtual, ela se registrasse no serviço ScaleFT, e ao destruir a VM, ela se removesse.

Como o ScaleFT é um serviço, somos obrigados a interagir com ele através da API. Foi escrita uma camada que podemos chamar e dizer: 'Entre e remova isso e aquilo'. Ela mantém todas as configurações e acessos necessários.

Agora podemos escrever testes adequados, pois isso não difere de um software comum: simulamos alguma API, você a chama e vemos o que acontece.

Resultados dos testes: o teste unitário, que deveria ser fornecido pelo sistema operacional em um minuto, não o é. Vários tipos de testes em níveis superiores da pirâmide geram efeito, mas resolvem apenas parte dos problemas.

Programação em par

Os testes são, com certeza, algo bom. Pode-se escrever muitos deles, e eles podem ser de diferentes tipos. Eles funcionarão em seus níveis e nos darão feedback. Mas o problema com testes unitários ruins, que oferecem o sistema operacional mais rápido, persiste. Apesar disso, ainda queremos um sistema operacional rápido, que seja fácil e agradável de trabalhar. Sem mencionar a qualidade da solução obtida. Felizmente, existem técnicas que proporcionam feedback ainda mais rápido do que os testes de unidade. Isso é a programação em par.

Ao escrever código, é desejável obter feedback sobre sua qualidade o mais rápido possível. Sim, pode-se escrever tudo em uma branch de recursos (para não quebrar nada para ninguém), fazer um pull request no GitHub, designar alguém cujo parecer é relevante e aguardar uma resposta.

Mas a espera pode ser longa. As pessoas estão todas ocupadas, e a resposta, mesmo que chegue, pode não ser da mais alta qualidade. Suponhamos que a resposta chegue imediatamente, o revisor entendeu instantaneamente toda a intenção, mas a resposta ainda assim chega com atraso, pós-fato. E desejamos antes. É para isso que a programação em par se destina - para que no momento da escrita já tenhamos o feedback.

A seguir, apresento os estilos de programação em par e sua aplicabilidade no trabalho com IaC:

1. Clássico, Experiente + experiente, troca a cada intervalo de tempo definido. Duas funções – driver e navegador. Duas pessoas. Elas trabalham juntas em um único código e trocam de papéis após um intervalo de tempo previamente designado.

Vamos considerar a compatibilidade de nossos problemas com o estilo:

• Problema: imperfeição das ferramentas, meios para desenvolver código.
  Impacto negativo: desenvolvimento mais longo, aceleramos, e o ritmo de trabalho se interrompe.
  Como lidamos: aplicamos outras ferramentas, IDEs compartilhadas e ainda ensinamos atalhos.
• Problema: implantação lenta.
  Impacto negativo: aumenta o tempo para criação de uma parte funcional do código. Ficamos entediados enquanto esperamos, as mãos se arriscam a se envolver em outra coisa enquanto aguardamos.
  Como lidamos: não superamos esse ponto.
• Problema: falta de abordagens e práticas.
  Impacto negativo: não há conhecimento sobre o que é bom e o que é ruim. Isso prolonga a obtenção de feedback.
  Como lidamos: a troca de opiniões e práticas no trabalho em par quase resolve o problema.

O principal problema da aplicação desse estilo em IaC é o ritmo irregular de trabalho. No desenvolvimento tradicional de software, você tem um fluxo muito uniforme. Você pode gastar cinco minutos e escrever N. Gastar 10 minutos e escrever 2N, 15 minutos – 3N. Aqui, você pode gastar cinco minutos e escrever N, e depois gastar mais 30 minutos e escrever um décimo de N. Aqui você nada sabe, fica preso, estagnado. O esclarecimento leva tempo e desvia do ato de programar.

Conclusão: em sua forma pura, não nos serve.

2. Ping-pong. Esta abordagem pressupõe que um participante escreve o teste, enquanto o outro faz a implementação correspondente. Considerando que os testes unitários são complicados e é preciso escrever um teste de integração demorado em termos de programação, toda a leveza do ping-pong se perde.

Posso dizer que tentamos dividir as responsabilidades na elaboração do cenário de teste e na implementação do código correspondente. Um participante elaborava o cenário e, nessa parte do trabalho, ele era responsável, tendo a palavra final. O outro era responsável pela implementação. Isso funcionou bem. A qualidade do cenário aumenta com essa abordagem.

Conclusão: infelizmente, o ritmo de trabalho não permite usar o ping-pong como prática de programação em par em IaC.

3. Strong Style. Uma prática complexa.A ideia é que um participante se torna um navegador diretivo, enquanto o outro assume o papel de um driver executor. Nesse caso, o direito de decisão é exclusivamente do navegador. O driver apenas digita e pode influenciar o que acontece com palavras. Os papéis não mudam por longos períodos.

É muito bom para aprendizagem, mas requer fortes habilidades interpessoais. Aqui, encontramos dificuldades. A técnica foi desafiadora. E não se trata nem mesmo da infraestrutura.

Conclusão: potencialmente pode ser aplicada, não desistimos da tentativa.

4. Mobbing, swarming e todos os estilos conhecidos, mas não listados aqui. não são considerados, pois não experimentamos e não podemos comentar sobre eles no contexto do nosso trabalho.

Resumo geral sobre o uso de programação em par:

• Temos um ritmo de trabalho desigual, que atrapalha.
• Nos deparamos com habilidades interpessoais insuficientes. E o domínio não ajuda a superar essas deficiências.
• Testes longos e problemas com ferramentas tornam o desenvolvimento em par complicado.

5. Apesar disso, também houve sucessos. Criamos nosso próprio método "Convergência - Divergência". Vou descrever de forma breve como funciona.

Temos parceiros constantes por alguns dias (menos de uma semana). Realizamos uma tarefa em conjunto. Passamos um tempo juntos: um escreve, o outro observa, como um time de suporte. Depois nos dispersamos por um tempo, cada um fazendo suas próprias coisas; em seguida, nos reunimos novamente, sincronizamos rapidamente, fazemos algo juntos e nos dispersamos outra vez.

Planejamento e comunicação

O último bloco de práticas, através do qual resolvemos problemas de sistema operacional, é a organização do trabalho com as próprias tarefas. Isso também inclui a troca de experiências que ocorre fora do trabalho em dupla. Vamos considerar três práticas:

1. Tarefas através da árvore de objetivos. A gestão geral do projeto é organizada através de uma árvore que se estende infinitamente para o futuro. Tecnologicamente, a gestão é feita no Miro. Há uma tarefa - ela é um objetivo intermediário. Dela surgem objetivos menores ou grupos de tarefas. A partir deles, surgem as próprias tarefas. Todas as tarefas são criadas e geridas neste quadro.

Este esquema também fornece feedback, que ocorre uma vez por dia, quando sincronizamos em reuniões. A presença de um plano comum, estruturado e totalmente transparente para todos, permite que cada um esteja ciente do que está acontecendo e de quão longe avançamos em nosso progresso.

Vantagens da visão visual das tarefas:

• Causalidade. Cada tarefa leva a um objetivo global. As tarefas são agrupadas por objetivos menores. O domínio da infraestrutura é bastante técnico. Nem sempre fica claro, à primeira vista, qual o impacto específico nos negócios que, por exemplo, a elaboração de um runbook para migração para outro nginx pode ter. Ter ao lado um cartão de objetivo torna isso mais claro.
  
  Causalidade é uma propriedade importante das tarefas. Ela responde diretamente à pergunta: "Estou fazendo a coisa certa?"
• Paralelismo. Somos nove pessoas e não é fisicamente possível que todos se lancem em uma única tarefa. Tarefas de um mesmo domínio também nem sempre são suficientes. Somos forçados a paralelizar o trabalho entre pequenos grupos de trabalho. As equipes ficam focadas em sua tarefa por um tempo e podem ser reforçadas por mais alguém. Às vezes, pessoas dessa equipe se afastam. Alguém sai de férias, outro faz uma apresentação para a conferência DevOps conf, outro escreve um artigo no Habr. Saber quais metas e tarefas podem ser realizadas em paralelo se torna muito importante.

2. Troca de facilitadores nas reuniões matinais. Nos stand-ups surgiu o problema – muitas tarefas são feitas em paralelo. Às vezes, as tarefas estão pouco relacionadas e não há clareza sobre quem está fazendo o quê. A opinião de um membro da equipe é muito importante. É uma informação adicional que pode mudar a resolução da tarefa. Claro, geralmente você tem alguém como parceiro, mas a consulta e dicas nunca são demais.

Para melhorar essa situação, aplicamos a técnica "Troca de Facilitador no Stand-up". Agora eles rotacionam por uma lista específica e isso tem seu efeito. Quando chega sua vez, você é forçado a se aprofundar e entender o que está acontecendo, para conduzir bem a reunião de scrum.

3. Demonstração interna. A ajuda na resolução de tarefas por meio da programação em par, visualização na árvore de tarefas e suporte nas reuniões de scrum pela manhã – é bom, mas não ideal. Em par, você está limitado apenas ao seu conhecimento. A árvore de tarefas ajuda a entender globalmente quem está fazendo o quê. E o facilitador e colegas na reunião matinal não vão se aprofundar em seus problemas. Com certeza podem acabar esquecendo algo.

A solução foi encontrada na demonstração do trabalho realizado uns aos outros e na subsequente discussão. Nos reunimos uma vez por semana por uma hora e mostramos os detalhes das soluções para as tarefas que fizemos na última semana.

Durante a demonstração, é necessário revelar os detalhes da tarefa e obrigatoriamente demonstrar seu funcionamento.

A apresentação pode ser conduzida por um checklist.1. Coloque no contexto. De onde veio a tarefa, por que isso era realmente necessário?

2. Como a tarefa foi resolvida anteriormente? Por exemplo, exigia um clique massivo com o mouse, ou era completamente impossível fazer algo.

3. Como melhoramos isso. Por exemplo: "Olhem, agora temos um script, aqui está o README."

4. Mostre como isso funciona. É preferível realizar um cenário de usuário diretamente. Quero X, faço Y, vejo Z (ou W). Por exemplo, implanto NGINX, verifico a URL, recebo 200 OK. Se a ação demorar, prepare com antecedência para mostrar depois. Idealmente, não quebrar as coisas uma hora antes da demonstração, especialmente se for frágil.

5. Explique quão bem o problema foi resolvido, quais dificuldades ainda existem, o que não foi concluído e quais melhorias são possíveis no futuro. Por exemplo, agora temos CLI, depois haverá automação completa em CI.

É desejável que cada palestrante se limite a 5-10 minutos. Se sua apresentação for significativamente importante e levar mais tempo, combine isso antecipadamente no canal sre-takeover.

Após a parte presencial, sempre haverá uma discussão no thread. É aqui que surge o feedback necessário sobre suas tarefas.

No final, uma pesquisa é realizada para avaliar a utilidade do que ocorreu. Isso já é um feedback sobre o conteúdo da apresentação e a importância da tarefa.

Conclusões longas e o que vem a seguir

Pode parecer que o tom do artigo é um pouco pessimista. Isso não é verdade. Dois níveis básicos de feedback, ou seja, testes e programação em par, funcionam. Não tão perfeitamente quanto no desenvolvimento tradicional, mas o efeito positivo é evidente.

Os testes, em sua forma atual, oferecem apenas uma cobertura parcial do código. Muitas funções de configuração acabam não sendo testadas. Seu impacto imediato ao escrever código é baixo. Contudo, o efeito dos testes de integração é positivo, e são eles que permitem refatorações sem medo. Isso é uma grande conquista. Além disso, com o foco na programação em linguagens de alto nível (para nós, Python e Go), o problema se dissipa. Para o 'cola', muitas verificações não são necessárias, basta a integração geral.

O trabalho em dupla depende mais das pessoas específicas. Há o fator da tarefa e nossas soft skills. Com algumas pessoas, o resultado é excelente; com outras, não tão bom. Há, sem dúvida, benefícios. Está claro que, mesmo com o cumprimento insuficiente das regras de trabalho em par, o simples fato de realizar tarefas conjuntamente tem um impacto positivo na qualidade do resultado. Pessoalmente, trabalhar em dupla é mais fácil e agradável para mim.

Métodos mais avançados de influência no SO - planejamento e gestão de tarefas realmente produzem efeitos: troca de conhecimentos de qualidade e melhoria na qualidade do desenvolvimento.

Resumos curtos em uma linha

• Práticas de XP funcionam em IaC, mas com menor eficiência.
• Fortaleça o que funciona.
• Crie seus próprios mecanismos e práticas compensatórias.

Fonte: habr.com