Un primer game day: un experimento de caos con hipótesis, radio de impacto y regla de aborto

Objetivo

Averiguar, en un día elegido y con todo el equipo observando, qué ocurre cuando falla un componente, en lugar de descubrirlo de madrugada; y ensayar al mismo tiempo la respuesta humana (alertas, runbooks, roles).

Requisitos previos

Monitorización que muestre la señal del estado estable casi en tiempo real; una forma probada de deshacer el fallo; una entrada en el calendario de cambios y, si interviene producción, una nota en la página de estado; un facilitador que no sea uno de los que responden a la incidencia.

Pasos

1. Elige un fallo que sea plausible y reversible: detener una réplica, bloquear el puerto de una dependencia, llenar una cola, expirar una cache, revocar una credencial en staging. No "tirar la base de datos".
2. Define el estado estable como, en palabras de los Principles of Chaos Engineering, una salida medible del sistema que indica comportamiento normal (tasa de éxito de peticiones, compras completadas por minuto), y escribe la hipótesis: "esta señal se mantiene dentro de su banda normal mientras la réplica 2 está detenida".
3. Escribe por separado el comportamiento esperado del sistema y el de las personas: qué alerta salta y en cuánto tiempo, qué runbook se usa, a quién se avisa.
4. Fija el radio de impacto (una réplica, una región, una fracción del tráfico) y la condición de aborto (la señal sale de su banda durante más de un número de minutos establecido, o aparece cualquier error visible para el cliente), con el comando para deshacer el fallo preparado en una terminal.
5. Anuncia el inicio, inyecta el fallo y arranca un temporizador. El facilitador anota las marcas de tiempo: fallo inyectado, primera alerta, primera acción humana, mitigación, recuperación. Quienes responden actúan como ante una alerta real; el facilitador no contesta ninguna pregunta que pueda resolver la monitorización.
6. Deshaz el fallo al final previsto o al abortar; verifica el estado estable; confirma que no quedan efectos residuales (colas vaciadas, conexiones restablecidas, alertas cerradas).
7. Haz una revisión dentro de la hora siguiente: ¿se refutó la hipótesis? ¿Qué alerta no saltó, qué paso del runbook era incorrecto, qué dashboard faltaba? Redacta acciones con responsables, como en un postmortem.
8. Si todavía no es aceptable una inyección real, ejecuta antes el mismo escenario como ejercicio de mesa (tabletop). El libro de SRE describe la "Wheel of Misfortune": un director de juego presenta un escenario y la pareja de guardia explica en voz alta lo que haría, mientras el grupo aprende de cada ronda.

Resultado esperado

Un registro escrito del efecto real de un fallo, una lista breve de las carencias detectadas y un equipo que ha practicado cómo declarar y gestionar un incidente sin sufrir una caída real.

Límites y base de verificación

Un entorno de staging demuestra menos que producción, y los Principles abogan por producción porque el comportamiento difiere según el entorno y el tráfico; aun así, una primera ejecución en staging es un comienzo más seguro. El protocolo es una síntesis de las fuentes citadas; no se afirma ningún hallazgo obtenido al ejecutarlo.