Infraestructura como código: cómo superar problemas con XP

Hola Habr! Anteriormente, me quejé de la vida en la Infraestructura como paradigma de código y no ofrecí nada para resolver esta situación. Hoy regresé para decirles qué enfoques y prácticas ayudarán a salir del abismo de la desesperación y llevar la situación por el buen camino.



En el artículo anterior "Infraestructura como código: primer conocido", compartí mi impresión de esta área, traté de reflexionar sobre la situación actual en esta área e incluso sugerí que las prácticas estándar conocidas por todos los desarrolladores pueden ayudar. Puede parecer que hubo muchas quejas sobre la vida, pero no hubo propuestas para salir de esta situación.

Quiénes somos, dónde estamos y qué problemas tenemos

Ahora estamos en el equipo de integración de Sre, que consta de seis programadores y tres ingenieros de infraestructura. Todos estamos tratando de escribir Infraestructura como código (IaC). Hacemos esto porque, en principio, podemos escribir código y en la historia somos desarrolladores del nivel "por encima del promedio".

• Tenemos un conjunto de ventajas: cierta experiencia, conocimiento de prácticas, la capacidad de escribir código, el deseo de aprender cosas nuevas.
• Y hay una parte que se hunde, también es una desventaja: la falta de conocimiento sobre el material de infraestructura.

La conclusión de mi último artículo fue esta: intenté inspirar optimismo (principalmente en mí mismo), quería decir que intentaremos los enfoques y prácticas que conocemos para hacer frente a las dificultades y dificultades que existen en esta área.

Ahora estamos luchando con estos problemas de IaC:

• Imperfección de herramientas, herramientas de desarrollo de código.
• Despliegue lento. La infraestructura es parte del mundo real y puede ser lenta.
• Falta de enfoques y prácticas.
• Somos nuevos y no sabemos mucho.

Programación extrema (XP) al rescate

Todos los desarrolladores están familiarizados con la programación extrema (XP) y las prácticas detrás de ella. Muchos de nosotros trabajamos en este enfoque, y fue exitoso. Entonces, ¿por qué no aprovechar los principios y prácticas establecidos allí para superar las dificultades de la infraestructura? Decidimos aplicar este enfoque y ver qué pasa.


Veamos algunas prácticas de XP y cómo afectan la velocidad y la calidad de los comentarios.

Principio del circuito de retroalimentación XP

Según tengo entendido, los comentarios son la respuesta a la pregunta, ¿estoy bien? ¿Vamos allí? En XP, hay un pequeño esquema divino a este respecto: un ciclo de retroalimentación de tiempo. Lo interesante es que cuanto más bajos somos, más rápido podemos obtener un sistema operativo para responder las preguntas necesarias.



Este es un tema bastante interesante para debatir que en nuestra industria de TI es posible obtener rápidamente un sistema operativo. Imagine lo doloroso que es hacer un proyecto durante medio año y solo entonces descubra que se cometió un error desde el principio. Esto sucede en el diseño y en cualquier construcción de sistemas complejos.

En nuestro caso, IaC nos ayuda a retroalimentar. Inmediatamente hago un pequeño ajuste al diagrama anterior: no tenemos un plan de lanzamiento mensual, pero sucedemos varias veces al día. Algunas prácticas están vinculadas a este ciclo del sistema operativo, que examinaremos con más detalle.

Importante: la retroalimentación puede ser la solución a todos los problemas mencionados anteriormente. Junto con las prácticas de XP, puede sacar la desesperación del abismo.

Cómo salir del abismo de la desesperación: tres prácticas

Pruebas

Las pruebas se mencionan dos veces en el ciclo de retroalimentación de XP. No es solo eso. Son extremadamente importantes para todas las técnicas de programación extremas.

Se supone que tiene pruebas de Unidad y Aceptación. Algunos le brindan comentarios en unos minutos, otros en pocos días, porque se escriben más tiempo y se ejecutan con menos frecuencia.

Hay una pirámide de prueba clásica, que muestra que debería haber más pruebas.



¿Cómo se aplica este esquema a nosotros en un proyecto de IaC? En realidad ... nada.

• Las pruebas unitarias, a pesar de que debería haber muchas, no pueden ser muchas. O están probando algo indirectamente. De hecho, podemos decir que no los escribimos en absoluto. Pero aquí hay algunas aplicaciones para tales pruebas, que aún logramos hacer:
  
  
  1. Código de prueba en jsonnet. Este, por ejemplo, es nuestro ensamblaje de tubería en dron, lo cual es bastante complicado. El código jsonnet está bien cubierto por las pruebas.
     Utilizamos este marco de prueba de la Unidad para Jsonnet .
  2. Prueba las secuencias de comandos que se ejecutan cuando se inicia el recurso. Se pueden escribir scripts en Python y, por lo tanto, probarlos.
• La verificación de la configuración en las pruebas es potencialmente posible, pero nosotros no. También es posible configurar la verificación de las reglas de configuración de recursos a través de tflint . Sin embargo, solo para terraform hay controles demasiado básicos, pero muchos scripts de prueba están escritos para AWS. Y estamos en Azure, por lo que esto no es adecuado nuevamente.
• Pruebas de integración de componentes: depende de cómo las clasifique y de dónde las coloque. Pero básicamente funcionan.
  
  Así es como se ven las pruebas de integración.
  
  
  
  Este es un ejemplo al ensamblar imágenes en Drone CI. Para llegar a ellos, debe esperar 30 minutos para que se junte la imagen de Packer, luego esperar otros 15 minutos para que pasen. Pero lo son!
  
  
  Algoritmo de Validación de Imagen

  1. Primero, Packer debe preparar la imagen por completo.
  2. Junto a la prueba hay una terraforma con un estado local, con el que desplegamos esta imagen.
  3. Al implementar, se usa un pequeño módulo junto a él para que sea más fácil trabajar con la imagen.
  4. Cuando la VM se implementa desde la imagen, puede comenzar a verificar. La mayoría de los controles se realizan en automóvil. Comprueba cómo funcionan los scripts en el inicio, cómo funcionan los demonios. Para hacer esto, a través de ssh o winrm, vamos a la máquina que se acaba de generar y verificamos el estado de la configuración o si los servicios han aumentado.

  
  
• Una situación similar con pruebas de integración y en módulos para terraform. Aquí hay una breve tabla que explica las características de tales pruebas.
  
  
  
  Tubería de retroalimentación en el área de 40 minutos. Todo lleva mucho tiempo. Se puede usar para la regresión, pero para un nuevo desarrollo generalmente no es realista. Si realmente, realmente se prepara para esto, prepara secuencias de comandos en ejecución, puede reducirlo a 10 minutos. Pero esto aún no son pruebas de Unidad, que son 100 piezas en 5 segundos.

La ausencia de pruebas unitarias durante el ensamblaje de imágenes o módulos de la terraforma alienta a cambiar el trabajo a servicios separados que simplemente pueden ser extraídos por REST, o por scripts de Python.

Por ejemplo, necesitábamos asegurarnos de que cuando la máquina virtual se iniciaba , se registraba en el servicio ScaleFT , y cuando destruía la máquina virtual, se eliminaba.

Dado que ScaleFT es un servicio, nos vemos obligados a trabajar con él a través de la API. Se escribió un contenedor que puede extraer y decir: "Entre y elimine esto, aquello". Almacena todos los ajustes y accesos necesarios.

Ya podemos escribir pruebas normales para esto, ya que no difiere de ninguna manera del software ordinario: alguna apiha se moja, usted tira y mira lo que sucede.

Resultados de la prueba: Las pruebas unitarias, que deberían proporcionar el sistema operativo en un minuto, no lo dan. Y los tipos más altos de pruebas en la pirámide dan efecto, pero solo una parte de los problemas están cubiertos.

Programación en pareja

Las pruebas son, por supuesto, buenas. Puedes escribir muchos de ellos, pueden ser de diferentes tipos. Trabajarán en sus niveles y nos darán su opinión. Pero el problema con las pobres pruebas unitarias, que dan el sistema operativo más rápido, persiste. Al mismo tiempo, sigue queriendo un sistema operativo rápido, es fácil y agradable trabajar con él. Sin mencionar la calidad de la solución. Afortunadamente, existen técnicas para dar retroalimentación aún más rápida que las pruebas unitarias. Esta es la programación de pares.

Cuando escribo código, quiero recibir comentarios sobre su calidad lo más rápido posible. Sí, puede escribir todo en la rama de características (para no revelar nada a nadie), hacer una solicitud de extracción en el github, asignarla a alguien cuya opinión tenga peso y esperar una respuesta.

Pero puedes esperar mucho tiempo. Todas las personas están ocupadas, y la respuesta, incluso si es así, puede no ser la más alta calidad. Supongamos que la respuesta llegó de inmediato, el revisor entendió al instante la idea completa, pero la respuesta aún llega tarde, ex post. Pero quiero algo antes. Aquí hay programación de pares y está dirigida a esto, de modo que inmediatamente, al momento de escribir.

Los siguientes son los estilos de programación de pares y su aplicabilidad al trabajar en IaC:

1. Clásico, experimentado + experimentado, cambio de temporizador. Dos roles: conductor y navegador. Dos personas Trabajan en un código y cambian roles después de un cierto período de tiempo predeterminado.

Considere la compatibilidad de nuestros problemas con el estilo:

• Problema: imperfección de herramientas, herramientas para el desarrollo de código.
  Impacto negativo: para desarrollarse más tiempo, disminuimos la velocidad, el ritmo / ritmo del trabajo se desvía.
  Cómo luchar: usamos otra afinación, un IDE común y aún aprendemos atajos.
• Problema: Despliegue lento.
  Impacto negativo: aumenta el tiempo para crear un código de trabajo. Echamos de menos mientras esperamos, las manos se dibujan para hacer otra cosa mientras espera.
  Cómo luchar: no superó.
• Problema: falta de enfoques y prácticas.
  Efecto negativo: no se sabe cómo hacer el bien, pero qué mal. Extiende la retroalimentación.
  Cómo luchar: el intercambio de opiniones y prácticas en el emparejamiento casi resuelve el problema.

El principal problema con la aplicación de este estilo a IaC a un ritmo desigual. En el desarrollo de software tradicional, tienes un movimiento muy uniforme. Puede pasar cinco minutos y escribir N. Pase 10 minutos y escriba 2N, 15 minutos - 3N. Aquí puedes pasar cinco minutos y escribir N, y luego pasar otros 30 minutos y escribir una décima parte de N. Aquí no sabes nada, tienes una mordaza, un tonto. La prueba lleva tiempo y distrae de la programación misma.

Conclusión: en su forma pura no nos conviene.

2. Ping-pong. Este enfoque supone que un participante está escribiendo una prueba y el otro está haciendo una implementación para él. Dado que todo es complicado con las pruebas unitarias, y tiene que escribir una prueba de integración larga, la facilidad del ping-pong ha desaparecido.

Puedo decir que intentamos separar las responsabilidades para diseñar un script de prueba e implementar código para él. A un participante se le ocurrió un guión, en esta parte del trabajo del que era responsable, tenía la última palabra. Y el otro fue responsable de la implementación. Funcionó bien. La calidad del escenario con este enfoque aumenta.

Conclusión: por desgracia, el ritmo de trabajo no permite el uso del ping-pong, como la práctica de la programación de pares en IaC.

3. Estilo fuerte. Práctica difícil La idea es que un participante se convierta en un navegador de directorios, y el segundo asuma el rol de un controlador en ejecución. En este caso, el derecho a tomar decisiones exclusivamente con el navegador. El controlador solo imprime y en una palabra puede afectar lo que está sucediendo. Los roles no cambian por mucho tiempo.

Muy adecuado para el entrenamiento, pero requiere fuertes habilidades blandas. En esto flaqueamos. La técnica fue difícil. Y el punto aquí no es ni siquiera la infraestructura.

Conclusión: potencialmente se puede aplicar, no renunciamos a los intentos.

4. Mobbing, enjambre y todos los estilos conocidos, pero no mencionados aquí no se consideran, porque No traté de decirlo en el contexto de nuestro trabajo no funcionará.

Resultados generales sobre el uso de la programación de pares:

• Tenemos un ritmo de trabajo desigual, que derriba.
• Nos encontramos con habilidades blandas insuficientemente buenas. Y el área temática no contribuye a superar estas deficiencias.
• Las pruebas largas, los problemas con las herramientas hacen que el desarrollo del par sea viscoso.

5. A pesar de esto, ha habido éxitos. Se nos ocurrió nuestro propio método de convergencia: divergencia. Describiré brevemente cómo funciona.

Tenemos socios regulares durante varios días (menos de una semana). Hacemos una tarea juntos. Por un tiempo nos sentamos juntos: uno escribe, el segundo se sienta y mira como equipo de soporte. Luego no estamos de acuerdo por un tiempo, todos hacen algunas cosas independientes, luego convergemos nuevamente, sincronizamos muy rápido, hacemos algo juntos y nuevamente divergemos.

Planificación y comunicación.

El último bloque de prácticas a través del cual se resuelven los problemas del sistema operativo es la organización del trabajo con las tareas mismas. Esto también incluye el intercambio de experiencias, que está fuera del trabajo en pareja. Considere tres prácticas:

1. Tareas a través del árbol de objetivos. Organizamos la gestión general del proyecto a través de un árbol que va infinitamente hacia el futuro. Técnicamente, el liderazgo se hace en Miro. Hay una tarea: es un objetivo intermedio. O bien objetivos más pequeños o grupos de tareas van de él. De ellos son las tareas mismas. Todas las tareas se crean y realizan en este tablero.



Este esquema también proporciona comentarios que ocurren una vez al día cuando sincronizamos en las manifestaciones. La presencia frente a todos de un plan común, aunque estructurado y completamente abierto, permite a todos mantenerse al tanto de lo que está sucediendo y hasta dónde hemos progresado.

Ventajas de la visión visual de las tareas:

• Causalidad Cada tarea lleva a una meta global. Las tareas se agrupan en objetivos más pequeños. El dominio de la infraestructura en sí es bastante técnico. No siempre está claro de inmediato qué impacto específico se ejerce en el negocio, por ejemplo, escribiendo un libro de calificaciones sobre la migración a otro nginx. La presencia de una carta objetivo cercana lo hace más claro.
  
  La causalidad es una propiedad importante de las tareas. Responde directamente a la pregunta: "¿Lo estoy haciendo?"
• Paralelismo Somos nueve, y es imposible atacar a todos con una tarea simplemente física. Es posible que las tareas de un área no siempre sean suficientes. Estamos obligados a trabajar en paralelo entre pequeños grupos de trabajo. Al mismo tiempo, los grupos se sientan en su tarea por algún tiempo, pueden ser fortalecidos por otra persona. La gente a veces se cae de este grupo de trabajo. Alguien se va de vacaciones, alguien hace un informe para la conferencia de conf DevOps, alguien escribe un artículo sobre Habr. Saber qué metas y objetivos se pueden hacer en paralelo se vuelve muy importante.

2. Presentadores cambiantes de manifestaciones matutinas. En los stand-ups, tenemos ese problema: las personas realizan muchas tareas en paralelo. A veces, las tareas se acoplan libremente y no se comprende quién está haciendo qué. Y la opinión de otro miembro del equipo es muy importante. Esta es información adicional que puede cambiar el curso de la resolución de un problema. Por supuesto, generalmente alguien está emparejado con usted, pero las consultas y los consejos no siempre son superfluos.

Para mejorar esta situación, aplicamos la técnica de "Cambiar el stand-up líder". Ahora rotan en una lista específica, y esto tiene su efecto. Cuando se trata de usted, se ve obligado a sumergirse y comprender lo que está sucediendo para llevar a cabo una reunión de scrum bien.



3. Demostración interna. La asistencia para resolver problemas de la programación de pares, la visualización en el árbol de tareas y la ayuda en las reuniones de scrum en la mañana es buena, pero no perfecta. En una pareja solo estás limitado por tu conocimiento. El árbol de tareas lo ayuda a comprender globalmente quién hace qué. Y el anfitrión y sus colegas en la reunión de la mañana no se sumergirán profundamente en sus problemas. Ciertamente pueden perder algo.

La solución se encontró demostrando el trabajo realizado entre ellos y su posterior discusión. Nos reunimos una vez por semana durante una hora y mostramos detalles de soluciones a las tareas que hemos realizado durante la semana pasada.

En el proceso de demostración, es necesario revelar los detalles de la tarea y asegurarse de demostrar su trabajo.


Después de la parte de tiempo completo, siempre hay una discusión en el hilo. Aquí es donde aparece la retroalimentación necesaria sobre nuestras tareas.


Como resultado, se realiza una encuesta para identificar la utilidad de lo que está sucediendo. Esto ya es retroalimentación sobre la esencia del discurso y la importancia de la tarea.

Largas conclusiones y lo que sigue

Puede parecer que el tono del artículo es algo pesimista. Esto no es asi. Dos niveles de retroalimentación de base, a saber, pruebas y programación de pares, funcionan. No es tan perfecto como en el desarrollo tradicional, pero esto tiene un efecto positivo.

Las pruebas, en su forma actual, proporcionan solo una cobertura parcial del código. Muchas funciones de configuración no se prueban. Su influencia en el trabajo directo cuando se escribe código es baja. Sin embargo, las pruebas de integración tienen un efecto, y son ellas las que hacen posible realizar refactorizaciones sin temor. Este es un gran logro. Además, con la transferencia del enfoque al desarrollo en lenguajes de alto nivel (tenemos python, go), el problema desaparece. Pero hay muchos controles sobre el "pegamento" y no hay necesidad de una integración suficientemente general.

El trabajo en parejas depende más de personas específicas. Hay un factor de tarea y nuestras habilidades blandas. Resulta muy bien con alguien, peor con alguien. Definitivamente hay un beneficio de esto. Está claro que incluso con una observancia insuficiente de las reglas del trabajo en pareja, el hecho de la ejecución conjunta de tareas afecta positivamente la calidad del resultado. Personalmente, funciona más fácil y más agradable para mí en un par.

Formas de alto nivel para influir en el sistema operativo: la planificación y el trabajo con tareas dan precisamente los efectos: un intercambio de conocimiento de alta calidad y una mejora en la calidad del desarrollo.

Conclusiones cortas en una línea.

• Las prácticas de XP funcionan en IaC, pero con menos eficiencia.
• Fortalece lo que funciona.
• Diseñe sus propios mecanismos y prácticas compensatorias.