🥇Infrastructure as Code: cómo superar problemas con XP

¡Hola, Habr! Antes me quejaba de la vida en la paradigma de Infrastructure as Code y no ofrecía nada para solucionar la situación. Hoy he vuelto para contar qué enfoques y prácticas pueden ayudar a salir del abismo de la desesperación y encaminar la situación de manera correcta.

En el artículo anterior «Infrastructure as Code: primer acercamiento» Compartía mis impresiones sobre este ámbito, intentaba reflexionar sobre la situación actual en este campo e incluso sugería que las prácticas estándar, conocidas por todos los desarrolladores, pueden ayudar. Podría haber parecido que había muchas quejas sobre la vida, pero no había propuestas para salir de esta situación.

Quiénes somos, dónde estamos y cuáles son nuestros problemas

Actualmente estamos en el SRE Onboarding Team, que consiste en seis programadores y tres ingenieros de infraestructura. Todos estamos tratando de escribir Infrastructure as Code (IaC). Lo hacemos porque, en principio, sabemos escribir código y en el pasado hemos sido desarrolladores de nivel «superior al promedio».

Tenemos un conjunto de ventajas: un cierto trasfondo, conocimientos de prácticas, habilidades para escribir código y deseos de aprender cosas nuevas.
Y hay una parte débil, que es un inconveniente: la falta de conocimientos en la materia de infraestructura.

El stack de tecnologías que utilizamos en nuestro IaC.

Terraform para crear recursos.
Packer para construir imágenes. Estas son imágenes de Windows y CentOS 7.
Jsonnet, para hacer poderosas construcciones en drone.io, así como para generar json de packer y nuestros módulos de Terraform.
Azure.
Ansible al preparar las imágenes.
Python para servicios auxiliares, así como scripts de aprovisionamiento.
Y todo esto en VSCode con plugins compartidos entre los miembros del equipo.

La conclusión de mi del artículo anterior fue la siguiente: intentaba inculcar (primordialmente a mí mismo) optimismo, quería decir que probaríamos los enfoques y prácticas que conocemos para enfrentar las dificultades y retos que existen en este campo.

Actualmente estamos enfrentando los siguientes problemas de IaC:

Imperfecciones de las herramientas y medios para desarrollar código.
Despliegue lento. La infraestructura es parte del mundo real, y este puede no ser rápido.
Falta de enfoques y prácticas.
Somos nuevos y no sabemos mucho.

La programación extrema (XP) viene al rescate.

A todos los desarrolladores les resulta bien conocido el desarrollo extremo (XP) y las prácticas que lo respaldan. Muchos de nosotros hemos trabajado con este enfoque, y ha sido 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é resulta de ello.

Evaluación de la aplicabilidad del enfoque XP a su ámbitoA continuación, presento una descripción del entorno para el cual XP es adecuado y cómo se relaciona con nosotros:

1. Requisitos de software que cambian dinámicamente. Teníamos claro cuál era el objetivo final. Pero se pueden variar los detalles. Nosotros mismos decidimos hacia dónde debemos dirigirnos, por lo que los requisitos cambian periódicamente (principalmente por nuestra parte). Si consideramos a un equipo de SRE que realiza la automatización y también limita los requisitos y el alcance del trabajo, este punto encaja bien.

2. Riesgos causados por proyectos de tiempo fijo que utilizan tecnología nueva. Pueden surgir riesgos al utilizar cosas que no conocemos. Y ese es nuestro caso al 100%. Todo nuestro proyecto implica el uso de tecnologías con las que no estábamos completamente familiarizados. En general, este es un problema constante, ya que en el campo de la infraestructura emergen continuamente muchas tecnologías nuevas.

3,4. Pequeño equipo de desarrollo extendido y coubicado. La tecnología que estás utilizando permite pruebas automáticas unitarias y funcionales. Estos dos puntos no nos aplican del todo. En primer lugar, no somos un equipo coubicado; en segundo lugar, somos nueve personas, lo que puede considerarse un equipo grande. Sin embargo, según algunas definiciones, un 'gran' equipo se compone de 14 o más personas.

Consideremos algunas prácticas de XP y cómo influyen en la velocidad y calidad de la retroalimentación.

El principio del ciclo de retroalimentación en XP

En mi entendimiento, la retroalimentación es la respuesta a la pregunta de si estoy haciendo lo correcto, si vamos en la dirección adecuada. En XP existe un esquema maravilloso al respecto: el ciclo de retroalimentación en el tiempo. La curiosidad radica en que, cuanto más bajo estamos, más rápido podemos obtener el feedback necesario para responder a las preguntas relevantes.

Este es un tema bastante interesante para discutir, ya que en nuestra industria de TI es posible obtener rápidamente retroalimentación. Imagínese lo difícil que es trabajar en un proyecto durante seis meses y solo luego enterarse de que se cometió un error al principio. Esto puede suceder tanto en el diseño como en la construcción de sistemas complejos.

En nuestro caso, IaC nos ayuda a obtener retroalimentación. Hago un pequeño ajuste en el esquema anterior: el plan de lanzamiento no tiene un ciclo mensual, sino que ocurre varias veces al día. A este ciclo están vinculadas ciertas prácticas que examinaremos en detalle.

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

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 casualidad. Son extremadamente importantes para toda la técnica de programación extrema.

Se supone que tienes pruebas de unidad y pruebas de aceptación. Algunas te dan retroalimentación en unos minutos, otras en unos días, por lo que se escriben más lentamente y se ejecutan con menos frecuencia.

Hay una pirámide de pruebas clásica que muestra que debe haber más de algunos tipos de pruebas.

¿Cómo se aplica este esquema a nuestro proyecto IaC? En realidad... no se aplica.

No puede haber demasiadas pruebas unitarias, a pesar de que deberían ser muchas. O bien prueban algo de manera muy indirecta. De hecho, se puede decir que casi no las escribimos. Pero aquí hay algunas aplicaciones para esas pruebas que sí hemos logrado hacer:
1. Pruebas de código en jsonnet. Por ejemplo, nuestro pipeline de compilación en drone, que es bastante complejo. El código en jsonnet está bien cubierto por pruebas.
  Usamos este Unit testing framework for Jsonnet.
2. Pruebas en scripts que se ejecutan al iniciar el recurso. Los scripts están en Python, por lo que también se pueden escribir pruebas para ellos.
Potencialmente, es posible verificar la configuración en las pruebas, pero no lo hacemos. También hay una posibilidad de configurar la verificación de las reglas de configuración de recursos a través de tflint. Sin embargo, simplemente para Terraform, las verificaciones son bastante básicas, aunque se han escrito muchos escenarios de verificación para AWS. Y nosotros estamos en Azure, así que eso nuevamente no se aplica.
Pruebas de integración de componentes: aquí depende de cómo las clasificas y dónde las distribuyes. Pero, en principio, funcionan.
Así es como se ven las pruebas de integración.

Este es un ejemplo durante la construcción de imágenes en Drone CI. Para llegar a ellas, debes esperar 30 minutos mientras se construye la imagen de Packer, luego otros 15 minutos para que pasen. ¡Pero existen!
Algoritmo de verificación de imágenes
1. Primero, Packer debe preparar completamente la imagen.
2. Junto a la prueba hay un terraform con estado local, que usamos para desplegar esta imagen.
3. Al desplegar, se utiliza un pequeño módulo cercano para facilitar el trabajo con la imagen.
4. Una vez que la VM se ha desplegado desde la imagen, se pueden iniciar las verificaciones. Principalmente, las pruebas se realizan en la máquina. Se verifica cómo funcionaron los scripts al iniciar y cómo trabajan los demonios. Para ello, accedemos a la máquina recién levantada a través de ssh o winrm y comprobamos el estado de la configuración o si los servicios se han levantado.
La situación es similar con las pruebas de integración y en los módulos para terraform. Aquí hay una tabla breve que explica las características de tales pruebas.

El feedback en el pipeline es de aproximadamente 40 minutos. Todo ocurre muy lentamente. Se puede utilizar para regresión, pero para nuevo desarrollo es completamente imposible. Si te preparas muy bien, preparas running, scripts, puedes reducirlo a 10 minutos. Pero aun así, no son pruebas Unitarias que se pueden ejecutar 100 en 5 segundos.

La falta de pruebas Unitarias al construir imágenes o módulos de terraform obliga a delegar el trabajo en servicios separados, que simplemente se pueden invocar a través de REST, o en scripts de Python.

Por ejemplo, necesitábamos hacer que al iniciar la máquina virtual, se registrara en el servicio ScaleFT, y al destruir la VM, se eliminara a sí misma.

Dado que ScaleFT es un servicio, nos vemos obligados a trabajar con él a través de la API. Se escribió un wrapper que se puede invocar y decir: "Ve y elimina esto, esto y aquello". Almacena todas las configuraciones y accesos necesarios.

Sobre esto ya podemos escribir pruebas normales, ya que no se diferencia de un software común: se moca una API, la llamas y observas qué ocurre.

Resultados de las pruebas: Las pruebas unitarias que deberían dar el SO en un minuto no lo hacen. Y tipos de pruebas más altas en la pirámide dan efecto, pero solo cubren una parte de los problemas.

Programación en pareja

Las pruebas son, por supuesto, importantes. Se pueden escribir muchas y pueden ser de varios tipos. Funcionarán en sus niveles y nos proporcionarán retroalimentación. Pero el problema con las malas pruebas unitarias, que proporcionan el sistema operativo más rápido, persiste. Aún así, se desea un sistema operativo rápido, con el que sea fácil y agradable trabajar. Sin mencionar la calidad de la solución obtenida. Afortunadamente, existen técnicas que permiten dar una retroalimentación incluso más rápida que las pruebas modulares. Eso es la programación en pareja.

Al escribir código, se desea obtener retroalimentación sobre su calidad lo más rápido posible. Sí, se puede escribir todo en una rama de características (para no romper nada a nadie), hacer una solicitud de extracción en GitHub, asignar a alguien cuyo criterio tenga peso y esperar la respuesta.

Pero la espera puede ser larga. Todos están ocupados, y la respuesta, incluso si llega, puede no ser de la más alta calidad. Supongamos que la respuesta llegó de inmediato, que el revisor entendió de inmediato toda la intención, pero aún así llega con retraso, a posteriori. Y se desea antes. Eso es precisamente lo que busca la programación en pareja: obtener respuestas inmediatamente, en el momento de escribir.

A continuación, presento los estilos de programación en pareja y su aplicabilidad en el trabajo sobre IaC:

1. Clásico, experimentado + experimentado, cambio por temporizador. Dos roles: conductor y navegador. Dos personas. Trabajan sobre el mismo código y cambian de roles en un intervalo de tiempo previamente determinado.

Consideremos la compatibilidad de nuestros problemas con el estilo:

Problema: imperfección de las herramientas y medios para el desarrollo de código.
Influencia negativa: desarrollo más lento, nos ralentizamos, se rompe el ritmo del trabajo.
Cómo lo enfrentamos: aplicamos diferentes herramientas, IDE compartido y también aprendemos atajos.
Problema: despliegue lento.
Influencia negativa: aumenta el tiempo necesario para crear una parte funcional del código. Nos aburrimos mientras esperamos, nuestras manos se ven atraídas a hacer algo más mientras esperamos.
Cómo lo enfrentamos: no lo hemos resuelto.
Problema: falta de enfoques y prácticas.
Influencia negativa: no hay conocimiento sobre lo que se hace bien y lo que se hace mal. Alarga la obtención de retroalimentación.
Cómo lo enfrentamos: el intercambio de opiniones y prácticas en el trabajo en pareja casi resuelve el problema.

El principal problema al aplicar este estilo en IaC es el ritmo irregular de trabajo. En el desarrollo de software tradicional, el avance es mucho más uniforme. Puedes gastar cinco minutos y escribir N, diez minutos y escribir 2N, quince minutos - 3N. Aquí, en cambio, puedes gastar cinco minutos y escribir N, y luego dedicar otros 30 minutos y escribir una décima parte de N. Aquí no sabes nada, te atascas, no avanzas. El desentramado lleva tiempo y distrae de la programación en sí.

Conclusión: en su forma pura no nos es adecuado.

2. Ping-pong. Este enfoque supone que un participante escribe una prueba y el otro realiza la implementación. Teniendo en cuenta que con las pruebas unitarias todo es complicado y es necesario escribir una prueba de integración que consume mucho tiempo, toda la ligereza del ping-pong desaparece.

Puedo decir que hemos probado la división de responsabilidades en el diseño del escenario de prueba y la implementación del código para ello. Un participante ideaba el escenario, en esta parte del trabajo era responsable y tenía la última palabra. El otro se encargaba de la implementación. Esto resultó ser efectivo. La calidad del escenario mejora con este enfoque.

Conclusión: lamentablemente, el ritmo de trabajo no permite utilizar el ping-pong como práctica de programación en pareja en IaC.

3. Strong Style. Práctica compleja.La idea es que un participante se convierte en el navegador directivo, mientras que el segundo asume el rol de conductor ejecutor. En este caso, el derecho a tomar decisiones corresponde exclusivamente al navegador. El conductor solo escribe y puede influir en lo que sucede con sus palabras. Los roles no cambian durante un largo tiempo.

Es muy adecuado para la enseñanza, pero requiere habilidades blandas fuertes. Aquí es donde nos encontramos con dificultades. La técnica resultó ser complicada. Y no se trata solo de la infraestructura.

Conclusión: potencialmente puede aplicarse, no nos rendimos en el intento.

4. Mobbing, swarming y todos los estilos conocidos, pero no mencionados aquí. no se consideran, ya que no los hemos probado y no podemos hablar de ellos en el contexto de nuestro trabajo.

Resumen general sobre el uso de la programación en pareja:

Tenemos un ritmo de trabajo desigual que interfiere.

Hemos topado con habilidades blandas insuficientemente buenas. Y el área temática no facilita la superación de estas deficiencias.

Pruebas largas y problemas con las herramientas hacen que el desarrollo en pareja sea engorroso.

5. A pesar de esto, también hubo éxitos. Inventamos nuestro propio método 'Convergencia - Divergencia'. Describiré brevemente cómo funciona.

Tenemos socios constantes por algunos días (menos de una semana). Realizamos una tarea en conjunto. Pasamos un tiempo juntos: uno escribe, el otro observa, como en un equipo de soporte. Luego nos separamos por un tiempo, cada uno realiza algunas tareas independientes, después volvemos a reunirnos, sincronizamos rápidamente, hacemos algo juntos y de nuevo nos separamos.

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 propias tareas. Esto incluye el intercambio de experiencias que está fuera del trabajo en pareja. Consideremos tres prácticas:

1. Tareas a través del árbol de objetivos. La gestión general del proyecto la organizamos a través de un árbol que se adentra infinitamente en el futuro. Técnicamente se lleva a cabo en Miro. Hay una tarea, que es un objetivo intermedio. De ella surgen objetivos más pequeños o grupos de tareas. Desde ellos, se generan las propias tareas. Todas las tareas se crean y gestionan en esta pizarra.

Este esquema también proporciona retroalimentación, que ocurre una vez al día, cuando nos sincronizamos en las reuniones. Tener un plan común ante todos, estructurado y completamente abierto, permite que cada uno esté al tanto de lo que está sucediendo y de cuánto hemos avanzado en el progreso.

Ventajas de la visión visual de las tareas:

Causalidad. Cada tarea lleva a algún objetivo global. Las tareas se agrupan por objetivos más pequeños. El dominio de la infraestructura en sí es bastante técnico. No siempre es evidente cuál es la influencia específica que, por ejemplo, tiene la redacción de un manual de migración a otro nginx sobre el negocio. Tener una tarjeta de objetivo junto a ello lo hace más comprensible.

La causalidad es una propiedad importante de las tareas. Responde directamente a la pregunta: '¿Estoy haciendo lo correcto?'
Paralelismo. Somos nueve personas y es físicamente imposible abordar una tarea todos a la vez. Las tareas de un mismo ámbito tampoco siempre son suficientes. Nos vemos obligados a paralelizar el trabajo entre pequeños grupos de trabajo. En este contexto, los grupos se dedican un tiempo a su tarea y pueden ser reforzados por alguien más. A veces, algunas personas de este grupo se retiran. Alguien puede irse de vacaciones, otro puede estar preparando una presentación para la conferencia DevOps conf, o alguien más puede estar escribiendo un artículo para Habr. Es muy importante saber qué objetivos y tareas se pueden realizar en paralelo.

2. Líderes alternos de las reuniones matutinas. En los stand-ups ha surgido un problema: muchas tareas se realizan en paralelo. A veces, las tareas están débilmente conectadas y no hay entendimiento sobre quién está haciendo qué. La opinión de otro miembro del equipo es muy importante. Es información adicional que puede cambiar el rumbo de la solución de la tarea. Claro que, normalmente, hay alguien contigo en pareja, pero la consulta y los consejos siempre son bienvenidos.

Para mejorar esta situación, aplicamos la técnica de "Cambio de líder del stand-up". Ahora rotan según una lista determinada, y esto tiene su efecto. Cuando te llega el turno, te ves obligado a sumergirte y entender qué está pasando, para llevar bien la reunión scrum.

3. Demos internas. La ayuda en la resolución de tareas a través de programación en pareja, la visualización en el árbol de tareas y la asistencia en las reuniones scrum por la mañana es buena, pero no es perfecta. En pareja, estás limitado solo por tus conocimientos. El árbol de tareas ayuda a entender globalmente quién hace qué. Y el líder y los colegas en la reunión matutina no profundizarán en tus problemas. Seguramente podrán pasar por alto algo.

La solución fue encontrar una forma de mostrar el trabajo realizado entre nosotros y discutirlo posteriormente. Nos reunimos una vez a la semana durante una hora y mostramos los detalles de las soluciones a las tareas que hicimos en la última semana.

Durante la demostración, hay que dar detalles de la tarea y mostrar su funcionamiento.

El informe se puede realizar según una lista de verificación.1. Establece el contexto. ¿De dónde surgió la tarea, por qué era necesaria?

2. ¿Cómo se resolvió la tarea anteriormente? Por ejemplo, ¿se requerían múltiples clics con un mouse, o era imposible hacer algo en absoluto?

3. ¿Cómo mejoramos esto? Por ejemplo: "Miren, ahora hay un pequeño script, aquí está el readme".

4. Muestre cómo funciona. Preferiblemente realice algún escenario de usuario. Quiero X, hago Y, veo Y (o Z). Por ejemplo, despliego NGINX, consulto la URL, obtengo 200 OK. Si la acción es larga, prepárela con antelación para luego mostrarla. Preferiblemente, aproximadamente una hora antes de la demo, no rompa nada importante, si es frágil.

5. Explique qué tan exitosamente se ha abordado el problema, qué dificultades persisten, qué no se ha completado, qué mejoras son posibles en el futuro. Por ejemplo, ahora hay CLI, después habrá una automatización completa en CI.

Es deseable que cada orador se limite a 5-10 minutos. Si su intervención es claramente importante y tomará más tiempo, coordine esto con anticipación en el canal sre-takeover.

Después de la parte presencial, es obligatorio un debate en el hilo. Aquí es donde aparece la retroalimentación necesaria sobre las tareas.

Al final, se realiza una encuesta para evaluar la utilidad de lo sucedido. Esta es ya una retroalimentación sobre el contenido de la presentación y la importancia de la tarea.

Conclusiones largas y qué sigue

Puede parecer que el tono del artículo es algo pesimista. No es así. Dos niveles básicos de obtención de retroalimentación, a saber, pruebas y programación en pareja, funcionan. No de manera tan perfecta como en el desarrollo tradicional, pero hay un efecto positivo.

Las pruebas, en su forma actual, proporcionan solo una cobertura parcial del código. Muchas funciones de configuración quedan sin probar. Su impacto en el trabajo inmediato al escribir código es bajo. Sin embargo, hay efecto de las pruebas de integración, y son precisamente ellas las que permiten realizar refactorizaciones sin miedo. Este es un gran logro. Además, con el cambio de enfoque hacia el desarrollo en lenguajes de alto nivel (tenemos python, go) el problema desaparece. Y para el 'pegamento' se requieren muchas verificaciones y no es necesario, solo es suficiente una integración general.

El trabajo en pareja depende más de las personas concretas. Está el factor de la tarea y nuestras habilidades blandas. Con algunos resulta muy bien, con otros peor. Definitivamente hay beneficios. Es claro que incluso con un cumplimiento deficiente de las reglas del trabajo en pareja, el simple hecho de realizar tareas conjuntamente influencia positivamente la calidad del resultado. Personalmente, me resulta más fácil y agradable trabajar en pareja.

Métodos más de alto nivel para influir en el sistema operativo: la planificación y el trabajo con tareas ciertamente producen efectos: un intercambio de conocimientos de calidad y una mejora en la calidad del desarrollo.