La base de esta lista son varios años de experiencia en el soporte de la automatización para el equipo upstream de tiempos de ejecución de contenedores (podman, buildah, skopeo, etc.). No tomaré todo el crédito, ya que muchos de estos consejos se basan en una amalgama de experiencia evolucionada y contribuciones individuales de una gran comunidad de usuarios y desarrolladores.
La mayoría de los elementos a continuación se pueden resumir en un solo principio:Eliminar o reducir la complejidad . Este concepto se basa en una aplicación compuesta de la Ley de Murphy :Cuantas más "cosas rompibles" tengas, más probable es que aparezca Murphy. Aquí hay ocho formas de evitar esos encuentros fortuitos.
[ A los lectores también les gustó: Presentamos el nuevo Ansible Automation Hub ]
1. Reducir las dependencias de la red
Reduzca las dependencias de red, especialmente en servicios de terceros sobre los que no tiene control. Además, los servicios de red de primera y segunda parte deben considerarse "evitar si es posible". En realidad, hay dos aspectos en esta recomendación:
- Desde todas las perspectivas, la creación de redes es un sistema muy complejo de componentes relacionados y relaciones en tiempo real. En términos generales, todos estos deben funcionar casi sin problemas de un extremo al otro, o podría tener un mal día.
- Nuevamente, en términos generales, las fallas de red suelen ser transitorias y dependen del tiempo (todos quieren que se solucionen rápidamente). Esto puede hacer que la depuración posterior sea increíblemente difícil. Incluso con un registro extenso, los efectos no observados pueden comenzar su mal día.
2. Reduzca las dependencias de software
Siempre que sea posible, reduzca las dependencias de software, especialmente en bibliotecas de terceros. Esto incluye tanto su tema principal de automatización como cualquier código de automatización compartido. A menos que bloquee la versión de cada uno de los componentes hacia arriba y hacia abajo de la pila, corre el riesgo de que se rompa debido a un comportamiento inesperado o a cambios en la API en alguna parte. La situación es un poco mejor cuando controlas el código incluido pero aún presenta un riesgo.
Nota :Reconozco que este consejo puede ser bastante controvertido y ciertamente no tiene sentido en muchas situaciones. Considérelo como un recordatorio de "piense dos veces", especialmente cuando desee una biblioteca para incorporar una función simple.
3. Organizar trabajos de automatización
Organice los trabajos de automatización en el orden descendente de la consecuencia de la falla. En otras palabras, intente detectar los elementos con el mayor impacto negativo lo antes posible. La idea aquí es ahorrar recursos (incluido el tiempo) para "Whoopsies" de alto impacto y bajo costo de detección. Algunos ejemplos de pruebas de integración continua (CI) de VCS:
- ¿Se puede acceder a los servicios de red de terceros? Por ejemplo, ¿se les puede hacer ping y validar sus certificados SSL?
- ¿Su proveedor o código incluido realmente coincide con la lista de requisitos documentada y configurada?
- ¿Alguien dejó accidentalmente un comentario "FIXME" en el código recién confirmado?
- ¿Todos los nuevos compromisos están firmados?
- ¿Los cambios coinciden con el contexto de ejecución, por ejemplo, un cambio no documentado durante las pruebas de lanzamiento o documentación faltante/actualizaciones de prueba con un cambio de código?
Con el tiempo, el efecto de este flujo de trabajo es que las verificaciones importantes recibirán la mayor atención y el mantenimiento más confiable (ya que las fallas tienden a retrasar todo el tren). A su vez, los desarrolladores también podrán circular más rápido. Por ejemplo, no esperarán mucho tiempo solo para descubrir que escribieron mal su propio nombre.
4. Mantenga los trabajos cortos
Mantenga los trabajos lo más cortos posible y en "trozos" fácilmente repetibles. Esto dependerá en gran medida del software de orquestación, pero la mayoría de las aplicaciones permiten varias etapas de ejecución. Usando otro ejemplo de prueba de CI, si tiene que ejecutar pruebas unitarias, de integración y de sistema (en ese orden), evite ejecutarlas todas juntas, una tras otra, en un solo script. De esta forma, si el paso de integración falla, los usuarios no están obligados a volver a ejecutar las pruebas unitarias. Esto mejora la confiabilidad al no volver a ejecutar operaciones redundantes, invitando innecesariamente a Murphy a volver al tren de engranajes de automatización.
5. Evite operaciones no esenciales en tiempo de ejecución
Evite operaciones no esenciales (como instalación o configuración) en tiempo de ejecución. En su lugar, prepare sus entornos de ejecución con todos los bits necesarios con anticipación. Esto no solo hace que las cosas funcionen de manera más eficiente, sino que también ayuda a seguir otros consejos de este artículo. También permite la observación y prueba del entorno preconstruido en el momento de la construcción. Si sus entornos se comparten entre trabajos con algunos requisitos diferentes, considere almacenar en caché esos componentes/paquetes dentro de la imagen. La instalación en tiempo de ejecución desde un caché local es mucho más segura y confiable que acceder a un repositorio remoto a través de la red.
6. Utilice las herramientas adecuadas
Utilice las herramientas más básicas disponibles para la tarea en cuestión. Por ejemplo, si necesita verificar indicadores binarios después de aplicar una máscara de bits, no intente hacerlo en un script bash. De manera similar, si su programa C++ simplemente ejecuta una serie de comandos, use bash en su lugar. Esto mejora la confiabilidad al no exponer las operaciones a efectos secundarios no relacionados con el propósito central del trabajo.
7. Rastrear fallas
Realice un seguimiento de los fallos en función de la frecuencia de su firma. La mayoría de las veces (pero no todas), las fallas de automatización darán como resultado que se registre alguna indicación en alguna parte. Identifíquelos y clasifíquelos (por ejemplo, por nombre de solicitud) para que pueda mantener un registro centralizado de ocurrencia. Podría decirse que esto requiere bastante trabajo para lograrlo, lo que posiblemente requiera que aprenda e interactúe con múltiples servicios y API. Sin embargo, con los resultados ordenados por frecuencia de firma, detectará rápidamente qué problemas afectan a la mayor cantidad de personas. Esos elementos deben recibir la mayor atención y tendrán el mayor impacto en la confiabilidad de la automatización.
8. Usa los comentarios de manera efectiva
Comenta por qué no cómo . Suponga que cualquier lector de su código puede determinar la forma en que funciona. No pueden determinar lo que usted (el autor) estaba pensando cuando escribió el código. La automatización involucra muchas partes móviles. Algunas de las relaciones pueden no ser obvias para un lector no iniciado. Los comentarios son especialmente útiles cuando informan sobre las relaciones de los componentes.
Por ejemplo, considere el siguiente comentario:
# Default variable value comes from CI unless executed manually.
# Detect this (`$CI == false`) to ensure the user did not leave
# the value blank. Debería imaginar fácilmente el código que esto adorna:alguna forma de definición o validación de variables. Además, insinuaba una fuente de información adicional, "CI" (lo que sea que eso signifique en el contexto del guión).
Comentarios útiles como este no necesitan adornar cada línea de su guión; apuntarlos. Concéntrese en los elementos afectados por archivos o fuerzas externas (incluidas las llamaradas solares). Estos detalles hacen que la automatización sea más confiable al garantizar que la "salsa secreta" se transmita continuamente a cualquier persona encargada de futuras mejoras o mantenimiento.
[ Una guía gratuita de Red Hat:5 pasos para automatizar su negocio. ]
Resumir
En la mayoría de las situaciones, será imposible seguir todos estos consejos. Están destinados a servir como pautas para el compromiso cuando las implementaciones alternativas son razonables. De lo contrario, para servir mejor a las partes interesadas, a veces será necesario violar algunos de estos principios. Aún así, otros (como escribir buenos comentarios) tenderán a tener un efecto sutil pero constante con el tiempo. Seré el primero en admitir que hacer las cosas con sencillez suele ser mucho más difícil que poner cinta adhesiva. Sin embargo, con el tiempo, la mayoría de las cintas adhesivas se secan y forman costras, lo que requiere que vuelvas a solucionar el problema. Hazte un favor a ti mismo en el futuro, dedica tiempo a refactorizar hacia la simplicidad desde el principio.