En la última mitad del 2015 me embarqué en una serie de proyectos 100% en la nube: computación distribuida, bigData, learning-machine, etc… y si algo estoy aprendiendo tanto a nivel proveedor de servicios basados en la nube como CTO digitalmeteo, como en otros proyectos como cliente de servicios en la nube, es tener mucho cuidado con los SLAs que se ofrecen y con los que se firman, sus indicadores, forma de medición, marcos temporales, etc.

Si hace unos días os dejaba los 3 puntos clave a tener en cuenta en la adopción de servicios en la nube, hoy os dejo una pequeña guía de los puntos clave a revisar en un SLA, qué significan y dónde hay que poner más atención.

 

Disponibilidad de servicio

Significa el tiempo, normalmente expresado en porcentaje, que el servicio contratado debe estar disponible y funcionando sin errores, sean del tipo que sean.   Evidentemente, la contabilización de disponibilidad del servicio nunca puede verse afectada por fallos en la propia infraestructura del cliente del servicio o por fallos atribuibles a mal uso o mala implementación por parte del usuario o cliente.
¿Y qué valores son “buenos” en el KPI de disponibilidad? Pues depende… veamos de qué…

 

Rendimiento del servicio (latencia, tiempo de espera…)

Es conveniente indicar cuál es la calidad mínima espera del servicio.  No nos vale de nada que el servicio esté operativo si los tiempos de respuesta van más allá de lo aceptable.  Idealmente, el no cumplimiento de la medida que se establezca en el SLA de rendimiento, debería considerarse como indisponibilidad.  Por tanto, en muchas ocasiones este indicador forma parte del indicador de Disponibilidad.

Por ejemplo, supongamos que tenemos un servicio que debe responder en menos de 200 milisegundos.  Si en los momentos de medición este servicio responde en 280ms, habrá que repetir la medición casi de forma inmediata, y si se confirma que el tiempo/latencia es superior al establecido, deberá empezar a contar como tiempo de indisponibilidad hasta que recupere los valores que se han establecido.  Solo así podremos controlar la calidad del servicio contratado, porque no nos vale de nada como cliente contratar un servicio de disponibilidad 99.95 o más, si los tiempos de respuesta son malos y no encajan en nuestro proceso.

 

Periodo de servicio

Seamos realistas: no todos los servicios los necesitamos 24/7/365. Y de hacerlo, casi seguro no es necesario un 27/7 en todas y cada una de las franjas horarias globales.  Quizás debamos dar servicio sí o sí de 8am a 10pm. Y aunque el servicio se preste de forma global, eso significa que las mediciones han de hacerse acorde a la franja horaria de cada punto de la medición.  Es decir, necesitaremos monitores del servicio en Europa que comprueben en esa franja horaria (en el ejemplo, de 8am a 10pm) pero no fuera de ella, y en USA necesitaremos otro monitor que se active en su horario de servicio, y en Australia… etc…  ¿me sigues?

Igualmente, quizás nuestro servicio no es necesario fines de semana, por ejemplo.  O quizás en países árabes el domingo sí… pero solo por la mañana….

En fin, te haces una idea…. estos puntos deben quedar indicados como Periodo de Servicio en el SLA, de forma que quede muy claro dónde se debe prestar el servicio y en qué franja horaria para cada zona.

 

Excepciones y exclusiones

En este punto debemos especificar, muy claramente definidas de forma explícita y bien acotada y limitada, qué excepciones tanto temporales como técnicas permiten no cumplir con la disponibilidad o rendimiento que se indique.

Por ejemplo, podría firmarse como excepción un período limitado y de indisponibilidad o de reducción de rendimiento cada 3 meses para tareas de mantenimiento necesarias, con un pre-aviso acordado y conocido por ambas partes.

Si somos los clientes del servicio, debemos tener cuidado con este punto, porque es donde más agujeros de indefinición pueden aparecer.  Y si somos los proveedores del servicio, debemos ser conscientes de nuestra planificación de tareas técnicas relativas a la infraestructura o software del servicio, y plantear al cliente claramente y con total transparencia estas necesidades:  que la firma de un contrato o ganar un nuevo cliente no nos haga meternos en unos posibles líos legales que finalmente haga que perdamos dinero…. y clientes.

 

Elementos de medición de cumplimiento

Como proveedores de servicios en la nube, debemos tener las herramientas adecuadas para monitorizar, por nuestro propio bien, la calidad y continuidad de nuestros servicios ofrecidos, de la forma más parecida (en topología de red y localización geográfica) a como lo hacen nuestros clientes.  Evidentemente cubrir todos los escenarios es imposible, así que debemos sopesar donde parar…   Es buen ejercicio además abrir los portales de información de estado –dashborads– al público en general, para que tanto nuestros clientes como los clientes potenciales, tengan acceso a estos datos:   transparencia y confianza… ya sabes…

Como clientes, deberíamos tener formas de monitorización y control diferentes a las que ofrezca el propio proveedor, por aquello de no confiar al zorro guardar el gallinero…

En este sentido, cada vez hay más oferta de servicios de monitorización neutrales, de terceros, que ofrecen KPIs independientes o pueden instalar monitores a petición en la infraestructura del cliente, que les indique la calidad y continuidad de los servicios contratados.

Obtención de medidas

Para cada punto del SLA que se acuerde, se debe establecer minuciosamente el procedimiento del cómo se obtienen los datos, desde dónde (físicamente), con qué tipologías de máquinas se ocuparán de ello y los valores y configuración del sistema de cada una que deben tener y cumplir para que la medición sea tomada como válida.

Y además, se deberá indicar cuándo se tomarán estas mediciones.  Podría ser por ejemplo algo como “se tomarán 5 mediciones diarias en el periodo establecido de disponibilidad, de forma aleatoria, siempre con una diferencia mínima entre mediciones de 30 minutos y máxima de 3 horas”.

Parece obvio, pero este punto es importante porque nos puede revelar comportamientos donde nuestro SLA falla a determinadas horas o días, mientras que quizás el proveedor del servicio no lo detecte porque los momentos de medición no coinciden.

Consecuencias de incumplimiento o sobre-cumplimiento

Poner todos los puntos anteriores en negro sobre blanco no serviría de nada si el incumplimiento de dichos acuerdos no tienen consecuencias para quien los incumple, o en el caso de sobrepasar las expectativas del cliente.

Imaginemos que estamos ofreciendo como proveedores un servicio a un cliente que impacta su velocidad de respuesta directamente en sus ventas o beneficios, por ejemplo operaciones High-Frecuency Tradings o mucho más común, renderizado o puesta a disposición de componentes estáticos de una eCommerce, donde el tiempo de respuesta impacta directamente en las ventas.

Debe plantearse qué medidas se tomarán (económicas, etc) ante determinados incumplimientos, incluso con grados de incumplimiento, porque no es lo mismo pasar de una disponibilidad de 99.8% a 99.7% que a 85.0%…   o que nuestro servicio que según la SLA debe tener una latencia máxima de 250ms, de una latencia de 280ms o de 500ms….

E igualmente en el otro sentido…  que para los ejemplos que ponía arriba, el proveedor de servicio debería verse de alguna forma recompensado si es capaz de ofrecer el servicio en menos tiempo y por tanto hace ganar más dinero al cliente, o el grado de cumplimiento del KPI de disponibilidad supera con creces las expectativas.  Aunque seamos francos, esta parte es realmente complicada de hacer firmar a los clientes, y como clientes, nos negamos casi en rotundo a que se integren en el documento de SLA’s.

 

 

Ahora queda en tu tejado analizar tus servicios, tus proveedores, y ver qué SLA’s puedes o no firmar o ajustar con ellos.  Obviamente si dependes de AWS (Servicios de Amazon) o de los servicios en la nube de Google, y no tienes el peso “financiero” suficiente, tendrás que conformarte con los SLAs que ofrecen “de caja”, pero no sólo existen estos proveedores de servicio, seguro que tienes muchos más con los que poder negociar de forma justa los SLAs.  En cualquier caso, y siendo cliente o proveedor de servicios en la nube: se realista.  No hay nada peor que no se cumplan nuestras expectativas o las de nuestros clientes simplemente porque se han sobre-dimensionado al punto de ser irreales.