Aplicación de niveles de servicios (SLA) para mejorar el Data Downtime.
En las últimas semanas hemos recibido algunas consultas de parte de nuestros clientes preguntándonos cómo mejorar la calidad de sus datos de una forma medible, eficiente y consistente en el tiempo con la finalidad de evitar las inconsistencias generadas por Data Downtime.
Data Downtime o tiempo de inactividad de datos se refiere a las inconsistencias de datos generadas por pipelines de datos que no fueron ejecutados correctamente, debido a errores de programación, los orígenes de datos mal cargados, o simplemente causado por un error aleatorio.
Estos errores suelen ser complejos de detectar si tu organización no posee una buena plataforma de observabilidad de datos que permita identificar caídas rápidamente y evitar que tus usuarios de negocio tomen malas decisiones.
Una buena plataforma de observabilidad de datos debe responder las siguientes preguntas: ¿Qué ocurrió? ¿por qué ocurrió? ¿con quién hablar? ¿a quien responsabilizar?
Cuando pensamos en observabilidad de datos, debemos pensar en el término de observabilidad de software, quiero decir, tenemos que generar métricas de disponibilidad de servicio que nos indique que tan bueno o malo es nuestro servicio.
Y en el caso contrario, ver dónde tenemos deficiencias para mejorarlo y reducir los problemas de calidad de datos que impactan al negocio.
Una de las métricas que nos será realmente útil es el acuerdo de nivel de servicio (SLA) que representa un acuerdo de calidad entre los productores y consumidores de un servicio.
Debemos pensar que la generación de buenos SLA nos servirán no solamente para garantizar la confiabilidad, frescura y calidad de nuestros datos, sino también para establecer una cultura de comunicación y confianza entre productores y consumidores de datos.
Pero, ¿Cómo podríamos aplicar un SLA en nuestros datos?
¿Cómo crear un SLA?
Para crear un buen SLA, debemos definir 3 métricas fundamentales. Indicador de nivel de servicio (SLI), nivel objetivo de servicio (SLO) y acuerdo de nivel de servicio (SLA).
- SLI: es la métrica que se utiliza para medir los niveles de servicio
- SLO: es el rango que somos capaces de cumplir con nuestros SLI
- SLA: los SLA reúnen los SLO en un acuerdo integral que incluye el presupuesto de errores para cualquier SLO determinado. Los SLI y los SLO son los componentes de un SLA. El SLA debe representar la alineación de las expectativas y el compromiso entre los productores de datos y los consumidores
Podemos pensar en estos componentes como “valor -> lo que obtenemos -> lo que prometemos”.
Un ejemplo concreto de la aplicación de un SLA podría ser la monetización de nuestros datos con uno de nuestros socios comerciales, dado que buscamos mejorar la calidad y la confianza en este proceso:
Diariamente a las 9:00 AM compartimos datos a uno de nuestros socios comerciales para agilizar los pedidos que recibimos de su parte.
Nos gustaría mejorar el servicio de intercambio de datos que tenemos con ellos y además ser capaces de aumentar los lazos de confianza que tenemos en el mismo.
Para esto, podemos declarar un SLI que nos indique la cantidad de minutos de retraso en el proceso de intercambio de datos.
Como SLO tendríamos el rango de minutos obtenidos desde la medición de escenarios ya validados de procesos de intercambios de datos (con el histórico de ejecuciones). Por ejemplo, en promedio los datos están en el repositorio de nuestro socio a las 9:15 AM.
Por último como SLA debemos alinear las expectativas versus el valor empírico obtenido del SLO para definir un acuerdo de nivel de servicio.
En este ejemplo, podríamos tener un acuerdo de nivel de servicio, en donde le ofrecemos una confianza que el 99,9% de las veces los datos estarán disponibles en su repositorio antes de las 9:30 AM y en el caso de no cumplirlo le damos un descuento de un 5% del valor.
En los siguientes apartados vamos a mostrarte en detalle como crear buenos SLA que permitan incrementar la confianza de tus productos de datos.
Recopilar los dolores de los interesados
El primer paso es identificar quienes son las partes interesadas y cuales son sus necesidades, en consecuencia a que un buen SLA debe representar un dolor, no sólo ser una métrica.
Por ejemplo, un SLA que indique la disponibilidad de una plataforma no es de interés para un consumidor de datos, dado que la plataforma puede estar 100% disponible, pero los datos pueden venir incompletos.
Por lo tanto, necesitamos el feedback de los usuarios de negocio.
Crear objetivos
Una vez hayas recopilado los dolores de los consumidores de datos, puedes comenzar a definir los objetivos de tus SLA.
Disponibilidad de datos
Cuando pensamos en disponibilidad de datos, debemos tener siempre en cuenta que debemos pensar ¿Se encuentran disponibles? ¿Son consumibles? ¿Los pipelines de procesamiento están funcionando? ¿El sistema de consultas está operativo?
Por otro lado, debemos pensar en el tiempo que le costaría a nuestros consumidores acceder a ellos, en consecuencia a que si un usuario tarda horas para acceder a sus datos de interés tendremos una mala calidad de servicio.
Algunos ejemplos
Supongamos que con nuestro SLA de intercambio de datos prometemos un tiempo de actividad del 99,9%, por lo tanto, ese SLA nos permite solamente 43 minutos de tiempo de inactividad por mes. Esa especificidad es fundamental para aumentar la confianza.
En el caso que necesitemos medir la velocidad de consulta o acceso a nuestros datos, nuestro SLA sería similar a «X% de consultas completadas en Y segundos».
Para armar un SLA, podemos preguntar
¿Qué significa la disponibilidad de datos para su parte interesada?¿Qué velocidad de consulta necesitan para ser considerados como no disponibles?
¿Cuánto tiempo puede permanecer una consulta en espera y satisfacer las necesidades comerciales de sus consumidores de datos? ¿10 minutos? ¿1 hora?
¿Hay gerencias que tienen mayor prioridad y necesitan tiempos de respuesta más ágiles?
Actualización de datos
Con actualización de datos nos referimos a cuando fue la última vez que los datos fueron modificados en nuestro repositorio, o cuánto tiempo tarda un conjunto de datos en completarse una vez que ingresa al pipeline de ingesta.
Los SLA que establezca dependerá principalmente de las necesidades de sus consumidores y las limitaciones de su plataforma de datos. Si un equipo de Marketing requiere hacer campañas geo referenciadas en tiempo real y usted le provee un SLA de 10 horas será demasiado tarde y no tendrá valor, dado que el prospecto estará fuera de la zona de interés.
Una recomendación para definir buenos SLA de actualización de datos es incluir cuánto tiempo llevaría resolver una falla en sus pipelines de datos.
Por ejemplo, si procesar las transacciones de sus clientes toma 4 horas y tiene un SLA de 5 horas, en el caso de que su pipeline de datos falle no tendrá tiempo para resolver el incidente y volver a procesar sus datos.
Acá nuevamente, se aprecia la necesidad de que las organizaciones tengan una buena plataforma de observabilidad de datos, dado que les permite agilizar el tiempo de respuesta ante caídas inesperadas de sus pipelines de datos.
Algunos ejemplos
Un SLA bastante simple que podríamos definir sería cuanto es el tiempo transcurrido desde que se procesaron los datos. Por ejemplo, podemos usar marcas de tiempo para saber cuando se realizó la compra de un retail y otra marca que indique cuando estos datos estuvieron disponibles en tu repositorio de datos.
Otro SLA sería ¿Cuántos minutos tenemos de retraso entre el servidor principal y nuestra réplica local?
Para armar un SLA, podemos preguntar
¿Con qué frecuencia se deben cargar los datos para satisfacer las necesidades de los casos de uso de tus consumidores?
¿Cuánto tiempo dura una iteración fallida en esa ventana de tiempo?
Calidad de datos
Cuando pensamos en calidad de datos, pensamos en el término holístico y ya conocido por los equipos de gobierno de datos dado que representa cuán libres de errores están nuestros datos; pueden ser tan simples como un error tipográfico en un campo de nombre o correo, o puede que falte un nombre por completo.
Algunos ejemplos
Corrección: ¿Qué tan precisos son nuestros datos cuando se comparan con los de los orígenes? ¿Qué tan libres de errores sintácticos están nuestros datos?
Completitud: ¿Qué porcentaje de los campos tienen un valor? ¿Cuál es el porcentaje de valores nulos en los datos?
Para armar un SLA, podemos preguntar
¿Qué tablas o entidades pueden tener valores nulos?
¿Son aceptables los valores nulos en los datos?
¿Son aceptables las constantes en las fechas o valores del pasado?
¿Existe una precisión de decimales mínima o máxima?
Retención de datos
La retención de datos se refiere a cuánto tiempo deben permanecer disponibles los datos para los cumplir con los casos de uso requeridos por los consumidores de datos.
Debido a que el valor de los datos tiende a disminuir con el tiempo, los costos de administración pueden aumentar y pueden haber limitaciones de los productos de repositorios de datos en el mercado.
Algunos ejemplos
5 Años de permanencia para las transacciones de los clientes
Tener un costo máximo de 1.000 USD para el almacenamiento de datos
Para armar un SLA, podemos preguntar
¿Cuánto tiempo se espera mantener los datos?
¿Con qué frecuencia se deben programar la eliminación periódica de datos?
¿Se pueden agregar diferencias incrementales de datos?
¿Se pueden mover los datos a un almacenamiento en frío?
Casos extremos a tener en cuenta al redactar un SLA
Si incluye datos de proveedores externos que no están bajo su control. Se puede dar el caso que una fuente de datos podría estar dañada o no disponible provocando que no se cumplan los SLA que definimos.
Es necesario que aclare si esta instancia estará excluida de sus SLA.
¿Es necesario que los consumidores usen datos fuera del horario de atención o los fines de semana? De no ser así, ¿pueden excluirse estos períodos al calcular el tiempo de inactividad?
Protocoliza la respuesta
Cuando definimos los SLA que son de interés para nuestros consumidores de datos, debemos negociar los objetivos que esperamos de ellos. Donde ambas partes deben tener claro qué sucederá si algo sale mal.
Una interrupción en el servicio es estresante para los involucrados, pero no tiene que ser conflictiva entre éstos.
Algunas cosas a considerar en caso de emergencia son:
Si hay inactividad de datos, ¿a quién se le notificará, cómo y cuándo?
¿Con qué frecuencia los interesados esperan recibir actualizaciones de estado?
¿Se realizarán revisiones post mortem después de que se resuelva un incidente y se compartan los resultados con las partes interesadas?
Por lo general, los SLA entre una empresa y sus clientes externos incluyen compensaciones en caso de que no se cumplan los SLA. Por ejemplo, si monetizas tus datos y no cumples los SLA que definiste puedes ofrecer un descuento de 5% del valor mensual por la pérdida de oportunidades que tuvo tu cliente.
Comienza a medir
Una vez definidos los SLA que tienen impacto a tus productos de datos y lo que significan. El siguiente paso es integrar el cálculo de los insumos necesarios para monitorear la frescura, calidad y precisión de tus datos.
Entre las opciones disponibles se encuentran, adquirir herramientas de Data Observability o desarrollar adaptadores comunes que se integren a tus flujos de datos.
Comunica, itera y crea bucles de retroalimentación
Cuando se determinan los SLA, deben documentarse y ser publicados para que todos los interesados tengan conocimiento de ellos. Si te parece más simple puedes generar una página web dedicada a exponer los SLA de tus productos de datos, brindándole una fuente de información a todas las partes interesadas.
Los SLA son documentos vivos; pueden ser re-evaluados y revisados.
Por ejemplo, si a menudo hay confusión en las expectativas entre los productores de datos y los consumidores, es posible que necesites modificar tus SLA.
¿Quieres aumentar la confiabilidad de tus datos?
Si te gusto este blog y quieres implementarlo en tu compañía no dudes en revisar nuestros servicios de Data Reliability.
¡QUIERO SABER MÁS!