Confiabilidad y operación de plataformas de datos
Cuando los datos se consumen como producto, pasa a regirlos la ingeniería de confiabilidad (SRE): objetivos de servicio, presupuestos de error, alertas accionables y procedimientos de incidente. El pipeline deja de ser un script y se convierte en un servicio con responsabilidad de disponibilidad.
SLI, SLO y SLA
- SLI: la medición concreta (frescura, calidad, tiempo de disponibilidad).
- SLO: el objetivo interno para ese indicador (la tabla se actualiza en menos de 6 horas).
- SLA: el acuerdo con consecuencias externas si se incumple.
Presupuesto de error
Un SLO del 99% deja un 1% de tolerancia al fallo: ese es el presupuesto de error. Mientras quede presupuesto, se prioriza velocidad (desplegar cambios); cuando se agota, se prioriza fiabilidad. Convierte el debate "confianza contra rapidez" en una decisión medible.
Alertas accionables
Una alerta debe representar un síntoma del usuario y exigir una acción. Alertar por cada causa o por métricas que nadie puede influir genera ruido y termina normalizando ignorarlas. La mejor alerta es la que despierta a alguien por algo real.
Runbooks y postmortems
Un runbook documenta qué hacer ante cada fallo: diagnóstico, mitigación y escalación. Después del incidente, un postmortem sin culpables registra qué pasó y qué se cambia para que no se repita: el aprendizaje se convierte en sistema.
| Concepto | Qué es | Para qué sirve |
|---|---|---|
| SLI | indicador medido | saber cómo va el servicio |
| SLO | objetivo del indicador | acordar qué es suficiente |
| Presupuesto de error | tolerancia al fallo | equilibrar velocidad y fiabilidad |
| Runbook | procedimiento de incidente | responder rápido y sin improvisar |
Errores frecuentes
- Alertar por causas y por todo, hasta que el equipo deja de hacer caso.
- No definir SLO, de modo que no hay criterio para subir o bajar cambios.
- Postmortems con culpables que se dejan de escribir.
Ejemplo resuelto: una entrega llega tarde cada lunes
- Definir el SLI de frescura de esa tabla y un SLO (por ejemplo, lista antes de las 8).
- Instrumentar una alerta por síntoma, no por causa.
- Escribir el runbook de la contingencia (servir último dato bueno y notificar).
- Hacer un postmortem sin culpables y agregar una verificación al pipeline.
- Revisar el presupuesto de error para decidir cuánto invertir en fiabilidad.
¿Para qué sirve en la realidad?
Un equipo que opera datos con mentalidad SRE deja de apagar fuegos a ciegas: sabe qué tan confiable es su plataforma, decide con evidencia cuánto fiabilidad comprar, y responde ante las caídas con procedimiento y no con pánico.
¿Qué es el presupuesto de error en un servicio de datos?
Una alerta accionable debe basarse en un síntoma del usuario y no en cualquier causa interna.
El documento con el procedimiento a seguir ante un incidente se llama .
Clasifica cada elemento según la cadena medir-objetivo-responder.
Medir
Objetivo
Responder
Une cada término con su definición.
SRE de datos
Confiabilidad y operación de plataformas de datos
# SRE de datos ## Medir ### SLI frescura calidad coste ## Objetivo ### SLO ### presupuesto de error ## Responder ### alerta por sintoma ### runbook ### postmortem sin culpables
Google Site Reliability Engineering
Marco de referencia de SLOs, alertas y gestión de incidentes.
Implementing SLOs (Google SRE Workbook)
Guía práctica para definir y usar objetivos de servicio con presupuesto de error.
Tu equipo vive apagando incendios de pipelines pero nadie sabe si la plataforma es confiable. ¿Qué SLI y qué SLO propondrías primero para convertir esa operación reactiva en una decisión con presupuesto de error?