Infraestrutura como código: como superar problemas com o XP

Olá Habr! Anteriormente, reclamei da vida na infraestrutura como paradigma de código e não ofereci nada para resolver essa situação. Hoje voltei para lhe dizer quais abordagens e práticas ajudarão a romper o abismo do desespero e colocar a situação no caminho certo.



No artigo anterior “Infraestrutura como código: primeiro conhecimento” , compartilhei minha impressão sobre essa área, tentei refletir sobre a situação atual nessa área e até sugeri que práticas padrão conhecidas por todos os desenvolvedores possam ajudar. Pode parecer que houve muitas reclamações sobre a vida, mas não houve propostas para sair dessa situação.

Quem somos, onde estamos e que problemas temos

Agora estamos na equipe de integração de 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, somos capazes de escrever código e, no histórico, somos desenvolvedores do nível "acima da média".

• Temos um conjunto de vantagens: um certo histórico, conhecimento de práticas, capacidade de escrever código, desejo de aprender coisas novas.
• E há uma parte frouxa, também é um sinal de menos: falta de conhecimento sobre o material de infraestrutura.

A conclusão do meu último artigo foi a seguinte: tentei inspirar otimismo (principalmente em mim mesmo), queria dizer que tentaremos as abordagens e práticas conhecidas por nós para lidar com as dificuldades e dificuldades existentes nessa área.

Agora estamos lutando com esses problemas de IaC:

• Imperfeição de ferramentas, ferramentas de desenvolvimento de código.
• Implantação lenta. A infraestrutura faz parte do mundo real e pode ser lenta.
• Falta de abordagens e práticas.
• Somos novos e não sabemos muito.

Extreme Programming (XP) para o resgate

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


Vejamos algumas práticas do XP e como elas afetam a velocidade e a qualidade do feedback.

Princípio do loop de feedback XP

No meu entendimento, o feedback é a resposta para a pergunta, estou indo bem, vamos para lá? No XP, existe um pequeno esquema divino a esse respeito: um loop de feedback de tempo. O interessante é que, quanto mais baixo, mais rápido conseguimos obter um sistema operacional para responder às perguntas necessárias.



Este é um tópico bastante interessante para discussão: em nosso setor de TI é possível obter rapidamente um sistema operacional. Imagine como é doloroso fazer um projeto por meio ano e só então descubra que um erro foi cometido no início. Isso acontece no design e em qualquer construção de sistemas complexos.

No nosso caso, o IaC nos ajuda a obter feedback. Imediatamente, faço um pequeno ajuste no diagrama acima: não temos um plano de liberação mensal, mas acontece várias vezes ao dia. Algumas práticas estão vinculadas a esse ciclo do SO, que examinaremos em mais detalhes.

Importante: o feedback pode ser a solução para todos os problemas mencionados acima. Juntamente com as práticas XP, ele pode tirar o desespero do abismo.

Como sair do abismo do desespero: três práticas

Testes

Os testes são mencionados duas vezes no ciclo de feedback do XP. Não é só isso. Eles são extremamente importantes para todas as técnicas extremas de programação.

Supõe-se que você tenha testes de unidade e aceitação. Alguns fornecem feedback em alguns minutos, outros em alguns dias, porque são escritos por mais tempo e são executados com menos frequência.

Existe uma pirâmide de teste clássica, que mostra que deve haver mais testes.



Como esse esquema se aplica a nós em um projeto de IaC? Na verdade ... nada.

• Os testes de unidade, apesar de haver muitos deles, não podem ser muitos. Ou eles estão indiretamente testando algo. De fato, podemos dizer que não os escrevemos. Mas aqui estão algumas aplicações para esses testes, que ainda conseguimos fazer:
  
  
  1. Teste de código no jsonnet. Este, por exemplo, é o nosso conjunto de tubulações em drones, o que é bastante complicado. O código jsonnet é bem coberto por testes.
     Usamos essa estrutura de teste de unidade para Jsonnet .
  2. Testa scripts que são executados quando o recurso é iniciado. Os scripts em Python e, portanto, os testes para eles, podem ser gravados.
• A verificação da configuração nos testes é potencialmente possível, mas não o fazemos. Também é possível configurar a verificação das regras de configuração de recursos através do tflint . No entanto, apenas para terraform, há verificações muito básicas, mas muitos scripts de teste são escritos para a AWS. E estamos no Azure, então isso não é adequado novamente.
• Testes de integração de componentes: depende de como você os classifica e de onde os coloca. Mas eles basicamente funcionam.
  
  É assim que os testes de integração são.
  
  
  
  Este é um exemplo ao montar imagens no Drone CI. Para alcançá-los, é necessário aguardar 30 minutos para a imagem do Packer se reunir e aguardar mais 15 minutos para que eles passem. Mas eles são!
  
  
  Algoritmo de validação de imagem

  1. Primeiro, o Packer deve preparar a imagem completamente.
  2. Ao lado do teste, há uma terraform com um estado local, com o qual implantamos essa imagem.
  3. Ao implantar, um pequeno módulo é usado ao lado dele, para facilitar o trabalho com a imagem.
  4. Quando a VM é implantada a partir da imagem, você pode começar a verificar. Principalmente as verificações são realizadas de carro. Ele verifica como os scripts funcionavam na inicialização, como os daemons funcionam. Para fazer isso, através do ssh ou winrm, vamos à máquina que acabou de ser criada e verificamos o status da configuração ou se os serviços aumentaram.

  
  
• Uma situação semelhante com testes de integração e em módulos para terraform. Aqui está uma breve tabela explicando os recursos de tais testes.
  
  
  
  Feedback do pipeline na área de 40 minutos. Tudo leva muito tempo. Pode ser usado para regressão, mas para um novo desenvolvimento é geralmente irreal. Se você realmente se preparar para isso, preparar scripts em execução, poderá reduzi-lo para 10 minutos. Mas ainda não são testes de unidade, que são 100 peças em 5 segundos.

A ausência de testes de unidade durante a montagem de imagens ou módulos da terraform incentiva a mudança do trabalho para serviços separados que podem ser simplesmente puxados pelo REST ou para scripts Python.

Por exemplo, precisávamos fazer com que, quando a máquina virtual fosse iniciada , ela se registrasse no serviço ScaleFT e, quando destruída, se excluísse.

Como o ScaleFT é um serviço, somos forçados a trabalhar com ele por meio da API. Havia um invólucro que você pode puxar e dizer: "Entre e exclua isso, aquilo". Ele armazena todas as configurações e acessos necessários.

Já podemos escrever testes normais para isso, uma vez que não difere de forma alguma do software comum: alguns apiha se molham, você puxa e olha o que acontece.

Resultados do teste: O teste de unidade, que deve fornecer o sistema operacional em um minuto, não fornece. E tipos mais altos de teste na pirâmide produzem efeito, mas apenas uma parte dos problemas é coberta.

Programação em par

Os testes são, obviamente, bons. Você pode escrever muitos deles, eles podem ser de tipos diferentes. Eles trabalharão em seus níveis e nos darão feedback. Mas o problema com testes de unidade ruins, que oferecem o sistema operacional mais rápido, permanece. Ao mesmo tempo, ele continua desejando um sistema operacional rápido, é fácil e agradável trabalhar com ele. Sem mencionar a qualidade da solução. Felizmente, existem técnicas para fornecer feedback ainda mais rápido que os testes de unidade. Isso é programação em pares.

Ao escrever um código, quero obter feedback sobre sua qualidade o mais rápido possível. Sim, você pode escrever tudo no ramo de recursos (para não quebrar nada com ninguém), fazer uma solicitação pull no github, atribuí-la a alguém cuja opinião tenha peso e aguardar uma resposta.

Mas você pode esperar muito tempo. As pessoas estão todas ocupadas, e a resposta, mesmo que seja, pode não ser a melhor em qualidade. Suponha que a resposta veio imediatamente, o revisor entendeu instantaneamente toda a ideia, mas a resposta ainda vem tardiamente, depois do fato. Mas eu quero algo mais cedo. Aqui está a programação em pares e visa a isso - de modo que imediatamente, no momento da redação.

A seguir, são apresentados os estilos de programação de pares e sua aplicabilidade no trabalho em IaC:

1. Clássico, experiente + experiente, mudança de temporizador. Dois papéis - motorista e navegador. Duas pessoas Eles trabalham em um código e alteram as funções após um determinado período de tempo predeterminado.

Considere a compatibilidade dos nossos problemas com o estilo:

• Problema: imperfeição de ferramentas, ferramentas para desenvolvimento de código.
  Impacto negativo: para desenvolver por mais tempo, desaceleramos, o ritmo / ritmo do trabalho se desvia.
  Como combater: usamos outro ajuste, um IDE comum e ainda aprendemos atalhos.
• Problema: Implantação Lenta.
  Impacto negativo: aumenta o tempo para criar um código de trabalho. Sentimos falta enquanto esperamos, mãos são atraídas para fazer outra coisa enquanto você espera.
  Como lutar: não superou.
• Problema: falta de abordagens e práticas.
  Efeito negativo: não há conhecimento de como fazer o bem, mas quão ruim. Estende feedback.
  Como lutar: a troca de opiniões e práticas no emparelhamento quase resolve o problema.

O principal problema com a aplicação desse estilo ao IaC em um ritmo desigual. No desenvolvimento de software tradicional, você tem um movimento muito uniforme. Você pode gastar cinco minutos e escrever N. Gaste 10 minutos e escreva 2N, 15 minutos - 3N. Aqui você pode gastar cinco minutos e escrever N, e depois gastar outros 30 minutos e escrever um décimo de N. Aqui você não sabe nada, tem uma piada, um idiota. O julgamento leva tempo e distrai a própria programação.

Conclusão: em sua forma pura não nos convém.

2. Pingue-pongue. Essa abordagem pressupõe que um participante esteja escrevendo um teste e o outro fazendo uma implementação para ele. Dado que tudo é complicado com os testes de unidade e você precisa escrever um longo teste de integração, a facilidade do ping-pong se foi.

Posso dizer que tentamos separar responsabilidades para projetar um script de teste e implementar o código para ele. Um participante veio com um roteiro, nesta parte do trabalho que ele era responsável, ele tinha a última palavra. E o outro foi responsável pela implementação. Funcionou bem. A qualidade do cenário com essa abordagem aumenta.

Conclusão: infelizmente, o ritmo do trabalho não permite o uso de pingue-pongue, como prática de programação em pares no IaC.

3. Estilo forte. Prática difícil . A idéia é que um participante se torne um navegador de diretório e o segundo assuma o papel de um driver em execução. Nesse caso, o direito de tomar decisões exclusivamente com o navegador. O driver apenas imprime e em uma palavra pode afetar o que está acontecendo. As funções não mudam por muito tempo.

Adequado para treinamento, mas requer fortes habilidades sociais. Por isso, vacilamos. A técnica foi difícil. E o ponto aqui não é nem infraestrutura.

Conclusão: potencialmente pode ser aplicado, não desistimos de tentativas.

4. Mobbing, enxame e todos os estilos conhecidos, mas não listados aqui, não são considerados, porque não tentei dizer sobre isso no contexto do nosso trabalho não vai funcionar.

Resultados gerais sobre o uso da programação em pares:

• Temos um ritmo de trabalho desigual, que derruba.
• Tivemos habilidades pessoais insuficientemente boas. E a área de assunto não contribui para superar essas deficiências.
• Testes longos, problemas com ferramentas tornam o desenvolvimento de pares viscoso.

5. Apesar disso, houve sucessos. Criamos nosso próprio método de convergência - divergência. Descreverei brevemente como funciona.

Temos parceiros regulares por vários dias (menos de uma semana). Nós fazemos uma tarefa juntos. Por um tempo, sentamos juntos: um escreve, o segundo senta e observa como equipe de suporte. Então discordamos por um tempo, todo mundo faz algumas coisas independentes, depois convergimos novamente, sincronizamos muito rapidamente, fazemos algo juntos e novamente divergem.

Planejamento e comunicação

O último bloco de práticas através das quais os problemas do sistema operacional são resolvidos é a organização do trabalho com as próprias tarefas. Isso também inclui a troca de experiências, que é um trabalho externo a pares. Considere três práticas:

1. Tarefas através da árvore de objetivos. Organizamos o gerenciamento geral do projeto através de uma árvore que se expande infinitamente no futuro. Tecnicamente, a liderança é feita no Miro. Há uma tarefa - é uma meta intermediária. Objetivos menores ou grupos de tarefas passam disso. Deles são as próprias tarefas. Todas as tarefas são criadas e conduzidas neste quadro.



Esse esquema também fornece feedback que ocorre uma vez ao dia quando sincronizamos em comícios. A presença na frente de todos de um plano comum, embora estruturada e completamente aberta, permite que todos se mantenham informados sobre o que está acontecendo e até onde avançamos.

Vantagens da visão visual das tarefas:

• Causalidade. Cada tarefa leva a algum objetivo global. As tarefas são agrupadas em objetivos menores. O domínio da infraestrutura em si é bastante técnico. Nem sempre é claro imediatamente qual o impacto específico sobre os negócios é exercido, por exemplo, escrevendo um ranking sobre a migração para outro nginx. A presença de um cartão de destino próximo torna isso mais claro.
  
  A causa é uma propriedade importante das tarefas. Responde diretamente à pergunta: "Estou fazendo isso?"
• Paralelismo. Somos nove e é impossível atacar todos com uma tarefa simplesmente fisicamente. Tarefas de uma área também podem nem sempre ser suficientes. Somos compelidos a trabalhar em paralelo entre pequenos grupos de trabalho. Ao mesmo tempo, os grupos mantêm sua tarefa por algum tempo, podem ser fortalecidos por outra pessoa. As pessoas às vezes caem nesse grupo de trabalho. Alguém sai de férias, alguém faz um relatório para a conferência conf DevOps, alguém escreve um artigo sobre Habr. Saber quais metas e objetivos podem ser realizados em paralelo se torna muito importante.

2. Apresentadores variáveis ​​de comícios matinais. Nos stand-ups, temos um problema: as pessoas fazem muitas tarefas em paralelo. Às vezes, as tarefas são fracamente acopladas e não há entendimento de quem está fazendo o que. E a opinião de outro membro da equipe é muito importante. Essas são informações adicionais que podem mudar o curso da solução de um problema. Obviamente, geralmente alguém está emparelhado com você, mas as consultas e dicas nem sempre são supérfluas.

Para melhorar essa situação, aplicamos a técnica de "Alterando o posicionamento principal". Agora eles alternam em uma lista específica, e isso tem seu efeito. Quando se trata de você, você é forçado a mergulhar e entender o que está acontecendo para conduzir bem uma reunião de scrum.



3. demonstração interna. A ajuda na resolução de um problema da programação em pares, a visualização na árvore de tarefas e a ajuda em reuniões de scrum pela manhã é boa, mas não perfeita. Em alguns, você é limitado apenas pelo seu conhecimento. A árvore de tarefas ajuda a entender globalmente quem faz o quê. E o anfitrião e os colegas da reunião da manhã não se aprofundarão nos seus problemas. Eles certamente podem perder alguma coisa.

A solução foi encontrada na demonstração do trabalho realizado entre si e na discussão subsequente. Reunimos uma vez por semana durante uma hora e mostramos detalhes de soluções para as tarefas que realizamos na semana passada.

No processo de demonstração, é necessário revelar os detalhes da tarefa e não se esqueça de demonstrar seu trabalho.


Após a parte de tempo integral, sempre há uma discussão no tópico. É aqui que o feedback necessário sobre nossas tarefas aparece.


Como resultado, é realizada uma pesquisa para identificar a utilidade do que está acontecendo. Isso já é um feedback sobre a essência do discurso e a importância da tarefa.

Conclusões longas e o que vem a seguir

Pode parecer que o tom do artigo seja um pouco pessimista. Isto não é verdade. Dois níveis de feedback de base, ou seja, testes e programação de pares, funcionam. Não é tão perfeito quanto no desenvolvimento tradicional, mas há um efeito positivo disso.

Os testes, em sua forma atual, fornecem apenas uma cobertura parcial do código. Muitas funções de configuração não são testadas. Sua influência no trabalho direto ao escrever código é baixa. No entanto, há um efeito nos testes de integração, e são eles que tornam possível realizar a refatoração com segurança. Esta é uma grande conquista. Além disso, com a transferência do foco para o desenvolvimento em linguagens de alto nível (temos python, vá), o problema desaparece. Mas há muitas verificações na "cola" e não há necessidade de uma integração suficientemente geral.

O trabalho em pares depende mais de pessoas específicas. Há um fator de tarefa e nossas habilidades pessoais. Acontece muito bem com alguém, pior com alguém. Definitivamente, há um benefício disso. É claro que, mesmo com a insuficiente observância das regras do trabalho em pares, o fato da execução conjunta de tarefas afeta positivamente a qualidade do resultado. Pessoalmente, é mais fácil e agradável trabalhar em conjunto.

Maneiras de nível mais alto de influenciar o sistema operacional - planejar e trabalhar com tarefas fornecem exatamente os efeitos: uma troca de conhecimento de alta qualidade e uma melhoria na qualidade do desenvolvimento.

Conclusões curtas em uma linha

• As práticas do XP funcionam no IaC, mas com menos eficiência.
• Fortalecer o que funciona.
• Crie seus próprios mecanismos e práticas compensatórias.