Infraestructura como código: cómo superar los problemas usando XP

¡Hola Habr! Anteriormente me quejé de la vida en la infraestructura como paradigma de código y no ofrecí nada para solucionar la situación actual. Hoy vuelvo para contarte qué enfoques y prácticas te ayudarán a escapar del abismo de la desesperación y a dirigir la situación en la dirección correcta.

En un artículo anterior "Infraestructura como código: primer contacto" Compartí mis impresiones sobre 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 podrían ayudar. Podría parecer que hubo muchas quejas sobre la vida, pero no hubo propuestas para salir de la situación actual.

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

Actualmente estamos en el Sre Onboarding Team, que consta de seis programadores y tres ingenieros de infraestructura. Todos intentamos escribir infraestructura como código (IaC). Hacemos esto porque básicamente sabemos cómo escribir código y tenemos un historial de ser desarrolladores "por encima del promedio".

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

La pila de tecnología que utilizamos en nuestro IaC.

• Terraform para la creación de recursos.
• Empaquetador para ensamblar imágenes. Estas son imágenes de Windows, CentOS 7.
• Jsonnet para crear una compilación potente en drone.io, así como para generar packer json y nuestros módulos terraform.
• Azure.
• Ansible al preparar imágenes.
• Python para servicios auxiliares y scripts de aprovisionamiento.
• Y todo esto en VSCode con complementos compartidos entre los miembros del equipo.

Conclusión de mi ultimo articulo fue así: traté de infundirme (en primer lugar a mí mismo) optimismo, quería decir que probaremos los enfoques y prácticas que conocemos para abordar las dificultades y complejidades que existen en esta área.

Actualmente estamos luchando con los siguientes problemas de IaC:

• Imperfección de herramientas y medios para el 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 que la respaldan. Muchos de nosotros hemos trabajado con este enfoque y ha tenido éxito. Entonces, ¿por qué no utilizar los principios y prácticas allí establecidos para superar los desafíos de infraestructura? Decidimos adoptar este enfoque y ver qué sucede.

Comprobar la aplicabilidad del enfoque XP en su industriaAquí hay una descripción del entorno para el que 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 los detalles pueden variar. Nosotros mismos decidimos dónde tenemos que rodar, por lo que los requisitos cambian periódicamente (principalmente por nosotros mismos). Si tomamos al equipo de SRE, que realiza la automatización por sí mismo y limita él mismo los requisitos y el alcance del trabajo, entonces este punto encaja bien.

2. Riesgos causados ​​por proyectos de tiempo fijo que utilizan nuevas tecnologías. Podemos encontrarnos con riesgos al utilizar algunas cosas que desconocemos. Y este es 100% nuestro caso. Todo nuestro proyecto consistió en el uso de tecnologías con las que no estábamos completamente familiarizados. En general, este es un problema constante, porque... Constantemente surgen muchas tecnologías nuevas en el sector de infraestructura.

3,4. Equipo de desarrollo extendido pequeño y ubicado en el mismo lugar. La tecnología automatizada que está utilizando permite pruebas unitarias y funcionales. Estos dos puntos no nos convienen del todo. En primer lugar, no somos un equipo coordinado y, en segundo lugar, somos nueve, lo que puede considerarse un equipo grande. Aunque, según algunas definiciones de equipo "grande", muchos son más de 14 personas.

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

Principio del bucle de retroalimentación de XP

Según tengo entendido, la retroalimentación es la respuesta a la pregunta: ¿estoy haciendo lo correcto? ¿Vamos hacia allí? XP tiene un plan divino para esto: un circuito de retroalimentación temporal. Lo interesante es que cuanto más bajos estemos, más rápido podremos conseguir que el SO responda las preguntas necesarias.

Un tema de discusión bastante interesante es que en nuestra industria de TI es posible obtener rápidamente un sistema operativo. Imagínese lo doloroso que es hacer un proyecto durante seis meses y sólo entonces descubrir que hubo un error desde el principio. Esto sucede en el diseño y en cualquier construcción de sistemas complejos.

En nuestro caso de IaC, la retroalimentación nos ayuda. Inmediatamente haré un pequeño ajuste al diagrama anterior: el plan de lanzamiento no tiene un ciclo mensual, sino que ocurre varias veces al día. Hay algunas prácticas vinculadas a este ciclo del sistema operativo que veremos con más detalle.

Importante: la retroalimentación puede ser una solución a todos los problemas mencionados anteriormente. Combinado con 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 sólo así. Son extremadamente importantes para toda la técnica de Programación Extrema.

Se supone que tiene pruebas unitarias y de aceptación. Algunos le brindan comentarios en unos minutos, otros en unos días, por lo que tardan más en escribirse y se revisan con menos frecuencia.

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

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

• Las pruebas unitarias, a pesar de que debería haber muchas, no pueden ser demasiadas. O están probando algo de forma muy indirecta. De hecho, podemos decir que no los escribimos en absoluto. Pero aquí hay algunas aplicaciones para este tipo de pruebas que pudimos realizar:
  1. Probando el código jsonnet. Éste, por ejemplo, es nuestro proceso de montaje de drones, que es bastante complicado. El código jsonnet está bien cubierto por pruebas.
     Usamos esto Marco de pruebas unitarias para Jsonnet.
  2. Pruebas de scripts que se ejecutan cuando se inicia el recurso. Los scripts están escritos en Python y, por lo tanto, se pueden escribir pruebas en ellos.
• Es potencialmente posible comprobar la configuración en las pruebas, pero no lo hacemos. También es posible configurar la verificación de reglas de configuración de recursos a través de pedernal. Sin embargo, las comprobaciones son simplemente demasiado básicas para terraform, pero muchos scripts de prueba están escritos para AWS. Y estamos en Azure, por lo que esto nuevamente no se aplica.
• Pruebas de integración de componentes: depende de cómo los clasifiques y dónde los coloques. Pero básicamente funcionan.

  Así es como se ven las pruebas de integración.

  
  
  Este es un ejemplo de creación de imágenes en Drone CI. Para llegar a ellos, debe esperar 30 minutos para que se forme la imagen de Packer y luego esperar otros 15 minutos para que pasen. ¡Pero existen!

  Algoritmo de verificación de imágenes

  1. Packer primero debe preparar la imagen por completo.
  2. Al lado de la prueba hay una terraforma con un estado local, que usamos para implementar esta imagen.
  3. Al desplegarlo, se utiliza un pequeño módulo que se encuentra cerca para facilitar el trabajo con la imagen.
  4. Una vez que la VM se implementa desde la imagen, pueden comenzar las comprobaciones. Básicamente, los controles se realizan en coche. Comprueba cómo funcionaron los scripts al inicio y cómo funcionan los demonios. Para ello, vía ssh o winrm iniciamos sesión en la máquina recién levantada y comprobamos el estado de configuración o si los servicios están activos.

• La situación es similar con las pruebas de integración en módulos para terraform. A continuación se muestra una breve tabla que explica las características de dichas pruebas.

  
  
  La retroalimentación sobre el oleoducto dura alrededor de 40 minutos. Todo sucede durante mucho tiempo. Puede usarse para la regresión, pero para el nuevo desarrollo generalmente no es realista. Si está muy, muy preparado para esto, prepare los scripts en ejecución, luego puede reducirlo a 10 minutos. Pero todavía no son pruebas unitarias, que hacen 5 piezas en 100 segundos.

La ausencia de pruebas unitarias al ensamblar imágenes o módulos de terraform fomenta el cambio de trabajo a servicios separados que pueden ejecutarse simplemente a través de REST o scripts de Python.

Por ejemplo, necesitábamos asegurarnos de que cuando se inicie la máquina virtual, se registre en el servicio. EscalaFT, y cuando la máquina virtual fue destruida, se eliminó sola.

Como tenemos ScaleFT como servicio, nos vemos obligados a trabajar con él a través de la API. Había un envoltorio escrito allí que podías sacar y decir: "Entra y elimina esto y aquello". Almacena todas las configuraciones y accesos necesarios.

Ya podemos escribir pruebas normales para esto, ya que no se diferencia del software común: se burla de algún tipo de apiha, lo extraes y ves qué sucede.

Resultados de las pruebas: Las pruebas unitarias, que deberían dar el sistema operativo en un minuto, no lo dan. Y los tipos de pruebas que se encuentran más arriba en la pirámide son efectivos, pero cubren sólo una parte de los problemas.

Programación en pareja

Las pruebas, por supuesto, son 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 malas pruebas unitarias, que dan el sistema operativo más rápido, persiste. Al mismo tiempo, todavía quiero un sistema operativo rápido con el que sea fácil y agradable trabajar. Por no hablar de la calidad de la solución resultante. Afortunadamente, existen técnicas que pueden proporcionar retroalimentación incluso más rápida que las pruebas unitarias. Esta es la programación en pares.

Al escribir código, desea obtener comentarios sobre su calidad lo más rápido posible. Sí, puedes escribir todo en una rama de características (para no romperle nada a nadie), hacer una solicitud de extracción en Github, asignarla a alguien cuya opinión tenga peso y esperar una respuesta.

Pero puedes esperar mucho tiempo. Toda la gente está ocupada y la respuesta, incluso si la hay, puede no ser de la más alta calidad. Supongamos que la respuesta llegó de inmediato, el revisor entendió instantáneamente toda la idea, pero la respuesta aún llega tarde, después del hecho. Ojalá fuera antes. Esto es a lo que apunta la programación en pares, de inmediato, en el momento de escribir este artículo.

A continuación se muestran los estilos de programación en pares y su aplicabilidad al trabajar en IaC:

1. Clásico, Experimentado+Experimentado, turno por cronómetro. Dos roles: conductor y navegador. Dos personas. Trabajan con el mismo código y cambian de roles después de un cierto período de tiempo predeterminado.

Consideremos la compatibilidad de nuestros problemas con el estilo:

• Problema: imperfección de herramientas y herramientas para el desarrollo de código.
  Impacto negativo: tardamos más en desarrollarnos, bajamos el ritmo, se pierde el ritmo de trabajo.
  Cómo luchamos: utilizamos una herramienta diferente, un IDE común y también aprendemos atajos.
• Problema: implementación lenta.
  Impacto negativo: aumenta el tiempo necesario para crear un código funcional. Nos aburrimos mientras esperamos, nuestras manos se extienden para hacer otra cosa mientras esperamos.
  Cómo luchamos: no lo superamos.
• Problema: falta de enfoques y prácticas.
  Impacto negativo: no se sabe cómo hacerlo bien y cómo hacerlo mal. Alarga la recepción de feedback.
  Cómo luchamos: el intercambio mutuo de opiniones y prácticas en el trabajo en pareja casi resuelve el problema.

El principal problema al utilizar este estilo en IaC es el ritmo desigual de trabajo. En el desarrollo de software tradicional, el movimiento es muy uniforme. Puedes pasar cinco minutos y escribir N. Pasar 10 minutos y escribir 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, estás estancado, estúpido. La investigación lleva tiempo y distrae de la programación misma.

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

2. Ping pong. Este enfoque implica que una persona escriba la prueba y otra realice la implementación. Teniendo en cuenta que con las pruebas unitarias todo es complicado y hay que escribir una prueba de integración que lleva mucho tiempo programar, toda la facilidad del ping-pong desaparece.

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

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

3. Estilo fuerte. Práctica difícil. La idea es que un participante se convierta en el navegador directivo y el segundo asuma el papel de conductor de ejecución. En este caso, el derecho a tomar decisiones corresponde exclusivamente al navegante. El conductor sólo imprime y puede influir en lo que sucede con una palabra. Los roles no cambian durante mucho tiempo.

Bueno para aprender, pero requiere fuertes habilidades sociales. Aquí es donde flaqueamos. La técnica fue difícil. Y ni siquiera se trata de infraestructura.

Conclusión: potencialmente se puede utilizar, no dejamos de intentarlo.

4. Mobbing, swarming y todos los estilos conocidos pero no enumerados No lo consideramos, porque No lo hemos probado y es imposible hablar de ello en el contexto de nuestro trabajo.

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

• Tenemos un ritmo de trabajo desigual, lo que resulta confuso.
• Nos topamos con habilidades blandas insuficientemente buenas. Y el tema no ayuda a superar estas deficiencias nuestras.
• Las pruebas largas y los problemas con las herramientas dificultan el desarrollo emparejado.

5. A pesar de ello, se lograron éxitos. Se nos ocurrió nuestro propio método "Convergencia - Divergencia". Describiré brevemente cómo funciona.

Tenemos socios permanentes por unos días (menos de una semana). Hacemos una tarea juntos. Nos sentamos juntos un rato: uno escribe, el segundo se sienta y observa al equipo de soporte. Luego nos dispersamos por un tiempo, cada uno hace algunas cosas independientes, luego nos reunimos nuevamente, nos sincronizamos muy rápidamente, hacemos algo juntos y luego nos dispersamos nuevamente.

Planificación y comunicación

El último bloque de prácticas mediante el cual se resuelven los problemas del SO es la organización del trabajo con las propias tareas. Esto también incluye el intercambio de experiencias fuera del trabajo en pareja. Veamos tres prácticas:

1. Objetivos a través del árbol de metas. Organizamos la gestión global del proyecto a través de un árbol que se extiende infinitamente hacia el futuro. Técnicamente, el seguimiento se realiza en Miro. Hay una tarea: es un objetivo intermedio. De ahí surgen objetivos más pequeños o grupos de tareas. Las tareas mismas provienen de ellos. Todas las tareas se crean y mantienen en este tablero.

Este esquema también proporciona retroalimentación, que ocurre una vez al día cuando sincronizamos en los rallyes. Tener un plan común delante de todos, pero estructurado y completamente abierto, permite que todos sean conscientes de lo que está pasando y hasta dónde hemos avanzado.

Ventajas de la visión visual de tareas:

• Causalidad. Cada tarea conduce a algún objetivo global. Las tareas se agrupan en objetivos más pequeños. El ámbito de la infraestructura en sí es bastante técnico. No siempre está claro de inmediato qué impacto específico tiene en el negocio, por ejemplo, escribir un runbook sobre la migración a otro nginx. Tener la carta objetivo cerca lo hace más claro.
  
  La causalidad es una propiedad importante de los problemas. Responde directamente a la pregunta: "¿Estoy haciendo lo correcto?"
• Paralelismo. Somos nueve y es simplemente físicamente imposible poner a todos en una misma tarea. Es posible que las tareas de un área tampoco siempre sean suficientes. Nos vemos obligados a paralelizar el trabajo entre pequeños grupos de trabajo. Al mismo tiempo, los grupos se sientan durante algún tiempo en su tarea y alguien más puede reforzarlos. A veces la gente se aleja de este grupo de trabajo. Alguien se va de vacaciones, alguien hace un informe para la conferencia DevOps, alguien escribe un artículo sobre Habr. Saber qué objetivos y tareas se pueden realizar en paralelo se vuelve muy importante.

2. Presentadores suplentes de las reuniones matutinas. En los stand-ups tenemos este problema: la gente realiza muchas tareas en paralelo. A veces, las tareas están poco conectadas y no se sabe quién hace 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 del problema. Por supuesto, normalmente hay alguien contigo, pero los consejos y sugerencias siempre son útiles.

Para mejorar esta situación, utilizamos la técnica “Cambiar el stand-up líder”. Ahora se rotan según una lista determinada, y esto tiene su efecto. Cuando es tu turno, te ves obligado a sumergirte y comprender lo que está sucediendo para poder llevar a cabo una buena reunión de Scrum.

3. Demostración interna. La ayuda para resolver un problema mediante la programación en pareja, la visualización en el árbol de problemas y la ayuda en las reuniones de scrum por la mañana son buenas, pero no ideales. Como pareja, sólo estáis limitados por vuestros conocimientos. El árbol de tareas ayuda a comprender globalmente quién está haciendo qué. Y el presentador y sus colegas en la reunión de la mañana no profundizarán en sus problemas. Ciertamente es posible que se les escape algo.

La solución se encontró en demostrarse mutuamente el trabajo realizado y luego discutirlo. Nos reunimos una vez a la semana durante una hora y mostramos detalles de las soluciones a las tareas que hemos realizado durante la semana pasada.

Durante la demostración, es necesario revelar los detalles de la tarea y asegurarse de demostrar su funcionamiento.

El informe se puede realizar utilizando una lista de verificación.1. Entre en contexto. ¿De dónde surgió la tarea? ¿Por qué era necesaria?

2. ¿Cómo se resolvió el problema antes? Por ejemplo, era necesario hacer muchos clics con el mouse o era imposible hacer nada.

3. Cómo lo mejoramos. Por ejemplo: "Mira, ahora está scriptosik, aquí está el archivo Léame".

4. Muestre cómo funciona. Es recomendable implementar directamente algún escenario de usuario. Quiero X, hago Y, veo Y (o Z). Por ejemplo, implemento NGINX, fumo la URL y obtengo 200 OK. Si la acción es larga, prepárala con antelación para poder mostrarla más tarde. Es recomendable no romperlo demasiado una hora antes de la demostración, si es frágil.

5. Explique con qué éxito se resolvió el problema, qué dificultades persisten, qué no se ha completado y qué mejoras son posibles en el futuro. Por ejemplo, ahora CLI, luego habrá automatización completa en CI.

Es aconsejable que cada orador lo limite a 5-10 minutos. Si su discurso es obviamente importante y va a durar más tiempo, coordine esto con antelación en el canal sre-takeover.

Después de la parte presencial siempre hay una discusión en el hilo. Aquí es donde aparece la retroalimentación que necesitamos sobre nuestras tareas.

Como resultado, se realiza una encuesta para determinar la utilidad de lo que está sucediendo. Se trata de retroalimentación sobre la esencia del discurso y la importancia de la tarea.

Conclusiones largas y lo que sigue.

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

Las pruebas, en su forma actual, proporcionan sólo una cobertura parcial del código. Muchas funciones de configuración no se prueban. Su influencia en el trabajo real al escribir código es baja. Sin embargo, las pruebas de integración tienen un efecto y le 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, vamos), el problema desaparece. Y no se necesitan muchas comprobaciones para el “pegamento”, una comprobación general de integración es suficiente.

Trabajar en parejas depende más de personas concretas. Está el factor tarea y nuestras habilidades blandas. A algunas personas les va muy bien, a otras les sale peor. Definitivamente hay beneficios de esto. Está claro que incluso si no se respetan suficientemente las reglas del trabajo en parejas, el hecho mismo de realizar tareas juntos tiene un efecto positivo en la calidad del resultado. Personalmente, encuentro que trabajar en parejas es más fácil y divertido.

Las formas más avanzadas de influir en el sistema operativo: la planificación y el trabajo con tareas producen efectos precisos: intercambio de conocimientos de alta calidad y mejora de la calidad del desarrollo.

Conclusiones breves en una línea.

• Los profesionales de RR.HH. trabajan en IaC, pero con menos eficiencia.
• Fortalecer lo que funciona.
• Crea tus propios mecanismos y prácticas compensatorias.

Fuente: habr.com