SLA de datos

¿Qué es?

Un SLA de datos (Service Level Agreement) es el compromiso explícito que el equipo responsable de una tabla, un flujo o un producto de datos adquiere frente a quienes lo consumen: hasta qué punto estará actualizado, disponible y correcto.

Es la respuesta escrita a una pregunta que normalmente se contesta de palabra: “¿puedo fiarme de esta tabla para decidir el martes por la mañana?”.

Qué contiene un SLA de datos

Un compromiso útil se concreta en pocas cláusulas medibles:

• Frescura: antigüedad máxima aceptable del dato más reciente. Es la cláusula que más se incumple y la que más duele; se apoya en la frescura de datos medida sobre el destino.
• Disponibilidad: a qué hora estará lista la tabla y qué porcentaje de días se cumple esa hora.
• Completitud: qué volumen mínimo se espera, para detectar cargas que terminan bien con la mitad de las filas.
• Corrección: qué reglas de calidad de datos se verifican antes de dar la carga por buena.
• Notificación: cómo y en cuánto tiempo se avisa al consumidor cuando algo de lo anterior falla.

Lo que no se puede medir automáticamente no entra en el SLA: se convierte en una promesa que nadie comprueba.

SLA, SLO y SLI

Los tres términos vienen del mundo de la fiabilidad de sistemas y conviene no confundirlos:

• SLI (indicator): la medida en crudo. “La tabla de pedidos tiene 35 minutos de antigüedad”.
• SLO (objective): el objetivo interno del equipo. “La antigüedad debe mantenerse por debajo de 60 minutos el 99 % de los días”.
• SLA (agreement): el compromiso acordado con el consumidor, normalmente algo más laxo que el SLO y con consecuencias definidas si se incumple.

La distancia entre el SLO y el SLA es deliberada: deja margen para reaccionar antes de romper lo prometido.

SLA y contrato de datos

Un contrato de datos describe la forma: qué campos hay, de qué tipo, con qué significado y qué pasa cuando cambian. El SLA describe el servicio: cuándo llega y en qué estado.

Suelen viajar juntos —el contrato es el sitio natural donde escribir el SLA— pero responden a preguntas distintas. Un esquema estable que llega doce horas tarde cumple el contrato e incumple el SLA.

Cómo se mide

El SLA no vale nada sin instrumentación. La secuencia habitual:

1. Medir primero, comprometer después. Observar durante unas semanas cómo se comporta realmente el flujo. Un SLA fijado sobre lo que al equipo le gustaría nace incumplido.
2. Instrumentar la medida en el destino, no en el proceso. Las herramientas de observabilidad de datos lo hacen de serie.
3. Publicar el cumplimiento donde lo vea el consumidor. Un SLA que solo conoce quien lo firma no cambia ninguna conversación.

Por qué importa para el negocio

Un KPI heredado de una tabla sin SLA es una cifra sin garantía: puede estar al día o llevar dos días parada, y quien la mira no tiene forma de saberlo.

Por eso el SLA conviene acordarlo antes de elegir la arquitectura, no después: es lo que decide la técnica de integración. Si el compromiso es de minutos, hace falta algo como CDC; si es de horas, un proceso por lotes cubre lo mismo con mucha menos complejidad operativa. Hacerlo al revés —elegir la tecnología primero y descubrir luego qué se necesitaba— explica buena parte de las plataformas sobredimensionadas que después cuesta mantener.

Más información

• Eventos vs batch: los fundamentos de la integración de datos — capítulo de la guía práctica de arquitectura de datos de Dataprix.
• Compara herramientas de calidad y observabilidad en el directorio de Dataprix.