Proyecto FinOps

Un incidente de datos combina impacto técnico y de negocio: atraso, datos incorrectos, duplicados, indisponibilidad o sobrecoste. Declara severidad y alcance, asigna incident commander y comunicación, congela cambios no esenciales y establece una línea de tiempo en UTC con IDs de job, run, statement y commit. La primera meta es contener impacto sin destruir evidencia.

Diferencia mitigación de causa raíz. Reprocesar una partición puede restaurar el SLA, pero no explica por qué falló; ampliar compute puede ganar tiempo, pero aumenta coste y oculta skew. Define criterios cuantificados de recuperación —freshness, completitud, duración, coste— y un rollback antes de ejecutar cualquier cambio.

incident: INC-2041
severity: SEV-2
started_at_utc: 2026-07-21T01:42:00Z
impact: "gold.sales_daily fuera de SLA; dashboards sin actualizar"
commander: data-platform-oncall
data_safety: "no ejecutar VACUUM ni borrar checkpoints"
recovery_criteria:
  freshness_minutes: 30
  duplicate_order_ids: 0
  p95_runtime_minutes: 24
rollback: "restaurar bundle release-2026.07.20"

Una regresión puede provenir de cambio de código, crecimiento o distribución de datos, estadísticas/layout, compute o concurrencia. Compara el último run sano con el primero degradado usando la misma ventana: plan, top operator, bytes leídos, shuffle, spill, workers y cola. Un diff de bundle o historial de tabla acota cambios sin especular.

Formula hipótesis falsables: 'la clave nula genera skew' se prueba con distribución y tareas; 'el warehouse se satura' con cola y concurrencia; 'faltan estadísticas' con pruning y plan. Prioriza la prueba barata y reversible que más reduce incertidumbre. No redimensiones hasta saber si la etapa puede utilizar capacidad adicional.

SELECT
  DATE_TRUNC('day', start_time) AS day,
  statement_type,
  percentile(total_duration_ms, 0.95) AS p95_duration_ms,
  SUM(read_bytes) AS read_bytes,
  COUNT(*) AS executions
FROM system.query.history
WHERE start_time >= current_timestamp() - INTERVAL 14 DAYS
  AND statement_type IN ('SELECT', 'MERGE')
GROUP BY day, statement_type
ORDER BY day DESC;

Antes de reintentar, determina el efecto parcial: qué commits Delta existen, qué tarea falló y si el sink externo recibió operaciones. Un `MERGE` con clave estable puede repetirse; un append sin deduplicación puede duplicar. En streaming, borrar un checkpoint cambia el progreso y el estado y rara vez es una reparación segura. Usa repair run para tareas fallidas cuando sus dependencias y outputs sean reutilizables.

Un backfill debe declarar rango, versión de código, tabla destino, estrategia de overwrite/merge y validaciones. Aísla el proceso de la ingesta viva para evitar carreras y conserva una tabla de control de lotes. La recuperación termina cuando reconcilias conteos, claves únicas, freshness y consumidores, no sólo cuando el run aparece verde.

MERGE INTO prod.silver.orders AS target
USING staging.backfill_orders AS source
ON target.order_id = source.order_id
WHEN MATCHED AND source.updated_at > target.updated_at THEN
  UPDATE SET *
WHEN NOT MATCHED THEN
  INSERT *;

SELECT order_id, COUNT(*) AS copies
FROM prod.silver.orders
GROUP BY order_id
HAVING COUNT(*) > 1;

Durante un incidente puede ser racional aumentar temporalmente capacidad para restaurar un SLA, pero registra quién lo aprobó, duración máxima y rollback automático. `system.billing.usage` permite atribuir el run y comparar coste por ejecución. Una reparación que reduce runtime pero duplica coste no es mejora salvo que el impacto evitado justifique esa compensación.

Después de estabilizar, elimina recursos temporales, restaura límites de policies y calcula coste de reintentos, backfill y mantenimiento. Distingue coste causado por el incidente del baseline. Los presupuestos alertan; no sustituyen un control operativo de concurrencia, autotermination y modos serverless adecuados.

SELECT
  usage_date,
  usage_metadata.job_id AS job_id,
  sku_name,
  SUM(usage_quantity) AS usage_quantity
FROM system.billing.usage
WHERE usage_metadata.job_id = '482901'
  AND usage_date BETWEEN DATE '2026-07-18' AND DATE '2026-07-21'
GROUP BY usage_date, usage_metadata.job_id, sku_name
ORDER BY usage_date;

El postmortem reconstruye impacto, detección, timeline, causa raíz y factores contribuyentes con evidencia. Evita 'error humano' como causa final: pregunta qué guardrail, test o diseño permitió que una acción normal causara daño. Separa acciones correctivas por prevenir, detectar, mitigar y aprender, con propietario y fecha.

Cada acción debe tener condición de cierre. 'Mejorar monitorización' no sirve; 'alertar si p95 supera 24 min durante dos runs y enlazar el Query Profile' sí. Actualiza runbooks, añade una prueba de regresión con distribución representativa y valida el fix bajo carga. Comparte el aprendizaje sin incluir datos sensibles del incidente.

actions:
  - id: INC-2041-A1
    class: prevent
    owner: data-orders
    change: "test de skew con 45 % de claves nulas"
    done_when: "p95 de tareas < 3x mediana en CI de rendimiento"
  - id: INC-2041-A2
    class: detect
    owner: platform-observability
    change: "alerta de p95 runtime y enlace a statement_id"
    due: 2026-08-05