Caos controlado: lecciones de ingeniería del caos en pagos sobre ECS

La ingeniería del caos lleva años dejando de ser una rareza: Netflix la popularizó y AWS la integró en Fault Injection Simulator. Pero los manuales escritos para aplicaciones web sin estado se rompen cuando se aplican a sistemas de pago desplegados en Amazon ECS. Un artículo de InfoQ recoge lo que aprenden los equipos que lo intentan y qué hacer desde el principio.

Los sistemas de pago violan tres supuestos del manual estándar de caos. Primero, no se puede detener un experimento limpiamente: una transacción en vuelo puede quedar en estados ambiguos (autorizada sin capturar, capturada sin liquidar...) que exigen intervención manual o generan excepciones de cumplimiento. Segundo, el radio de explosión no se puede definir de antemano: un solo task de ECS que procesa liquidación por lotes puede ser la ruta crítica de miles de transacciones aunque represente una fracción mínima del servicio. Tercero, en entornos PCI DSS y SOC 2, cualquier degradación intencionada de producción necesita aprobación formal; ejecutar experimentos sin cadena de aprobación crea hallazgos de auditoría.

Fallos específicos de ECS que las herramientas genéricas no cubren

ECS introduce su propia clase de fallo. Cuando sustituye un task (por despliegue, fallo de health check o interrupción de Spot), arranca el nuevo antes de drenar el viejo según la configuración. Si el servicio se registra en un balanceador o registro durante el arranque y el período de calentamiento no se tiene en cuenta, el tráfico llega a un task que aún no ha cargado su configuración ni establecido el pool de conexiones. El health check responde 200, así que ECS no lo considera degradado.

La configuración que controla esto vive en las definiciones de servicio y task. Por ejemplo, deployment_minimum_healthy_percent = 100 evita caer por debajo del número deseado durante un despliegue rodante; health_check_grace_period_seconds = 120 da tiempo a cargar configuración y calentar conexiones; stopTimeout = 120 permite completar transacciones en vuelo durante el drenaje. No son valores por defecto; hay que ajustarlos y verificar su comportamiento con experimentos.

Otro descubrimiento típico: los valores configurados divergen de la realidad bajo fallo. Un TTL de DNS de 60 segundos produjo una ventana de conmutación por error de 93 segundos por cachés intermedias, y una política de reintentos bien afinada multiplicó por 2,4 la carga en la base de datos. Hay que medir ambos, no asumir que la configuración se cumple.

Tratar los experimentos como cambios formales

La recomendación práctica es tratar cada experimento de caos como una solicitud de cambio formal. Eso obliga a documentar el estado estable, las condiciones de rollback y produce un rastro de auditoría que satisface PCI DSS y SOC 2. También sugieren empezar con servicios que no estén en la ruta de transacción y subir de nivel solo cuando se tenga definido el estado estable y la automatización de reversión.

El artículo termina con una moraleja implícita: el caos no es un lujo, es una herramienta de descubrimiento. Un incidente real de cuatro horas en una pasarela de pagos llevó a un programa serio de ingeniería del caos; la siguiente vez, el fallo se descubre en un experimento, no en producción.