This post is also available in English.
This post is also available in Romanian.
Si alguna vez te aventuraste en la ciudad de los SRE, es muy probable que ya hayas conocido a algunos de mis personajes favoritos: SLO, SLA y SLI. Son muy similares pero usan sombreros muy diferentes. Con sólo la última letra para cambiar, ¿quién no podría mezclarlos?
Mi bono de Navidad para ti en este artículo es guiarte a través de este tema de aventuras interminables de los SRE y aclarar un poco quién es quién. Tomándolos en orden de aparición, los SLO o los objetivos de nivel de servicio nos dicen cuál es nuestro objetivo de disponibilidad del sistema. Si usted es un SRE, probablemente no necesitará definirlos usted mismo; también necesitaría que otras partes interesadas de su empresa le ayuden a seleccionar lo que es más aconsejable y particular para su organización. La conclusión es que debe tenerlos y elegirlos en relación con los SLA con los que se comprometió su empresa. El SLA o el acuerdo de nivel de servicio promete que si su servicio está por debajo de cierto nivel de disponibilidad que usted aceptó, se pagará algún tipo de penalización. Básicamente, el cliente recupera su dinero si los SLA caen por debajo de un cierto umbral.
Por último, pero no menos importante, los SLI o indicadores de nivel de servicio son útiles ya que miden las pruebas exitosas de su sistema. Esto sucede observando el comportamiento de su servicio e indicando si su sistema ha estado ejecutándose dentro de SLO durante un intervalo de tiempo determinado.
¿No es ésta una explicación elegante? Profundicemos un poco en algo un poco más concreto.
El SLA es el acuerdo que su empresa hace con sus clientes.
Los SLO son los objetivos que su equipo debe alcanzar para cumplir los SLA.
Los SLI representan los números reales del rendimiento de su sistema.
Si tiene SLO incorrectos desde el primer momento, sus prácticas de SRE, la experiencia del cliente y el marco de DevOps básicamente se harán añicos. Necesita SLO bien definidos para cumplir el SLA con el que se comprometió su empresa y una vez que tenga los SLO definidos, también necesitará SLI bien definidos para medir el rendimiento de su sistema.
Suficiente teoría, veamos cómo se ve y se comporta un SLO malo versus uno bueno.
El objetivo de un SLO MALO:
Asegúrese de que el tiempo de actividad de la aplicación sea satisfactorio.
Métrica de un SLO MALO:
Disponibilidad
Umbral de un SLO MALO:
Intente mantener el sistema lo más activo posible.
Ventana de observación de un SLO MALO:
Seguimiento continuo sin plazo especificado.
Justificación de un SLO MALO:
Queremos que el sistema esté disponible la mayor parte del tiempo.
Ahora pasemos a un buen SLO.
El objetivo de un BUEN SLO:
Asegúrese de que el tiempo de respuesta de la API cumpla con las expectativas del usuario.
Métrica de un BUEN SLO:
Tiempo de respuesta promedio de los puntos finales de API.
Umbral de un BUEN SLO:
Mantenga un tiempo de respuesta promedio de 200 milisegundos para el 95 % de las solicitudes de API.
Ventana de observación de un BUEN SLO:
Monitoreo continuo durante un período consecutivo de 7 días.
El SLO MALO es malo porque es vago y subjetivo, carece de métricas cuantificables, tiene un umbral indefinido y no tiene ventana de observación.
Lo que hace que un SLO sea bueno: es específico y medible, está centrado en el usuario, es cuantificable y alcanzable y tiene un marco de tiempo definido.
Se distingue un SLO bien definido porque se centra en un aspecto crucial de la calidad del servicio, proporciona claridad, mensurabilidad y alineación con las expectativas del usuario, que son elementos esenciales para un monitoreo y evaluación efectivos de la confiabilidad del servicio.
Probablemente se esté preguntando cuál es la posición de Elastic en cuanto a SLO bueno y malo. ¿Cómo vamos con eso? Con la actualización 8.11 de Elasticsearch, estamos promocionando los SLOs directamente desde la interfaz de usuario, organizados como una lista de panel, que brinda al usuario un resumen rápido de lo que sucede en cada SLO.
El usuario obtiene un historial de SLI en la vista detallada de un SLO, gráficos de evolución del presupuesto de errores y alertas activas actuales. Además, los SLO se pueden configurar fácilmente a través de Kibana, en Stack Management.
Espero haberle despertado la curiosidad suficiente para intentar crear sus propios SLO y SLI en Elasticsearch y respetar plenamente sus SLA.
¡Espero que tengáis una Navidad muy agradable!