Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 5 de 5
Game day y recuperación
Un game day verifica con fallos controlados que checkpoints, capacidad, alertas y runbook cumplen el RTO sin duplicar ni perder datos.
30 min aprox.
05Decisión de diseñoGame day y recuperación
Un game day verifica con fallos controlados que checkpoints, capacidad, alertas y runbook cumplen el RTO sin duplicar ni perder datos.
+
Game day y recuperación
Un game day verifica con fallos controlados que checkpoints, capacidad, alertas y runbook cumplen el RTO sin duplicar ni perder datos.
La prueba puede detener compute durante diez minutos, introducir un evento tardío y reiniciar desde el mismo checkpoint. Se mide tiempo hasta recuperar frescura, lag máximo, duplicados y completitud. Otra prueba despliega un cambio stateful incompatible en un entorno aislado para practicar rollback o rebuild.
El runbook se escribe como decisiones observables: si el checkpoint está íntegro y el código es compatible, reanudar; si faltan offsets, escalar pérdida y reconciliar; si el sink tiene efectos externos, verificar idempotencia. El resultado del ejercicio genera acciones con responsable y fecha.
experiment: stop-streaming-compute
preconditions:
- bronze_backlog_is_zero
- baseline_freshness_p95_lt_300s
fault:
duration_minutes: 10
success:
- no_duplicate_event_ids
- completeness_percent_gte_99.5
- freshness_recovered_within_30m
rollback:
- resume_original_job
- preserve_checkpoint
owner: data-platform-oncallNo ejecutes un experimento de resiliencia en producción sin límites, observabilidad y autorización explícitos.
¿Qué cuatro resultados mínimos debe registrar un game day de streaming?
Profundiza
Un game day convierte supuestos de resiliencia en evidencia mediante fallos controlados. No busca demostrar que nada falla; comprueba que detección, recuperación, idempotencia y comunicación funcionan dentro de RTO/RPO. El experimento define hipótesis, alcance, guardas de seguridad, datos sintéticos o reversibles, responsables y criterio de aborto. Se eligen fallos representativos: matar el driver durante un commit, ralentizar un sink, detener una partición, enviar poison pills o llenar backlog. Antes se registra el estado esperado y después se reconcilia cada evento. Reiniciar con éxito no basta: hay que demostrar que no faltan ni sobran claves, que el state store recuperó, que alertas llegaron al owner y que el runbook no exigió conocimiento tribal. Los resultados alimentan capacidad, automatización y documentación; un fallo del ejercicio es aprendizaje antes de una incidencia real.
Afirmación medible sobre cómo responderá el sistema a un fallo concreto bajo condiciones definidas.
Permite declarar éxito o fracaso con evidencia en vez de aceptar que el Job volvió a verde.Límite técnico u operativo que contiene el impacto del experimento y activa aborto o rollback.
Hace posible probar escenarios realistas sin convertir el aprendizaje en un incidente incontrolado.Comparación de identidades, conteos, importes y efectos antes y después de recuperar.
Demuestra RPO e idempotencia, propiedades que una captura de estado RUNNING no puede probar.Resumen
Puntos clave
- Define estado inicial y criterios de éxito antes de inyectar el fallo.
- Mide RTO y calidad final, no solo que el proceso vuelve a estado RUNNING.
- El game day debe ser reversible, aislado y aprobado por el owner del servicio.
Evita
- Declarar éxito cuando el query reinicia aunque el backlog y los duplicados sigan creciendo.
- Probar borrado de checkpoint productivo sin snapshot, aislamiento ni procedimiento de rollback.