Saltar al contenido

Proyecto FinOps

Menú

Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.

Guardar progreso

Lección 1 de 5

Triage y severidad

Dirige un incidente con severidad, roles, timeline y criterios de éxito explícitos antes de tocar configuración.

30 min aprox.

Detalles

Proyecto de fiabilidad y coste

Recupera un workload degradado equilibrando SLA, capacidad, layout, código y presupuesto.

Reto observable

Recupera un workload degradado y entrega un postmortem que demuestre mejora de fiabilidad y coste y asigne acciones preventivas.

Al terminar podrás
  • Resolver un incidente con método
  • Demostrar mejora con métricas
  • Definir prevención y alertas
Prerrequisitos
m26
Última revisión
25 ago 2026
Nivel
Professional
Ruta relacionada
performance
Dominios blueprint
Reliability · Cost & Performance
Estado
Revisión editorial interna
Fuentes principales
Monitor Lakeflow Jobs · Query profile
Reportar un error
01
Modelo mental

Triage y severidad

Dirige un incidente con severidad, roles, timeline y criterios de éxito explícitos antes de tocar configuración.

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.

YAMLCabecera de un expediente de incidente
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"

El expediente es operativo: evita nombres de clientes y enlaza evidencia gobernada en lugar de pegar datos sensibles.

¿Qué diferencia una mitigación de una causa raíz?

Profundiza

Un incidente es un sistema de decisiones bajo incertidumbre. Antes de optimizar Spark o cambiar compute, el equipo necesita una imagen común: impacto, severidad, servicio afectado, inicio probable, propietario y condición de recuperación. El incident commander coordina y protege la línea temporal; quienes investigan prueban hipótesis; quien comunica mantiene informados a los consumidores. Separar funciones reduce cambios simultáneos y memoria contradictoria. El objetivo inmediato no es encontrar la explicación perfecta, sino restaurar el servicio con una mitigación reversible y evidencia suficiente. Cada acción debe declarar hipótesis, riesgo, señal esperada y rollback. Sin esa disciplina, aumentar recursos puede ocultar la causa, elevar coste y destruir la comparación necesaria para el análisis posterior.

Incident commander

Rol único que coordina prioridades, responsables, decisiones y comunicación durante la respuesta, sin necesitar ejecutar cada investigación técnica personalmente.

Evita órdenes contradictorias, cambios simultáneos y pérdida de una visión común del impacto y la recuperación.
Mitigación reversible

Cambio temporal cuyo efecto puede deshacerse rápidamente si no mejora las señales o introduce un riesgo nuevo.

Permite recuperar servicio con incertidumbre sin convertir una reacción urgente en deuda o daño permanente.
Criterio de recuperación

Condición medible que combina disponibilidad, latencia, integridad y frescura para declarar restaurado el servicio afectado.

Impide cerrar cuando sólo desaparece el error visible pero permanecen datos atrasados, incorrectos o consumidores rotos.
Resumen

Puntos clave

  • Prioriza impacto y seguridad de datos sobre una optimización elegante.
  • Registra cada hipótesis, acción, resultado e identificador.
  • Separa mitigación inmediata de corrección permanente.

Evita

  • Cambiar varias configuraciones a la vez y perder atribución causal.
  • Declarar resuelto al terminar el job sin validar calidad y consumidores downstream.

Vista de lectura · sin ejecución

databricks-finops-system-tables

databricks-finops-system-tables · commit 7834d5d

README.md

Módulo 27

Contenido del módulo