La ingeniería del caos no es «destruir», sino «verificar»
Cuando Netflix publicó Chaos Monkey en la década de 2010, la ingeniería del caos fue percibida como una práctica radical de «destruir el entorno de producción de forma aleatoria». Su impacto cultural fue grande, pero también generó malentendidos: arrojar bombas en producción requería una madurez organizacional que estaba muy por encima de la mayoría de las empresas.
En 2026 el punto de llegada es claro. La ingeniería del caos no es «tecnología para destruir», sino «disciplina para verificar la resiliencia»; su esencia es «comprobar científicamente si un diseño preparado para fallas funciona realmente como se esperaba cuando ocurren». Se plantea una hipótesis, se prueba a pequeña escala, se observa y se mejora. Todo ese proceso de hacer girar este PDCA es lo que constituye el chaos engineering. En el contexto japonés, resulta útil presentarlo como una extensión del TPM (mantenimiento productivo total) o del FMEA (análisis de modos y efectos de falla), que son ampliamente conocidos en las empresas.
Selección de herramientas: Gremlin / LitmusChaos / Chaos Mesh
En 2026 las herramientas principales se dividen en tres. Gremlin es el líder en SaaS comercial; su principal argumento de venta es el control del «blast radius» (radio de impacto) y las condiciones de «halt» que permiten introducirlo de forma segura incluso en organizaciones sin un equipo SRE. Cuenta con decenas de ataques estándar como latencia de red, presión de CPU, agotamiento de I/O de disco y falla de zona, y los experimentos se pueden iniciar desde la UI web en pocos clics. Es especialmente fuerte en sectores como finanzas y telecomunicaciones, donde el programa de ingeniería del caos es necesario como requisito regulatorio.
LitmusChaos es un proyecto CNCF Graduated y un OSS nativo de Kubernetes. Define los Chaos Experiments como CRDs y permite importar experimentos de la comunidad desde ChaosHub. La integración con GitOps es sobresaliente: combinado con Argo CD, permite construir un pipeline completo de «declarar el experimento en Git, ejecutarlo con Argo Workflows, verificar métricas con Prometheus y hacer rollback automático en caso de falla». Es adecuado para organizaciones con equipos SRE bien estructurados.
Chaos Mesh es un proyecto CNCF Incubating de origen PingCAP, especializado en inyección de fallas de granularidad fina sobre Kubernetes. Cuenta con CRDs como PodChaos, NetworkChaos, IOChaos, TimeChaos y DNSChaos, y destaca especialmente por reproducir «fallas de bajo nivel difíciles de simular con otras herramientas», como desvíos de NTP o envenenamiento de DNS. Su UX en Chaos Dashboard también es superior y tiene una curva de aprendizaje más baja que LitmusChaos.
Implementación en Kubernetes: el modelo de tres niveles de experimentos
En entornos Kubernetes, el estándar es operar los experimentos en tres niveles. El primer nivel es el «nivel de Pod»: se usa PodChaos para matar un Pod de un Deployment específico y verificar que el HPA y los mecanismos de retry y circuit breaker del service mesh funcionan como se espera. El impacto es mínimo y puede ejecutarse de forma automática a diario.
El segundo nivel es el «nivel de Node»: se usa NodeChaos para drenar un nodo dentro de una AZ y verificar que el Pod Disruption Budget y la redistribución de pods funcionan. La cadencia recomendada es semanal. El tercer nivel es el «nivel de región o AZ»: se usa NetworkChaos para cortar la comunicación entre zonas y verificar el failover de una configuración multi-AZ. Esta es la escala de un game day trimestral.
En los equipos de 2026, el primer y segundo nivel se automatizan completamente (integrados en el pipeline de CI), y solo el tercer nivel se mantiene como un game day con participación humana. La parte automatizada se llama desde GitHub Actions o Tekton hacia LitmusChaos, y siempre debe incluirse una condición de halt vinculada al dashboard de SLO para «detener automáticamente el experimento si se detecta una violación del SLO».
Verificación del failover multi-región
Para los servicios con configuración multi-región, el «game day de cambio de región» una o dos veces al año se ha convertido en una práctica prácticamente obligatoria. El procedimiento tiene tres etapas: primero, se transfiere gradualmente el tráfico DNS de la región actual a la región secundaria (10 % → 50 % → 100 %); en cada etapa se verifica que los SLI no se degraden y, si lo hacen, se hace rollback. Una vez alcanzado el 100 %, se corta intencionalmente la red de la región actual (usando `partition` de NetworkChaos) y se observa durante varias horas si la región secundaria resiste por sí sola.
Los problemas que aparecen con más frecuencia en estos game days son: (1) capacidad insuficiente en la región secundaria (el HPA tiene un límite demasiado bajo porque habitualmente maneja poco tráfico), (2) picos en la latencia de réplicas de base de datos (la réplica se atrasa bajo la presión de escrituras concentradas), y (3) restricciones de la API de terceros por región (no se puede llamar desde cierta región, o los límites de tasa son más estrictos). Son exactamente el tipo de problemas difíciles de anticipar de antemano; si no se verifican con un game day, se manifiestan por primera vez durante un desastre real.
El desafío cultural en las empresas japonesas: «corte planificado» vs. «caos en producción»
La barrera más grave para introducir la ingeniería del caos no es técnica, sino cultural. Las empresas japonesas tienen la cultura del «corte planificado del servicio» (notificación previa con interrupción breve), pero hay una fuerte resistencia a «inyectar fallas intencionalmente en un sistema que está funcionando en producción». La reacción directiva de «¿cómo se te ocurre dañar la producción?» no es inusual.
Hay tres tácticas prácticas para superar esta barrera. La primera es empezar por el caos «en entornos no productivos». Se inicia ejecutando PodChaos a diario en el entorno de staging para crear la cultura de verificar el SLO antes de cada release. Durante seis meses a un año se acumulan resultados con los que explicar «no lo estamos haciendo en producción».
La segunda es aprovechar las «ventanas de mantenimiento planificado» existentes para la introducción en producción. Se ejecuta un caos a pequeña escala en la ventana de mantenimiento mensual y se encuadra como «parte del mantenimiento planificado». Esto elimina la necesidad de crear un nuevo proceso de aprobación a nivel directivo.
La tercera es hacer branding del game day como «entrenamiento». Si se denomina «simulacro de respuesta ante incidentes» o «ejercicio de BCP», los departamentos de gestión de calidad y auditoría interna lo valoran positivamente. De hecho, el game day puede usarse como evidencia para cumplir los requisitos de ejercicio de ISO 22301 (continuidad del negocio) o de los estándares de seguridad de FISC.
Madurez y próximos pasos
El Chaos Engineering Maturity Model (propuesto por Casey Rosenthal, revisado en 2026) define cinco niveles de madurez: desde el Nivel 1 (experimentos ad hoc) hasta el Nivel 5 (ejecución continua y completamente automatizada en producción). La mayoría de las empresas japonesas se encuentran en transición del Nivel 2 (experimentos periódicos en staging) al Nivel 3 (game day en producción). Para pasar al Nivel 4 (experimentos automatizados en producción) es un prerequisito tener el trío completo de SLO, error budget y observabilidad, y que la multi-window multi-burn-rate mencionada en artículos anteriores esté funcionando.
En KGA IT diseñamos «hojas de ruta de introducción de ingeniería del caos» de 6 a 18 meses como parte del diagnóstico de madurez SRE de nuestros clientes. La secuencia para superar las barreras culturales es más importante que la selección tecnológica; la elección entre Gremlin y LitmusChaos es, en realidad, un debate para la segunda mitad del proceso.