Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lecció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.
- Duración
- 30 min aprox.
- Objetivo
- Un game day verifica con fallos controlados que checkpoints, capacidad, alertas y runbook cumplen el RTO sin duplicar ni perder datos.
- Siguiente paso
- Continuar con el laboratorio
Ver detalles del módulo
Proyecto de streaming con SLA
Entrega un flujo operable que soporte datos tardíos, recuperación e incidentes reproducibles.
- Cumplir SLA de frescura y completitud
- Recuperar sin duplicados
- Crear métricas y runbook
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.
Modelo mental
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.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.
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.
Recuerdo activo