No se asuste con el título, no hablaremos de Coelho ni de recetas esotéricas, sino de algo más terrenal. Las auditorías de seguridad a proveedores de servicio incluyen una pregunta: ¿Existen criterios acordados y verificables que permitan medir los niveles de servicio? ¿A qué se refiere niveles de servicio?
Un buen punto de partida, es seguir los lineamientos desarrollados por Google en su ya famoso "Site Reliability Engineering" o SRE. Trataremos de responder esta pregunta, y revisar las consecuencias que ello trae para los usuarios, servicios y la organización.
¿SLA, SLI, SLO?
La relación entre el cliente y un proveedor se regula a través de un contrato, para objetivar la calidad de un servicio intangible, se introducen los acuerdos de niveles de servicio o SLAs (Service Level Agreement). Frecuentemente, los SLA se relacionan con el uptime, y se mide en porcentajes, es decir, el tiempo en que estuvo funcionando un servicio dividido entre el tiempo total en el mes, por ejemplo, uptime de 99,5% mensual.
Sin embargo, que un servicio esté arriba o sea accesible la mayor parte del tiempo, puede que no satisfaga lo que desea el cliente. El usuario puede necesitar, y tal vez valorar más, que su sistema haga búsquedas rápidamente, o que el tiempo de acceso a una sección del sitio sea rápido desde varios puntos de Internet, o que atienda rápidamente a muchos usuarios concurrentes durante un Cyberweek. Entonces, ¿cómo medir esas experiencias de felicidad del usuario?
Para resolver esto Google propuso los SLI o indicadores del nivel de servicio (Service Level Indicators). Estos indicadores son una razón entre dos valores numéricos medibles en los sistemas, por ejemplo, un SLI podría ser los casos exitosos dividos por el total de casos. Entre las categorías definidas a medir mediante SLI podemos mencionar:
- Disponibilidad (Availability)
- Latencia (Latency)
- Calidad (Quality)
- Frescura (Freshness)
- Exactitud (Correctness)
- Cobertura (Coverage)
- Desempeño (Throuhput)
Veamos unas breves definiciones de tres SLI frecuentemente usados, aunque no implica que los otros no se usen.
- Disponibilidad: este es el caso explicado anteriormente, por ejemplo, para una VPS, el tiempo
funcionando en el mes/ tiempo total del mes. - Latencia: La proporción de requerimientos válidos que están bajo ciertos umbrales de tiempo, por ejemplo, el 95% de las respuestas del sistema deben ser menores a 3000 ms.
- Desempeño: La proporción de tiempo donde los datos son procesados más rápido que un
cierto umbral. El umbral se mide en bytes por segundo.
Como bien podemos intuir, no nos sirve de mucho saber el porcentaje de uso de CPU o RAM, cantidad de IOPS y otras métricas de hardware, porque poco le dirán a un usuario final. Puede que el uso de la CPU sea muy baja y que la mayoria de las acciones del sitio respondan muy lentamente, lo
que haría menos feliz al usuario. Si queremos medir la latencia de nuestro sistema, podríamos construir una aplicación cliente (synthetic client), ubicada en diferentes ubicaciones y simular acciones que harían los usuarios en el sitio. Luego, recolectar todos esos logs y construir un indicador de latencia del servicio. En general se recomienda tener no más de 3 ó 4 SLI para medir si un servicio funciona correctamente.
Finalmente, estos indicadores se traducen en lo que se conoce como SLO u objetivo del nivel de servicio (Service Level Objective), que serán las métricas internas de la organización para medir la calidad del servicio. Estos SLO son más exigentes que los SLA, ya que la alerta debe llegar primero a la empresa antes que el cliente lo note.
En conclusión, es necesario entender con profundidad cómo y cuándo un usuario está feliz con un servicio. Para medir la felicidad del usuario, se requiere definir métricas (SLI), construir los indicadores, documentarlos, medirlos y comprometer a toda la organización en el cumplimiento de estas promesas. Duro camino nos plantean Google y los auditores de seguridad para asegurar la
felicidad de los usuarios.
