En este documento del framework de arquitectura de Google Cloud, se definen los conceptos clave necesarios para comprender y crear objetivos de nivel de servicio (SLO).
En esencia, los SLO reflejan los objetivos de confiabilidad del servicio que proporcionas a los usuarios. Es importante incluir aportes de todas las partes interesadas fundamentales cuando definas estos objetivos. Muchos grupos y niveles de administración diferentes tienen un gran interés en tu servicio. Se incluyen propietarios de empresas, propietarios de productos, ejecutivos, ingenieros, personal de asistencia, operaciones, ventas y cualquier otro equipo asociado con el servicio.
Hay tantas formas de obtener aportes de las partes interesadas como diferentes objetivos de confiabilidad para elegir. La forma en la que eliges tus objetivos depende de ti y de tu organización en función de los requisitos, las partes interesadas y otros factores. Si bien este proceso está fuera del alcance de esta guía, un enfoque simple es crear un documento compartido que describa tus SLO y cómo los desarrollaste. Tu equipo puede iterar en el documento a medida que implementa y sigue mejorando los SLO con el tiempo.
En las siguientes secciones, se definen los distintos componentes de los SLO.
Nivel de servicio
Un nivel de servicio es una medición del rendimiento de un servicio en las tareas previstas para el usuario. Esta métrica se puede describir en términos de la satisfacción del usuario y se puede medir a través de varios métodos que dependen de las características únicas del servicio, su base de usuarios y las expectativas del usuario. En esta guía, asociamos el rendimiento con la confiabilidad del sistema.
Nivel de servicio de ejemplo: nuestros usuarios esperan que el servicio esté disponible y sea rápido.
Indicador de nivel de servicio
Un indicador de nivel de servicio (SLI) es un indicador de satisfacción de los usuarios que se puede medir de forma cuantitativa. Un indicador es similar a una línea en un gráfico que cambia con el tiempo a medida que el servicio mejora o se degrada. Para evaluar un nivel de servicio, elige un indicador que represente algún aspecto de la satisfacción del usuario. La disponibilidad es un SLI común.
SLI de ejemplo: la cantidad de solicitudes correctas en los últimos 10 minutos dividida por la cantidad de solicitudes válidas en el mismo período.
El SLI en el ejemplo es específico, está bien definido y se expresa como un valor numérico. Ese valor refleja qué tan disponible está el servicio. A través del seguimiento constante de este SLI en el tiempo, un equipo puede determinar la disponibilidad general de su servicio.
Si deseas obtener más información para elegir tus SLI, consulta Elige tus SLI.
Objetivo de nivel de servicio
El objetivo de nivel de servicio (SLO) es el rango objetivo que esperas que el servicio alcance según la medición del SLI. En el siguiente ejemplo, se usa el tiempo de respuesta, o la velocidad del servicio, como el SLI.
SLO de ejemplo: la respuesta del servicio es más rápida que 400 milisegundos (ms) para el 95% de todas las solicitudes válidas medidas durante 14 días.
En el SLO de ejemplo, el SLI es la cantidad de solicitudes más rápidas que 400 ms dividida por la cantidad de solicitudes válidas. Se realiza un seguimiento de este porcentaje durante 14 días. El objetivo es cumplir con el 95% de todas las solicitudes. Es decir, si el resultado final (el porcentaje de solicitudes que cumplen con los criterios) es superior al 95%, cumples con el SLO del servicio.
En resumen, el SLI es una medida (como la velocidad, la disponibilidad y el éxito) de tu servicio. El SLO es la expectativa de que una cantidad específica de esas mediciones (el porcentaje) alcance o supere un nivel o rango predeterminado. Cualquier elemento por debajo del nivel esperado es malo. No puedes proporcionar a tus usuarios un servicio confiable en un área específica de rendimiento.
Para obtener más información sobre cómo elegir tus SLO, consulta Elige tus SLO.
Acuerdo de nivel de servicio
El Acuerdo de Nivel de Servicio (ANS) es el contrato entre tú, el proveedor de servicios y tus clientes. Enumera los SLO que se prometen a los clientes y que estos esperarán en última instancia. El ANS también especifica qué sucede si no se cumple un SLO. Si no se cumple un SLO, el proveedor de servicios puede reembolsar dinero, proporcionar servicios con descuento o, en el caso de servicios más importantes, el incumplimiento puede dar lugar acciones legales o daños sanitarios.
Los ANS no se analizan demasiado en esta guía. Los ANS se mencionan para mejorar tu comprensión de los SLO, los SLI y el usuario.
Porcentaje de error aceptable
El valor final que se debe comprender cuando se analizan los SLO es el porcentaje o la cantidad de eventos negativos que tu servicio puede soportar antes de infringir el SLO. Este número, llamado porcentaje de error aceptable, define la cantidad de errores que tu empresa puede esperar y tolerar.
Para demostrarlo, usa la disponibilidad como el SLI (representado por un porcentaje). Tres o más “nueves” en el porcentaje indican la precisión con la que deseas medir ese SLI. En otras palabras, la cantidad de “9” expresa el porcentaje de disponibilidad.
Considera que un SLO de tres nueves es del 99.9%. Si se resta el valor de SLO del 100%, nos queda un porcentaje de error aceptable del 0.1%. Cuando se trata de la disponibilidad, un presupuesto del 0.1% es un poco menos de nueve horas al año durante las cuales el servicio no está disponible. Agregar otros nueve reduce considerablemente el porcentaje de error aceptable. Una disponibilidad del 99.99% (cuatro nueves) permite menos de una hora de tiempo de inactividad del servicio por año.
Ese tiempo de inactividad incluye solicitudes que fallan, tiempo de inactividad del servidor por fallos (falla o errores de software) o diseño (actualizaciones o pruebas), errores humanos, accidentes y muchos otros.
¿Qué sigue?
- Consulta Elige tus SLO.
- Explora otras categorías en el framework de arquitectura.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.