Infraestrutura como código: como superar problemas usando XP

Ola, Habr! Previamente queixeime da vida na Infraestrutura como paradigma de código e non ofrecía nada para solucionar a situación actual. Hoxe estou de volta para contarche cales son os enfoques e prácticas que che axudarán a escapar do abismo da desesperación e a orientar a situación na dirección correcta.

Nun artigo anterior "A infraestrutura como código: primeiro coñecido" Compartin as miñas impresións sobre esta área, intentei reflexionar sobre a situación actual nesta área e mesmo suxerín que as prácticas estándar coñecidas por todos os desenvolvedores poderían axudar. Podería parecer que houbo moitas queixas sobre a vida, pero non houbo propostas para saír da situación actual.

Quen somos, onde estamos e que problemas temos

Actualmente estamos no Sre Onboarding Team, que consta de seis programadores e tres enxeñeiros de infraestruturas. Todos estamos intentando escribir Infraestructura como código (IaC). Facemos isto porque basicamente sabemos escribir código e temos un historial de programadores "por encima da media".

• Temos un conxunto de vantaxes: certa formación, coñecementos de prácticas, capacidade de escribir código, ganas de aprender cousas novas.
• E hai unha parte flácida, que tamén é un inconveniente: a falta de coñecemento sobre o hardware da infraestrutura.

A pila de tecnoloxía que usamos no noso IaC.

• Terraform para crear recursos.
• Packer para a montaxe de imaxes. Estas son imaxes de Windows, CentOS 7.
• Jsonnet para crear unha potente compilación en drone.io, así como para xerar paquetes json e os nosos módulos terraform.
• Azul.
• Ansible ao preparar imaxes.
• Python para servizos auxiliares e scripts de aprovisionamento.
• E todo isto en VSCode con complementos compartidos entre os membros do equipo.

Conclusión do meu último artigo foi así: tratei de inculcar (en primeiro lugar) optimismo, quería dicir que probaremos os enfoques e prácticas que nos coñecemos para facer fronte ás dificultades e complexidades que hai neste ámbito.

Actualmente estamos loitando cos seguintes problemas de IaC:

• Imperfección de ferramentas e medios para o desenvolvemento de código.
• Implantación lenta. A infraestrutura forma parte do mundo real e pode ser lenta.
• Falta de enfoques e prácticas.
• Somos novos e non sabemos moito.

Programación extrema (XP) ao rescate

Todos os desenvolvedores están familiarizados con Extreme Programming (XP) e as prácticas que hai detrás. Moitos de nós traballamos con este enfoque, e tivo éxito. Entón, por que non utilizar os principios e prácticas alí establecidos para superar os desafíos das infraestruturas? Decidimos tomar este enfoque e ver que pasa.

Comprobando a aplicabilidade do enfoque XP á súa industriaAquí tes unha descrición do ambiente para o que XP é moi axeitado e como se relaciona con nós:

1. Requisitos de software que cambian dinámicamente. Quedounos claro cal era o obxectivo final. Pero os detalles poden variar. Nós mesmos decidimos onde necesitamos taxi, polo que os requisitos cambian periódicamente (principalmente por nós mesmos). Se tomamos o equipo SRE, que fai a automatización por si mesmo, e limita os requisitos e o alcance do traballo, entón este punto encaixa ben.

2. Riscos derivados de proxectos de tempo fixo que utilicen novas tecnoloxías. Podemos atopar riscos cando usamos algunhas cousas descoñecidas para nós. E este é 100% o noso caso. Todo o noso proxecto foi o uso de tecnoloxías que non estabamos completamente familiarizados. En xeral, este é un problema constante, porque... Son moitas as novas tecnoloxías que aparecen no sector das infraestruturas todo o tempo.

3,4. Pequeno equipo de desenvolvemento ampliado co-ubicado. A tecnoloxía automatizada que está a usar permite realizar probas unitarias e funcionais. Estes dous puntos non nos axustan. En primeiro lugar, non somos un equipo coordinado, e en segundo lugar, somos nove, que podemos considerar un equipo grande. Aínda que, segundo algunhas definicións dun equipo "grande", moitos son máis de 14 persoas.

Vexamos algunhas prácticas de XP e como afectan á velocidade e á calidade dos comentarios.

Principio do bucle de retroalimentación XP

Ao meu entender, o feedback é a resposta á pregunta, estou facendo o correcto, imos alí? XP ten un esquema divino para iso: un bucle de retroalimentación temporal. O interesante é que canto máis baixos esteamos, máis rápido conseguiremos que o SO responda ás preguntas necesarias.

Este é un tema bastante interesante para discutir, que na nosa industria de TI é posible obter rapidamente un sistema operativo. Imaxina o doloroso que é facer un proxecto durante seis meses e só entón descubrir que houbo un erro ao principio. Isto ocorre no deseño e en calquera construción de sistemas complexos.

No noso caso de IaC, os comentarios axúdanos. Inmediatamente farei un pequeno axuste no diagrama anterior: o plan de lanzamento non ten un ciclo mensual, pero ocorre varias veces ao día. Hai algunhas prácticas vinculadas a este ciclo de SO que analizaremos con máis detalle.

Importante: os comentarios poden ser unha solución a todos os problemas indicados anteriormente. Combinado coas prácticas de XP, pode sacarche do abismo da desesperación.

Como sacarse do abismo da desesperación: tres prácticas

Probas

As probas menciónanse dúas veces no bucle de comentarios de XP. Non é só así. Son moi importantes para toda a técnica de programación extrema.

Suponse que ten probas de unidade e de aceptación. Algúns danche comentarios en poucos minutos, outros en poucos días, polo que tardan máis en escribir e son revisados ​​con menos frecuencia.

Hai unha pirámide de proba clásica, que mostra que debería haber máis probas.

Como se nos aplica este marco nun proxecto IaC? En realidade... en absoluto.

• As probas unitarias, a pesar de que deberían ser moitas, non poden ser demasiadas. Ou están probando algo moi indirectamente. De feito, podemos dicir que non as escribimos en absoluto. Pero aquí tes algunhas aplicacións para este tipo de probas que puidemos facer:
  1. Probando código jsonnet. Este, por exemplo, é o noso pipeline de montaxe de drons, que é bastante complicado. O código jsonnet está ben cuberto polas probas.
     Usamos isto Marco de probas unitarias para Jsonnet.
  2. Probas de scripts que se executan cando se inicia o recurso. Os scripts están escritos en Python e, polo tanto, pódense escribir probas neles.
• É posiblemente posible comprobar a configuración en probas, pero non o facemos. Tamén é posible configurar regras de configuración de recursos de comprobación mediante tflint. Non obstante, as comprobacións que hai son demasiado básicas para terraform, pero moitos scripts de proba están escritos para AWS. E estamos en Azure, polo que isto de novo non se aplica.
• Probas de integración de compoñentes: depende de como as clasifiques e onde as poñas. Pero basicamente funcionan.

  Así se ven as probas de integración.

  
  
  Este é un exemplo cando se crean imaxes en Drone CI. Para chegar a eles, tes que esperar 30 minutos para que se forme a imaxe de Packer e despois esperar outros 15 minutos para que pasen. Pero existen!

  Algoritmo de verificación de imaxes

  1. O empacador primeiro debe preparar a imaxe completamente.
  2. Xunto á proba hai unha terraforma cun estado local, que utilizamos para despregar esta imaxe.
  3. Cando se desprega, utilízase un pequeno módulo situado preto para facilitar o traballo coa imaxe.
  4. Unha vez que se desprega a máquina virtual desde a imaxe, as comprobacións poden comezar. Basicamente, as comprobacións realízanse en coche. Comproba como funcionaban os scripts ao inicio e como funcionan os daemons. Para iso, a través de ssh ou winrm iniciamos sesión na máquina recén levantada e comprobamos o estado da configuración ou se os servizos están activados.

• A situación é similar coas probas de integración en módulos para terraform. Aquí tes unha pequena táboa que explica as características deste tipo de probas.

  
  
  Os comentarios sobre o gasoduto duran uns 40 minutos. Todo pasa por moito tempo. Pódese usar para a regresión, pero para o desenvolvemento novo é xeralmente pouco realista. Se estás moi, moi preparado para iso, prepara scripts en execución, entón podes reducilo a 10 minutos. Pero estas aínda non son probas unitarias, que fan 5 pezas en 100 segundos.

A ausencia de probas unitarias cando se ensamblan imaxes ou módulos de terraform incentiva a cambiar o traballo a servizos separados que simplemente se poden executar a través de REST ou a scripts de Python.

Por exemplo, necesitabamos asegurarnos de que cando se inicia a máquina virtual, rexistrase no servizo EscalaFT, e cando a máquina virtual foi destruída, eliminouse a si mesma.

Xa que temos ScaleFT como servizo, vémonos obrigados a traballar con el a través da API. Había un envoltorio escrito alí que podías tirar e dicir: "Entra e elimina isto e aquilo". Almacena todos os axustes e accesos necesarios.

Xa podemos escribir probas normais para iso, xa que non é diferente do software común: se burla dalgún tipo de apiha, tirás dela e mira que pasa.

Resultados das probas: as probas unitarias, que deberían dar o SO nun minuto, non o dan. E os tipos de probas máis altas na pirámide son eficaces, pero só cobren parte dos problemas.

Programación de pares

As probas son, por suposto, boas. Podes escribir moitos deles, poden ser de distintos tipos. Eles traballarán nos seus niveis e daránnos comentarios. Pero o problema das malas probas unitarias, que dan o sistema operativo máis rápido, permanece. Ao mesmo tempo, aínda quero un sistema operativo rápido que sexa fácil e agradable de traballar. Sen esquecer a calidade da solución resultante. Afortunadamente, hai técnicas que poden proporcionar un feedback aínda máis rápido que as probas unitarias. Esta é a programación por parellas.

Ao escribir código, quere obter comentarios sobre a súa calidade o máis rápido posible. Si, podes escribir todo nunha rama de funcións (para non romper nada para ninguén), facer unha solicitude de extracción en Github, asignala a alguén cuxa opinión teña peso e esperar unha resposta.

Pero podes esperar moito tempo. A xente está toda ocupada e a resposta, aínda que a houbera, pode non ser da máis alta calidade. Supoñamos que a resposta chegou inmediatamente, o revisor entendeu ao instante toda a idea, pero a resposta aínda chega tarde, despois do feito. Gustaríame que fose antes. Isto é ao que se dirixe a programación por parellas: de inmediato, no momento de escribir.

A continuación móstranse os estilos de programación por parellas e a súa aplicabilidade para traballar en IaC:

1. Clásico, experimentado + experimentado, cambio por temporizador. Dous papeis: condutor e navegante. Dúas persoas. Funcionan co mesmo código e cambian de pape despois dun período de tempo predeterminado.

Consideremos a compatibilidade dos nosos problemas co estilo:

• Problema: imperfección das ferramentas e ferramentas para o desenvolvemento de código.
  Impacto negativo: tarda máis en desenvolverse, ralentizamos, pérdese o ritmo/ritmo de traballo.
  Como loitamos: usamos unha ferramenta diferente, un IDE común e tamén aprendemos atallos.
• Problema: implantación lenta.
  Impacto negativo: aumenta o tempo que se tarda en crear unha peza de código de traballo. Aburrimonos mentres esperamos, as nosas mans estenden para facer outra cousa mentres esperamos.
  Como loitamos: non o superamos.
• Problema: falta de enfoques e prácticas.
  Impacto negativo: non se sabe como facelo ben e como facelo mal. Alarga a recepción de comentarios.
  Como loitamos: o intercambio mutuo de opinións e prácticas no traballo por parellas case resolve o problema.

O principal problema co uso deste estilo en IaC é o ritmo desigual de traballo. No desenvolvemento de software tradicional, tes un movemento moi uniforme. Podes pasar cinco minutos e escribir N. Pasa 10 minutos e escribe 2N, 15 minutos - 3N. Aquí podes pasar cinco minutos e escribir N, e despois pasar outros 30 minutos e escribir unha décima de N. Aquí non sabes nada, estás atrapado, estúpido. A investigación leva tempo e distrae da propia programación.

Conclusión: na súa forma pura non nos convén.

2. Ping-pong. Este enfoque implica que unha persoa escriba a proba e outra que faga a súa implementación. Tendo en conta que todo é complicado coas probas unitarias, e hai que escribir unha proba de integración que leva moito tempo programada, desaparece toda a facilidade do ping-pong.

Podo dicir que tentamos separar as responsabilidades para deseñar un script de proba e implementar código para el. A un participante ocorréuselle o guión, nesta parte do traballo el foi o responsable, tiña a última palabra. E o outro encargouse da execución. Saíu ben. A calidade do guión con este enfoque aumenta.

Conclusión: por desgraza, o ritmo de traballo non permite o uso do ping-pong como práctica de programación por parellas en IaC.

3.Estilo forte. Práctica difícil. A idea é que un participante convértese no navegador directivo e o segundo tome o papel de controlador de execución. Neste caso, o dereito a tomar decisións corresponde exclusivamente ao navegador. O controlador só imprime e pode influír no que está a suceder cunha palabra. Os papeis non cambian durante moito tempo.

Bo para aprender, pero require habilidades suaves fortes. Aquí é onde tambaleamos. A técnica era difícil. E nin sequera se trata de infraestruturas.

Conclusión: potencialmente pódese utilizar, non renunciamos a intentalo.

4. Mobbing, swarming e todos os estilos coñecidos pero non enumerados Non o consideramos, porque Non o probamos e é imposible falar diso no contexto do noso traballo.

Resultados xerais sobre o uso da programación por parellas:

• Temos un ritmo de traballo irregular, o que é confuso.
• Atopamos habilidades blandas insuficientemente boas. E a área temática non axuda a superar estas nosas carencias.
• As probas longas e os problemas coas ferramentas dificultan o desenvolvemento combinado.

5. A pesar diso, houbo éxitos. Creamos o noso propio método "Converxencia - Diverxencia". Vou describir brevemente como funciona.

Temos socios permanentes por uns días (menos dunha semana). Facemos unha tarefa xuntos. Sentamos un tempo xuntos: un escribe, o outro senta e observa o equipo de apoio. Despois dispersámonos durante algún tempo, cada un fai algunhas cousas independentes, despois xuntámonos de novo, sincronizamos moi rápido, facemos algo xuntos e volvémonos a dispersar.

Planificación e comunicación

O último bloque de prácticas a través do cal se solucionan os problemas do SO é a organización do traballo coas propias tarefas. Isto tamén inclúe o intercambio de experiencias fóra do traballo en parella. Vexamos tres prácticas:

1. Obxectivos a través da árbore de obxectivos. Organizamos a xestión global do proxecto a través dunha árbore que vai sen fin cara ao futuro. Tecnicamente, o seguimento faise en Miro. Hai unha tarefa: é un obxectivo intermedio. A partir del saen obxectivos máis pequenos ou grupos de tarefas. As propias tarefas veñen delas. Todas as tarefas son creadas e mantidas neste taboleiro.

Este esquema tamén proporciona feedback, que ocorre unha vez ao día cando nos sincronizamos nos mitins. Ter un plan común diante de todos, pero estruturado e totalmente aberto, permite que todos estean ao tanto do que está a suceder e do que avanzamos.

Vantaxes da visión visual das tarefas:

• Causalidade. Cada tarefa leva a algún obxectivo global. As tarefas agrúpanse en obxectivos máis pequenos. O dominio da infraestrutura en si é bastante técnico. Non sempre está claro de inmediato que impacto específico ten na empresa, por exemplo, escribir un runbook ao migrar a outro nginx. Ter a tarxeta de destino preto faino máis claro.
  
  A causalidade é unha propiedade importante dos problemas. Responde directamente á pregunta: "Estou facendo o correcto?"
• Paralelismo. Somos nove, e simplemente é fisicamente imposible botarlle a todos nunha mesma tarefa. As tarefas dunha área poden non ser sempre suficientes. Estamos obrigados a paralelizar o traballo entre pequenos grupos de traballo. Ao mesmo tempo, os grupos sentan na súa tarefa durante algún tempo, poden ser reforzados por outra persoa. Ás veces, a xente se afasta deste grupo de traballo. Alguén vai de vacacións, alguén fai un informe para a conf de DevOps, alguén escribe un artigo sobre Habr. Coñecer cales son os obxectivos e tarefas que se poden facer en paralelo faise moi importante.

2. Presentadores substitutos das reunións matinais. Nos stand-ups temos este problema: a xente fai moitas tarefas en paralelo. Ás veces, as tarefas están pouco conectadas e non se entende quen fai que. E a opinión doutro membro do equipo é moi importante. Esta é información adicional que pode cambiar o curso de resolución do problema. Por suposto, normalmente hai alguén contigo, pero os consellos e consellos sempre son útiles.

Para mellorar esta situación, utilizamos a técnica "Changing the Leading Stand-Up". Agora rótanse segundo unha determinada lista, e isto ten o seu efecto. Cando é a túa quenda, estás obrigado a mergullarte e comprender o que está a suceder para levar a cabo unha boa reunión de Scrum.

3. Demo interna. Axudar a resolver un problema a partir da programación por parellas, a visualización na árbore de problemas e a axuda nas reunións scrum pola mañá son boas, pero non ideais. Como parella, só estás limitado polos teus coñecementos. A árbore de tarefas axuda a comprender globalmente quen fai que. E o presentador e os compañeiros da reunión da mañá non mergullarán profundamente nos teus problemas. Seguramente poden perder algo.

A solución atopouse demostrando o traballo feito entre si e discutíndoo despois. Reunímonos unha vez á semana durante unha hora e mostramos detalles das solucións ás tarefas que fixemos durante a semana pasada.

Durante a demostración, é necesario revelar os detalles da tarefa e asegúrese de demostrar o seu funcionamento.

O informe pódese realizar mediante unha lista de verificación.1. Entra en contexto. De onde saíu a tarefa, por que era necesario?

2. Como se resolvía o problema antes? Por exemplo, era necesario facer un clic masivo do rato ou era imposible facer nada.

3. Como o melloramos. Por exemplo: "Mira, agora hai scriptosik, aquí está o readme".

4. Mostra como funciona. É recomendable implementar directamente algún escenario de usuario. Quero X, fago Y, vexo Y (ou Z). Por exemplo, implemento NGINX, fumo o URL e obteño 200 OK. Se a acción é longa, prepáraa con antelación para poder mostrala máis tarde. É recomendable non rompelo demasiado unha hora antes da demo, se é fráxil.

5. Explica o éxito que se resolveu o problema, que dificultades quedan, que non se completa, que melloras son posibles no futuro. Por exemplo, agora CLI, entón haberá unha automatización total en CI.

É recomendable que cada altofalante o manteña a 5-10 minutos. Se o teu discurso é obviamente importante e vai levar máis tempo, coordine isto con antelación na canle de toma de posesión.

Despois da parte cara a cara sempre hai unha discusión no fío. Aquí é onde aparecen os comentarios que necesitamos sobre as nosas tarefas.

Como resultado, realízase unha enquisa para determinar a utilidade do que está a suceder. Trátase de comentarios sobre a esencia do discurso e a importancia da tarefa.

Conclusións longas e que segue

Pode parecer que o ton do artigo é algo pesimista. Isto está mal. Funcionan dous niveis inferiores de feedback, a saber, as probas e a programación por parellas. Non tan perfecto como no desenvolvemento tradicional, pero hai un efecto positivo.

As probas, na súa forma actual, ofrecen só unha cobertura parcial do código. Moitas funcións de configuración acaban sen probar. A súa influencia no traballo real ao escribir código é baixa. Non obstante, as probas de integración teñen un efecto e permiten realizar refactorizacións sen medo. Este é un gran logro. Ademais, co cambio de foco no desenvolvemento en linguaxes de alto nivel (temos python, vaia), o problema desaparece. E non necesitas moitas comprobacións para o "pegamento"; unha comprobación xeral de integración é suficiente.

O traballo en parella depende máis de persoas concretas. Está o factor tarefa e as nosas habilidades blandas. Con algunhas persoas sae moi ben, con outras sae peor. Definitivamente hai beneficios disto. Está claro que aínda que as regras do traballo por parellas non sexan suficientemente observadas, o feito mesmo de realizar tarefas xuntos repercute positivamente na calidade do resultado. Persoalmente, paréceme máis fácil e agradable traballar en parella.

Formas de maior nivel de influír no SO: a planificación e o traballo con tarefas producen precisamente efectos: intercambio de coñecemento de alta calidade e mellora da calidade do desenvolvemento.

Breve conclusións nunha liña

• Os profesionais de RRHH traballan en IaC, pero con menos eficiencia.
• Fortalece o que funciona.
• Crea os teus propios mecanismos e prácticas compensatorias.

Fonte: www.habr.com