Automatización de pruebas de conmutación por error en ingeniería del caos dentro de las pipelines CI/CD de AWS

Un tutorial técnico detallado, publicado el 2 de noviembre de 2026, demuestra cómo incorporar pruebas automatizadas de fiabilidad directamente en los flujos de trabajo de integración y despliegue continuos. La guía, escrita por Gbenga Ogbonyenitan para DEV Community, acompaña a los ingenieros paso a paso en el uso de AWS Fault Injection Service (FIS) para detener intencionadamente tareas de contenedores y verificar que el sistema se recupera dentro de límites de tiempo aceptables.

Qué ocurrió

El artículo ofrece una implementación paso a paso de un patrón de ingeniería del caos donde una pipeline despliega un servicio, rompe deliberadamente uno de sus componentes activos y luego valida que la infraestructura se auto-repara. La configuración utiliza Amazon ECS (Elastic Container Service) con Fargate, un Application Load Balancer y AWS CodePipeline. La innovación central es añadir una etapa "FailoverTest" que se ejecuta después del despliegue, asegurando que cada lanzamiento venga acompañado de una prueba de resiliencia.

El proceso consta de dos fases principales: construir la infraestructura subyacente del servicio y configurar el mecanismo de inyección de fallos. Primero, el ingeniero configura grupos de seguridad, grupos de destino y el balanceador de carga para gestionar el tráfico. Luego, configura FIS para dirigirse a tareas específicas de ECS. El tutorial enfatiza que no se trata solo de romper cosas, sino de medir el tiempo de recuperación contra un umbral predefinido, como 300 segundos. Si el servicio no vuelve a un estado saludable dentro de esa ventana, la pipeline falla, evitando que configuraciones potencialmente inestables sean consideradas exitosas.

El autor señala que, aunque la demo utiliza un servidor web nginx simple, el patrón está diseñado para aplicaciones del mundo real. Al automatizar esta prueba, los equipos pasan de asumir que su diseño de alta disponibilidad funciona a demostrarlo en cada lanzamiento individual. La guía incluye tanto un enfoque manual basado en consola para fines de aprendizaje como un enfoque basado en CloudFormation para infraestructura lista para producción mediante código.

Detalles clave

• La pipeline consta de tres etapas: Source, Deploy y FailoverTest, siendo la última la que ejecuta el experimento de caos.
• AWS Fault Injection Service está configurado para detener exactamente una tarea en un servicio ECS de dos tareas, garantizando disponibilidad parcial durante la prueba.
• Un script personalizado que se ejecuta en AWS CodeBuild verifica las condiciones previas, inicia el experimento de FIS, espera a que finalice y valida las métricas de recuperación.
• La validación de recuperación requiere que tanto el recuento de tareas en ejecución de ECS como el recuento de objetivos saludables del balanceador de carga coincidan con el estado deseado.
• El experimento utiliza una alarma de CloudWatch como condición de parada para monitorear hosts saludables, aunque el control de seguridad principal consiste en limitar el fallo a una sola tarea.
• Se proporcionan scripts de limpieza para manejar recursos no gestionados por stacks de CloudFormation, como grupos de logs y revisiones de definiciones de tareas.

Contexto

La ingeniería del caos es la disciplina de experimentar sobre un sistema para generar confianza en su capacidad para soportar condiciones turbulentas en producción. Tradicionalmente, esto podría implicar días de juego manuales o entornos de prueba separados. Integrarla en CI/CD acerca estas pruebas a los cambios de código, detectando regresiones en la lógica de resiliencia tempranamente. AWS Fault Injection Service es un servicio gestionado que ayuda a realizar estos experimentos de forma segura definiendo alcances, acciones y condiciones de parada.

En este contexto, la "conmutación por error" (failover) se refiere al reemplazo automático de una tarea de contenedor fallida por parte del planificador de ECS. Cuando una tarea se detiene, el servicio detecta la discrepancia entre el recuento deseado y el recuento en ejecución, lanza una nueva tarea y la registra con el balanceador de carga. La prueba verifica que todo este ciclo se complete sin intervención humana y dentro de un plazo que cumpla con los objetivos de nivel de servicio.

Por qué importa

Para equipos que gestionan software autoalojado o plataformas internas, la fiabilidad suele asumirse más que probarse. Los documentos de diseño pueden afirmar que un servicio es altamente disponible, pero la deriva de configuración, errores de permisos o políticas de red pueden romper silenciosamente los mecanismos de conmutación por error. Al automatizar esta prueba, los ingenieros convierten afirmaciones abstractas de diseño en comprobaciones concretas de aprobado/fallo. Esto reduce el riesgo de descubrir fallos de recuperación durante cortes reales, cuando las apuestas son más altas.

Además, este enfoque destaca la importancia de los objetivos de tiempo de recuperación. No basta con que un servicio vuelva eventualmente; debe hacerlo lo suficientemente rápido para cumplir con las expectativas del usuario. La pipeline impone un tiempo de espera estricto, forzando a los equipos a optimizar sus intervalos de comprobación de salud, tiempos de inicio de contenedores y retrasos de desregistro del balanceador de carga. Esto transforma la ingeniería de fiabilidad de una actividad reactiva post-mortem a un requisito proactivo de desarrollo.

Sin embargo, implementar esto requiere una gestión cuidadosa de permisos. El tutorial detalla varias trampas comunes, como permisos IAM faltantes para crear roles vinculados a servicios o ARNs incorrectos de grupos de destino. Estos detalles subrayan que la ingeniería del caos introduce nuevas complejidades operativas que deben gestionarse junto con las tareas estándar de despliegue.

Qué puedes hacer

• Revisa tus pipelines CI/CD actuales para identificar dónde se podría añadir pruebas de resiliencia como una etapa posterior al despliegue.
• Comienza con un entorno no productivo para probar la integración de FIS, asegurándote de entender los modos de fallo antes de tocar tráfico en vivo.
• Define objetivos claros de tiempo de recuperación para tus servicios críticos y úsalos como umbral de tiempo de espera en tus pruebas automatizadas.
• Audita tus roles IAM para asegurar que tus agentes de compilación tengan los permisos mínimos necesarios para iniciar experimentos de FIS y consultar el estado de ECS.
• Implementa comprobaciones previas en tus scripts de prueba para verificar que el sistema esté saludable antes de inyectar fallos, evitando falsos positivos derivados de problemas existentes.
• Documenta el comportamiento esperado de tus servicios durante cortes parciales y usa estas pruebas para validar continuamente esas expectativas.