Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 27 · Lección

Triage y severidad

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu 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.

Duración
30 min aprox.
Objetivo
Dirige un incidente con severidad, roles, timeline y criterios de éxito explícitos antes de tocar configuración.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyecto de fiabilidad y coste

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

Al terminar podrás
  • Resolver un incidente con método
  • Demostrar mejora con métricas
  • Definir prevención y alertas
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 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.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m26
Reportar un error en esta lecció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.

Modelo mental

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.
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.

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.

Recuerdo activo

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

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

databricks-finops-system-tables

databricks-finops-system-tables · commit 7834d5d

README.md