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.
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
Une cada término con su definición.
SRE de datos
Toca una tarjeta para ver la respuesta.
Confiabilidad y operación de plataformas de datos
- SRE de datos
- Medir
- SLI frescura calidad coste
- SLI frescura calidad coste
- Medir
- Objetivo
- SLO
- SLO
- presupuesto de error
- alerta por sintoma
Google Site Reliability EngineeringMarco 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?
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.