Infraestrutura como Código: como superar problemas usando XP

Olá, Habr! Anteriormente, reclamei da vida na Infraestrutura como paradigma de código e não ofereci nada para resolver a situação atual. Hoje estou de volta para contar quais abordagens e práticas o ajudarão a escapar do abismo do desespero e a direcionar a situação na direção certa.

Em um artigo anterior “Infraestrutura como código: primeiro contato” Compartilhei minhas impressões sobre esta área, tentei refletir sobre a situação atual nesta área e até sugeri que práticas padrão conhecidas por todos os desenvolvedores poderiam ajudar. Pode parecer que houve muitas reclamações sobre a vida, mas não houve propostas de saída para a situação atual.

Quem somos, onde estamos e que problemas temos

Atualmente fazemos parte da equipe de integração da 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 basicamente sabemos escrever código e temos um histórico de desenvolvedores “acima da média”.

• Temos um conjunto de vantagens: uma certa formação, conhecimento de práticas, capacidade de escrever código, vontade de aprender coisas novas.
• E há uma parte negativa, que também é um ponto negativo: falta de conhecimento sobre hardware de infraestrutura.

A pilha de tecnologia que usamos em nosso IaC.

• Terraform para criação de recursos.
• Packer para montagem de imagens. Estas são imagens do Windows, CentOS 7.
• Jsonnet para fazer uma construção poderosa no drone.io, bem como para gerar o packer json e nossos módulos terraform.
• Azul.
• Ansible ao preparar imagens.
• Python para serviços auxiliares e scripts de provisionamento.
• E tudo isso em VSCode com plugins compartilhados entre os membros da equipe.

Conclusão do meu último artigo foi assim: tentei incutir (em primeiro lugar em mim mesmo) otimismo, queria dizer que vamos experimentar as abordagens e práticas que conhecemos para lidar com as dificuldades e complexidades que existem nesta área.

No momento, estamos lutando com os seguintes problemas de IaC:

• Imperfeição de ferramentas e meios para 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 Extreme Programming (XP) e as práticas que estão por trás dele. Muitos de nós trabalhamos com essa abordagem e ela teve sucesso. Então porque não utilizar os princípios e práticas aí estabelecidos para superar os desafios infra-estruturais? Decidimos adotar essa abordagem e ver o que acontece.

Verificando a aplicabilidade da abordagem XP ao seu setorAqui está uma descrição do ambiente para o qual o XP é adequado e como ele se relaciona conosco:

1. Requisitos de software que mudam dinamicamente. Ficou claro para nós qual era o objetivo final. Mas os detalhes podem variar. Nós mesmos decidimos onde precisamos taxiar, então os requisitos mudam periodicamente (principalmente por nós mesmos). Se pegarmos a equipe SRE, que faz a automação sozinha, e ela mesma limita os requisitos e o escopo do trabalho, então esse ponto se encaixa bem.

2. Riscos causados ​​por projetos de tempo fixo que utilizam novas tecnologias. Podemos encontrar riscos ao usar algumas coisas que desconhecemos. E este é 100% o nosso caso. Todo o nosso projeto foi o uso de tecnologias com as quais não estávamos totalmente familiarizados. Em geral, este é um problema constante, porque... Há muitas novas tecnologias surgindo no setor de infraestrutura o tempo todo.

3,4. Equipe de desenvolvimento estendida pequena e co-localizada. A tecnologia automatizada que você está usando permite testes unitários e funcionais. Esses dois pontos não nos convêm muito bem. Em primeiro lugar, não somos uma equipa coordenada e, em segundo lugar, somos nove, o que pode ser considerado uma equipa grande. Embora, de acordo com algumas definições de uma equipe “grande”, sejam mais de 14 pessoas.

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

Princípio do Ciclo de Feedback XP

No meu entendimento, feedback é a resposta para a pergunta: estou fazendo a coisa certa, vamos lá? XP tem um esquema divino para isso: um ciclo de feedback temporal. O interessante é que quanto mais baixo estivermos, mais rápido conseguiremos fazer com que o SO responda às perguntas necessárias.

Este é um tópico bastante interessante para discussão, que em nosso setor de TI é possível obter um sistema operacional rapidamente. Imagine como é doloroso fazer um projeto durante seis meses e só depois descobrir que houve um erro logo no início. Isto acontece no projeto e em qualquer construção de sistemas complexos.

No nosso caso da IaC, o feedback nos ajuda. Farei imediatamente um pequeno ajuste no diagrama acima: o plano de lançamento não tem ciclo mensal, mas ocorre várias vezes ao dia. Existem algumas práticas vinculadas a este ciclo de sistema operacional que examinaremos com mais detalhes.

Importante: o feedback pode ser uma solução para todos os problemas mencionados acima. Combinado com as práticas XP, pode tirar você do abismo do desespero.

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 toda a técnica de Extreme Programming.

Presume-se que você tenha testes de unidade e aceitação. Alguns fornecem feedback em alguns minutos, outros em alguns dias, por isso demoram mais para escrever e são revisados ​​com menos frequência.

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

Como esta estrutura se aplica a nós em um projeto IaC? Na verdade... de jeito nenhum.

• Os testes unitários, apesar de deverem ser muitos, não podem ser muitos. Ou eles estão testando algo de forma muito indireta. Na verdade, podemos dizer que não os escrevemos. Mas aqui estão algumas aplicações para esses testes que conseguimos fazer:
  1. Testando código jsonnet. Este, por exemplo, é o nosso pipeline de montagem de drones, que é bastante complicado. O código jsonnet é bem coberto por testes.
     Nós usamos isso Estrutura de teste unitário para Jsonnet.
  2. Testes de scripts que são executados quando o recurso é iniciado. Os scripts são escritos em Python e, portanto, testes podem ser escritos neles.
• É potencialmente possível verificar a configuração em testes, mas não fazemos isso. Também é possível configurar a verificação de regras de configuração de recursos via pederneira. No entanto, as verificações são simplesmente básicas demais para o terraform, mas muitos scripts de teste são escritos para AWS. E estamos no Azure, então isso novamente não se aplica.
• Testes de integração de componentes: depende de como você os classifica e onde os coloca. Mas eles basicamente funcionam.

  É assim que se parecem os testes de integração.

  
  
  Este é um exemplo de construção de imagens no Drone CI. Para alcançá-los, é necessário aguardar 30 minutos para que a imagem do Packer se forme e depois esperar mais 15 minutos para que passem. Mas eles existem!

  Algoritmo de verificação de imagem

  1. O Packer deve primeiro preparar a imagem completamente.
  2. Ao lado do teste existe um terraform com estado local, que utilizamos para implantar esta imagem.
  3. Ao desdobrar, um pequeno módulo próximo é utilizado para facilitar o trabalho com a imagem.
  4. Depois que a VM for implantada a partir da imagem, as verificações poderão começar. Basicamente, as verificações são feitas de carro. Ele verifica como os scripts funcionaram na inicialização e como funcionam os daemons. Para fazer isso, via ssh ou winrm fazemos login na máquina recém-criada e verificamos o status da configuração ou se os serviços estão ativos.

• A situação é semelhante com testes de integração em módulos para terraform. Aqui está uma pequena tabela explicando os recursos de tais testes.

  
  
  O feedback sobre o pipeline leva cerca de 40 minutos. Tudo acontece há muito tempo. Pode ser usado para regressão, mas para novos desenvolvimentos é geralmente irrealista. Se você estiver muito, muito preparado para isso, prepare scripts em execução, então poderá reduzir para 10 minutos. Mas estes ainda não são testes unitários, que fazem 5 peças em 100 segundos.

A ausência de testes unitários ao montar imagens ou módulos terraform incentiva a mudança do trabalho para serviços separados que podem ser simplesmente executados via REST ou para scripts Python.

Por exemplo, precisávamos ter certeza de que, quando a máquina virtual fosse iniciada, ela se registrasse no serviço EscalaFT, e quando a máquina virtual foi destruída, ela se excluiu.

Como temos o ScaleFT como serviço, somos obrigados a trabalhar com ele por meio da API. Havia um invólucro escrito lá que você poderia puxar e dizer: “Entre e exclua isso e aquilo”. Ele armazena todas as configurações e acessos necessários.

Já podemos escrever testes normais para isso, pois não é diferente do software comum: algum tipo de apiha é ridicularizado, você puxa e vê o que acontece.

Resultados dos testes: O teste unitário, que deveria dar o SO em um minuto, não dá. E os tipos de testes mais elevados na pirâmide são eficazes, mas cobrem apenas parte dos problemas.

Programação em pares

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

Ao escrever código, você deseja obter feedback sobre sua qualidade o mais rápido possível. Sim, você pode escrever tudo em um feature branch (para não quebrar nada para ninguém), fazer um pull request no Github, atribuí-lo 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 exista, pode não ser da mais alta qualidade. Suponha que a resposta veio imediatamente, o revisor entendeu instantaneamente toda a ideia, mas a resposta ainda chega tarde, depois do fato. Eu gostaria que fosse antes. É para isso que se destina a programação em pares – imediatamente, no momento em que este artigo é escrito.

Abaixo estão os estilos de programação em pares e sua aplicabilidade no trabalho em IaC:

1. Clássico, Experiente + Experiente, mudança por cronômetro. Duas funções – motorista e navegador. Duas pessoas. Eles trabalham no mesmo código e trocam de função após um determinado período de tempo predeterminado.

Consideremos a compatibilidade dos nossos problemas com o estilo:

• Problema: imperfeição de ferramentas e ferramentas para desenvolvimento de código.
  Impacto negativo: demora mais para se desenvolver, desaceleramos, perde-se o ritmo/ritmo do trabalho.
  Como lutamos: usamos uma ferramenta diferente, um IDE comum e também aprendemos atalhos.
• Problema: implantação lenta.
  Impacto negativo: aumenta o tempo necessário para criar um código funcional. Ficamos entediados enquanto esperamos, nossas mãos se estendem para fazer outra coisa enquanto esperamos.
  Como lutamos: não superamos.
• Problema: falta de abordagens e práticas.
  Impacto negativo: não há conhecimento de como fazer bem e de como fazer mal. Prolonga o recebimento de feedback.
  Como lutamos: a troca mútua de opiniões e práticas no trabalho em pares quase resolve o problema.

O principal problema do uso desse estilo em IaC é o ritmo desigual de trabalho. 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 mais 30 minutos e escrever um décimo de N. Aqui você não sabe de nada, você está preso, estúpido. A investigação leva tempo e distrai a programação em si.

Conclusão: na sua forma pura não é adequado para nós.

2. Pingue-pongue. Essa abordagem envolve uma pessoa escrevendo o teste e outra fazendo a implementação dele. Levando em conta que tudo é complicado com testes unitários, e você tem que escrever um teste de integração que demora muito para programar, toda a facilidade do pingue-pongue vai embora.

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

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

3. Estilo forte. Prática difícil. A ideia é que um participante se torne o navegador diretivo e o segundo assuma o papel de condutor de execução. Neste caso, o direito de tomar decisões cabe exclusivamente ao navegador. O driver apenas imprime e pode influenciar o que está acontecendo com uma palavra. Os papéis não mudam por muito tempo.

Bom para aprender, mas requer fortes habilidades sociais. Foi aqui que vacilámos. A técnica era difícil. E nem se trata de infraestrutura.

Conclusão: pode ser potencialmente utilizado, não desistimos de tentar.

4. Mobbing, swarming e todos os estilos conhecidos, mas não listados Não consideramos isso, porque Ainda não experimentamos e é impossível falar sobre isso no contexto do nosso trabalho.

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

• Temos um ritmo de trabalho desigual, o que é confuso.
• Encontramos habilidades sociais insuficientemente boas. E a área temática não ajuda a superar essas nossas deficiências.
• Testes longos e problemas com ferramentas dificultam o desenvolvimento pareado.

5. Apesar disso, houve sucessos. Criamos nosso próprio método “Convergência - Divergência”. Descreverei brevemente como funciona.

Temos parceiros permanentes por alguns dias (menos de uma semana). Fazemos uma tarefa juntos. Ficamos um tempo sentados juntos: um escreve, o outro senta e observa a equipe de apoio. Aí a gente se dispersa por um tempo, cada um faz algumas coisas independentes, depois a gente se reúne de novo, sincroniza muito rápido, faz alguma coisa juntos e depois se dispersa novamente.

Planejamento e comunicação

O último bloco de práticas através das quais os problemas do SO são resolvidos é a organização do trabalho com as próprias tarefas. Isto também inclui a troca de experiências fora do trabalho em pares. Vejamos três práticas:

1. Objetivos através da árvore de metas. Organizamos a gestão global do projeto através de uma árvore que avança indefinidamente no futuro. Tecnicamente, o rastreamento é feito no Miro. Existe uma tarefa - é um objetivo intermediário. Dele partem objetivos menores ou grupos de tarefas. As próprias tarefas vêm deles. Todas as tarefas são criadas e mantidas neste quadro.

Este esquema também fornece feedback, que ocorre uma vez por dia quando sincronizamos nos comícios. Ter um plano comum diante de todos, mas estruturado e totalmente aberto, permite que todos tenham consciência do que está acontecendo e do quanto 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 infra-estrutura em si é bastante técnico. Nem sempre fica imediatamente claro qual impacto específico, por exemplo, escrever um runbook sobre a migração para outro nginx tem nos negócios. Ter a carta alvo por perto torna tudo mais claro.
  
  A causalidade é uma propriedade importante dos problemas. Responde diretamente à pergunta: “Estou fazendo a coisa certa?”
• Paralelismo. Somos nove e é simplesmente fisicamente impossível colocar todos em uma tarefa. As tarefas de uma área também nem sempre são suficientes. Somos forçados a paralelizar o trabalho entre pequenos grupos de trabalho. Ao mesmo tempo, os grupos sentam-se na sua tarefa durante algum tempo, podendo ser reforçados por outra pessoa. Às vezes as pessoas se afastam deste grupo de trabalho. Alguém sai de férias, alguém faz um relatório para a conferência DevOps, alguém escreve um artigo no Habr. Saber quais objetivos e tarefas podem ser realizadas em paralelo torna-se muito importante.

2. Substituição de apresentadores das reuniões matinais. Nos stand-ups temos este problema – as pessoas realizam muitas tarefas em paralelo. Às vezes, as tarefas estão vagamente conectadas e não há compreensão de quem está fazendo o quê. E a opinião de outro membro da equipe é muito importante. Esta é uma informação adicional que pode mudar o rumo da solução do problema. Claro, geralmente há alguém com você, mas conselhos e dicas são sempre úteis.

Para melhorar esta situação, utilizamos a técnica “Mudando o Stand-Up do Líder”. Agora eles são girados de acordo com uma determinada lista, e isso tem seu efeito. Quando chega a sua vez, você é forçado a mergulhar e entender o que está acontecendo para realizar uma boa reunião Scrum.

3. Demonstração interna. Ajuda na resolução de um problema a partir da programação em pares, visualização na árvore de problemas e ajuda nas reuniões scrum pela manhã são boas, mas não são ideais. Como casal, vocês estão limitados apenas pelo seu conhecimento. A árvore de tarefas ajuda a compreender globalmente quem está fazendo o quê. E o apresentador e os colegas da reunião matinal não irão se aprofundar nos seus problemas. Eles certamente podem perder alguma coisa.

A solução foi encontrada em demonstrar o trabalho realizado entre si e depois discuti-lo. Nos reunimos uma vez por semana durante uma hora e mostramos detalhes de soluções para tarefas que realizamos na semana passada.

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

O relatório pode ser conduzido usando uma lista de verificação.1. Entre no contexto. De onde veio a tarefa, por que foi necessária?

2. Como o problema foi resolvido antes? Por exemplo, eram necessários cliques massivos do mouse ou era impossível fazer qualquer coisa.

3. Como podemos melhorá-lo. Por exemplo: “Olha, agora existe o scriptosik, aqui está o leia-me.”

4. Mostre como funciona. É aconselhável implementar diretamente algum cenário de usuário. Quero X, faço Y, vejo Y (ou Z). Por exemplo, eu implanto o NGINX, fumo o URL e obtenho 200 OK. Se a ação for longa, prepare-a com antecedência para poder mostrá-la mais tarde. É aconselhável não quebrá-lo muito uma hora antes da demonstração, se estiver frágil.

5. Explique até que ponto o problema foi resolvido com sucesso, que dificuldades permanecem, o que não foi concluído, que melhorias são possíveis no futuro. Por exemplo, agora CLI, haverá automação total no CI.

É aconselhável que cada palestrante reserve de 5 a 10 minutos. Se o seu discurso for obviamente importante e demorar mais, coordene isso com antecedência no canal sre-takeover.

Depois da parte presencial sempre há uma discussão no tópico. É aqui que aparece o feedback que precisamos sobre nossas tarefas.

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

Longas conclusões e o que vem a seguir

Pode parecer que o tom do artigo é um tanto pessimista. Isto está errado. Dois níveis inferiores de feedback, nomeadamente testes e programação em pares, funcionam. Não tão perfeito quanto no desenvolvimento tradicional, mas há um efeito positivo nisso.

Os testes, em sua forma atual, fornecem apenas cobertura parcial do código. Muitas funções de configuração acabam não sendo testadas. Sua influência no trabalho real ao escrever código é baixa. No entanto, há um efeito dos testes de integração, e eles permitem que você refatore sem medo. Esta é uma grande conquista. Além disso, com a mudança de foco para o desenvolvimento em linguagens de alto nível (temos python, vai), o problema desaparece. E você não precisa de muitas verificações para a “cola”; uma verificação geral de integração é suficiente.

Trabalhar em pares depende mais de pessoas específicas. Existe o fator tarefa e nossas habilidades interpessoais. Com algumas pessoas funciona muito bem, com outras funciona pior. Definitivamente há benefícios nisso. É claro que mesmo que as regras do trabalho em pares não sejam suficientemente observadas, o próprio fato de realizarem as tarefas em conjunto tem um efeito positivo na qualidade do resultado. Pessoalmente, acho que trabalhar em pares é mais fácil e agradável.

Formas de alto nível de influenciar o sistema operacional - planejar e trabalhar com tarefas com precisão produzem efeitos: troca de conhecimento de alta qualidade e melhor qualidade de desenvolvimento.

Conclusões curtas em uma linha

• Os profissionais de RH trabalham em IaC, mas com menos eficiência.
• Fortaleça o que funciona.
• Crie seus próprios mecanismos e práticas compensatórias.

Fonte: habr.com