Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 5 de 5
Pruebas operativas
La preparación productiva se demuestra con replay, backfill, fallo de calidad, métricas, coste y un runbook ejecutado, no solo con un update exitoso.
30 min aprox.
05Decisión de diseñoPruebas operativas
La preparación productiva se demuestra con replay, backfill, fallo de calidad, métricas, coste y un runbook ejecutado, no solo con un update exitoso.
+
Pruebas operativas
La preparación productiva se demuestra con replay, backfill, fallo de calidad, métricas, coste y un runbook ejecutado, no solo con un update exitoso.
El equipo prueba una segunda ejecución sin datos, un update CDC fuera de orden, una fila en cuarentena y una caída recuperable. Un backfill de una fecha usa el mismo pipeline/Job y se reconcilia. El event log debe explicar qué flows procesaron filas y qué expectations fallaron.
El runbook identifica owner, SLO, paneles, decisiones de retry, repair o full refresh y rutas de rollback. La entrega incluye consultas de evidencia y límites conocidos. Una demo feliz sin incidente ni recuperación no valida producción.
acceptance:
- second_run_adds_zero_duplicates
- out_of_order_cdc_keeps_highest_sequence
- invalid_order_is_quarantined_with_reason
- expectation_metrics_visible_in_event_log
- one_day_backfill_reconciles_to_manifest
- repair_run_preserves_successful_outputs
- rto_under_60_minutes
- service_principal_has_least_privilegeCada elemento enlaza a una consulta, run o captura reproducible, no a una marca manual sin evidencia.
¿Qué prueba distingue idempotencia de una ejecución simplemente exitosa?
Profundiza
Preparación productiva se demuestra con evidencia sobre corrección, recuperación, capacidad, seguridad y operación. Un run exitoso con datos felices solo prueba la ruta más sencilla. La checklist incluye replay determinista, backfill concurrente, schema evolution compatible e incompatible, expectation que falla, sink lento, checkpoint restore, límites de coste y permisos mínimos. Se mide SLA al volumen pico y RTO con un game day. El event log y system tables alimentan dashboards, alertas y atribución de coste. Un runbook describe síntomas, consultas, decisiones seguras, rollback y owners, y otra persona debe poder ejecutarlo sin conocimiento tribal. La promoción usa artefacto versionado, configuración revisada y criterios de aceptación; el rollback conserva tablas y checkpoints anteriores. La preparación también exige reconocer límites: ningún curso garantiza aprobar ni reemplaza práctica, pero el producto debe cubrir mecanismos y decisiones examinables con profundidad autosuficiente.
Condición medible que una versión debe satisfacer en corrección, rendimiento, recuperación, seguridad y coste antes de promoverse.
Evita decisiones go-live basadas únicamente en un run verde o una revisión informal del código.Experimento controlado que introduce fallos representativos y mide alertas, diagnóstico, recuperación, reconciliación y cumplimiento de RTO/RPO.
Transforma supuestos de resiliencia en evidencia y descubre dependencias de conocimiento o permisos antes de un incidente.Procedimiento versionado con síntomas, consultas, decisiones, comandos seguros, criterios de escalado, rollback y responsables de la recuperación.
Reduce tiempo de diagnóstico y permite que la operación no dependa exclusivamente del autor original.Resumen
Puntos clave
- Idempotencia se prueba ejecutando dos veces el mismo input.
- Recuperación se prueba con fallo y checkpoint/estado realista.
- Aceptación incluye calidad, observabilidad, seguridad y coste además del resultado funcional.
Evita
- Aceptar el proyecto porque las tablas existen aunque no haya pruebas de reintento o recuperación.
- Realizar full refresh por defecto sin estimar coste, disponibilidad ni efecto en consumers.