Una lista de verificación de 11 puntos para establecer y cumplir los SLA de datos (con una plantilla de SLA)

Nos atreveríamos a decir que ningún equipo es demasiado pequeño para elaborar y comprometerse con un acuerdo de nivel de servicio de datos, o SLA de datos. ¿Qué es un SLA de datos? Es una promesa pública de ofrecer un nivel de servicio cuantificable. Al igual que sus proveedores de infraestructura como servicio (IaaS) se comprometen a un tiempo de actividad del 99,99 %, usted se compromete a proporcionar datos de cierta calidad, dentro de ciertos parámetros.

Es importante que el compromiso sea público (dentro de la empresa, al menos). El carácter público fomenta una mayor responsabilidad, ayuda a que todos los equipos se alineen en torno a lo más importante y permite crear una estructura que respalde la calidad.

En esta guía, exploramos cómo establecer su propio SLA de datos.

Los SLA de datos formalizados y escritos hacen que sus compromisos informales sean concretos y mutuamente aceptables. Toda relación de datos implica compromisos informales, los expresemos o no, y muy a menudo, dos partes pueden ponerse de acuerdo en algo sin darse cuenta de que están hablando de cosas diferentes.

Entonces, ¿qué es exactamente el SLA de datos? Es un documento escrito simple, generalmente de 250 a 500 palabras, publicado en un espacio compartido como una wiki de la empresa o Google Doc. Debe incluir 6 elementos:

• Propósito: ¿Por qué existe este SLA de datos? ¿Qué problemas espera que resuelva y cómo espera que se utilice?

• Promesa: ¿qué promete a otros equipos?

• Medición: ¿cómo medirá el SLA de datos, quién lo medirá y cuál es el plazo del mismo?

• Ramificaciones: ¿qué sucede cuando  no cumple con su SLA de datos? ¿Quién es responsable y qué tipo de correcciones están disponibles, si las hay?

• Requisitos: ¿qué espera a cambio? ¿Cómo son sus promesas condicionales?

• Firmas: ¿quién se compromete con el SLA de datos?

Al redactar su SLA de datos, expréselo con la menor cantidad de palabras posible sin alterar el significado. Esto requiere mucho trabajo de edición, pero le recomendamos que lo escriba todo de una sola vez, sin preocuparse por la forma, y que vuelva a editarlo más tarde. La razón es que, si se queda mirando la página durante demasiado tiempo, puede desarrollar lo que los escritores denominan “ansiedad por la página en blanco” y seguir posponiéndolo. Redacte ahora un borrador de mala calidad, no espere.

A continuación se muestra un ejemplo de acuerdo de nivel de servicio de datos:

El propósito de este documento es establecer una promesa pública de nuestro equipo a otros para mantener una alta calidad de los datos dentro de parámetros precisos. Esperamos que esto genere comprensión, nos ayude a trabajar juntos y mantenga a nuestros equipos mutuamente responsables.

Nuestro compromiso: entregaremos datos de ventas con una puntuación de calidad de datos de al menos el 95 % antes de las 5:00 ET todos los días para que el equipo pueda responder a preguntas como “¿Cuáles fueron las ventas de ayer?”. Acusaremos recibo de todas las solicitudes en el plazo de un día hábil y las clasificaremos en tiques simples y complejos. Resolveremos las solicitudes simples en un plazo de tres días hábiles y las complejas en un plazo de dos semanas.

Mediremos la calidad de los datos comparando los KPI de entrega de datos, como las horas de inicio y finalización de la ejecución, el recuento de registros y la proporción de nulos a registros, y las puntuaciones de distribución y desviación con los estándares predefinidos de frescura, integridad y fidelidad de los datos.

Si no cumplimos un SLA de datos, en un plazo de tres días hábiles, nuestro equipo publicará una disculpa pública asumiendo la responsabilidad, explicando por qué ha ocurrido y las medidas precisas que estamos tomando para solucionarlo.

Para cumplir esta promesa, necesitamos su ayuda. Nuestro equipo necesita orientación oportuna, aportaciones y un feedback claro sobre cómo se utilizan los datos, así como un aviso con al menos cuatro semanas de antelación de cualquier cambio complejo que se solicite.

Envíen todas sus preguntas, comentarios e inquietudes a data-eng@team.com.

Con determinación,

– Su equipo de Ingeniería de Datos

Con su SLA establecido (o tal vez mientras lo edita), empiece a pensar en todas las cosas que necesita poner en marcha antes de poder cumplirlo.

Por ejemplo:

Intente eliminar la mayor ambigüedad posible de esta frase. Defínalo en términos concretos e inequívocos. Como vemos, hay cuatro características que puede utilizar para definir los datos de alta calidad. Una vez definidos, consiga que los demás equipos estén de acuerdo con esa definición.

Pregúntese:

• ¿Cuál es el resultado de contar con datos de calidad para la empresa?
• ¿Qué características únicas definen los datos de calidad?
• ¿Qué características definen los datos de mala calidad?

Para el seguimiento, necesitará una herramienta de observabilidad que le permita saber si partes de su pipeline están inactivas. Sin ella, es bastante difícil medir si se está incumpliendo un SLA, y mucho más diagnosticar la causa raíz. También le ayudará a comprender los errores para que pueda corregirlos mucho más rápido.

Puede tratar su SLA de datos como una métrica de estrella polar, un punto focal que sirva de guía para todos. Pero, por supuesto, dentro de él hay mucha complejidad oculta, y tendrá que hacer un seguimiento de una serie de KPI que le ayuden a saber qué está pasando en las fases anteriores y posteriores.

Estas son algunas recomendaciones específicas:

1. Establezca pruebas automáticas para monitorizar la calidad de los datos en sus cuatro dimensiones
   • Pruebe los datos antes de la producción
   • Pruebe en cada etapa: integridad, anomalías
2. Mida su capacidad para detectar, responder y resolver problemas
   • Tiempo de descubrimiento
   • Tiempo de resolución
   • Incidentes por activo
3. Documente las causas inmediatas y fundamentales de cada problema.
   • El partner de datos no ha realizado una entrega
   • Tiempo de espera agotado
   • Trabajo atascado en una cola
   • Transformación inesperada
   • Problema de permisos
   • Error de tiempo de ejecución
   • Cambios en la programación

Tenga cuidado con lo que se compromete. No se puede estar en todas partes y prepararse para todo, y un SLA del 99,999 % de tiempo de actividad significa que solo puede tener 5 minutos de tiempo de inactividad al año. Para cumplir con eso, probablemente necesite más personal, más visibilidad, más redundancias y personas que trabajen las 24 horas del día.

Probablemente necesite una herramienta de gestión de incidencias como Jira o ServiceNow. Esto permite a los usuarios de datos crear tiques, a su equipo hacer un seguimiento de ellos y a usted comprender la naturaleza de esos tiques para que pueda encontrar correcciones a largo plazo e identificar áreas problemáticas.

Es posible que no desee especificarlo en su documento público de SLA de datos, pero defina los propietarios de la fuente de datos y el pipeline. Son los responsables en última instancia si algo sale mal. Especifique también qué sucede si se van de vacaciones o dejan la empresa.

Configure alertas para publicarlas en la aplicación de mensajería de su equipo, como Slack, o en un sistema de gestión de incidentes como PagerDuty. Cuantos más detalles del incidente pueda incluir en esa alerta, más rápido podrá diagnosticar. Estas alertas le indicarán con antelación a quién más deberá involucrar o por dónde empezar el análisis (IBM® Databand puede enviar estas alertas y añadir conocimientos y contexto útiles).

Supongamos que un consumidor de datos le dice que una tabla no funciona correctamente en su panel de control. ¿Cómo lo confirma y responde? Escríbalo para que, cuando se produzca un incidente, no se encuentre con el problema del espectador, en el que todo el mundo asume que alguien más se encargará de ello y, al final, nadie actúa.

En función del tamaño de su equipo y de cómo estén distribuidos por todo el mundo, es posible que desee tomarse esto muy en serio y nombrar a lo que los servicios de emergencia denominan “comandante del incidente”. Esa persona se convierte en el CEO del incidente y dirige a todos los demás (esto garantiza una respuesta coordinada y ayuda a evitar que varias personas se ocupen del mismo problema).

Si puede, cree paneles de alerta en los paneles de control de las personas para poder comunicar el estado del sistema. Si algo sale mal, puede escribir: “Estamos teniendo una interrupción del servicio; este es el tiempo estimado para su resolución”. Esto disipará las alertas repetidas de todos los consumidores de datos y le permitirá responder de verdad.

Si no puede crear paneles de alerta, como mínimo, designe a una persona clave en cada equipo a la que pueda informar, que luego informará a todos los demás.

Monitorice cómo utilizan los datos los consumidores (y si realmente los utilizan). Realice encuestas ocasionales, formales o informales, para evaluar su confianza en esos datos y pídales sugerencias. A los consumidores interesados, comuníqueles cuál es su hoja de ruta.

Establezca periodos de mantenimiento periódico en los que su equipo revise por qué se han producido los fallos y proponga correcciones. Pregunte por qué han sido posibles esos problemas, realice un análisis posterior sin culpar a nadie, documente sus conclusiones, asigne las correcciones y monitorice cómo han funcionado.

Una vez que tenga todo esto claro, estará listo para editar y revisar su SLA de datos. Publíquelo en la wiki de su empresa o en algún lugar compartido, asegúrese del compromiso de todos y cúmplalo.

Los SLA de datos le ayudan a usted y a su equipo a ser honestos. Aunque se formulan como una promesa pública a terceros, en realidad son un acuerdo bilateral: usted acepta proporcionar datos dentro de parámetros específicos, pero a cambio, necesita la participación de las personas y su comprensión.

Muchas cosas pueden salir mal en la ingeniería de datos y muchas de ellas tienen que ver con la falta de comunicación. Documentar su SLA contribuye en gran medida a aclararlo todo, para que pueda lograr su objetivo final: infundir una mayor confianza en los datos dentro de su organización.

Comience a detectar los problemas de estado de los datos a tiempo y deje de perder dinero en los incumplimientos de los SLA de datos. Descubra cómo puede capacitar a sus ingenieros con alertas avanzadas y detección de anomalías para cortar de raíz los problemas de calidad. Si está listo para profundizar, solicite una demo hoy mismo.