5. Alertas sobre SLO

Por Steven Thurgood
con Jess Frame, Anthony Lenton
Carmela Quinito, Anton Tolchanov y Nejc Trdin

Este capítulo explica cómo convertir sus SLO en alertas procesables sobre eventos significativos. Tanto nuestro primer libro de SRE como este libro hablan sobre la implementación de SLOs. Creemos que tener buenos SLO que midan la fiabilidad de su plataforma, tal y como la experimentan sus clientes, proporciona la indicación de mayor calidad para saber cuándo debe responder un ingeniero de guardia. Aquí damos una orientación específica sobre cómo convertir esos SLO en reglas de alerta para que pueda responder a los problemas antes de que consuman demasiado de su presupuesto para errores.

Nuestros ejemplos presentan una serie de implementaciones cada vez más complejas para las métricas y la lógica de alerta; discutimos la utilidad y las deficiencias de cada una. Aunque nuestros ejemplos utilizan un servicio sencillo basado en solicitudes y la sintaxis de Prometheus, puede aplicar este enfoque en cualquier marco de alerta.

Consideraciones sobre alertas

Para generar alertas a partir de indicadores de nivel de servicio (SLI) y un presupuesto de errores, necesita una forma de combinar estos dos elementos en una regla específica. Su objetivo es recibir una notificación en caso de un evento significativo: un evento que consuma una gran fracción del presupuesto de errores.

Tenga en cuenta los siguientes atributos a la hora de evaluar una estrategia de alerta:

• Precisión: La proporción de eventos detectados que son significativos. La precisión es del 100% si cada alerta corresponde a un suceso significativo. Tenga en cuenta que las alertas pueden ser especialmente sensibles a los eventos no significativos durante los periodos de bajo tráfico (analizados en “Servicios de bajo tráfico y alertas de presupuesto de errores”).

• Recuperación: Proporción de eventos significativos detectados. La recuperación es del 100% si todos los eventos significativos dan lugar a una alerta.

• Tiempo de detección: El tiempo que se tarda en enviar notificaciones en distintas condiciones. Los tiempos de detección largos pueden afectar negativamente al presupuesto de errores.

• Tiempo de reinicio: Tiempo que tardan en dispararse las alertas una vez resuelto un problema. Los tiempos de restablecimiento largos pueden llevar a confusión o a que se ignoren los problemas.

La construcción de reglas de alerta para sus SLO puede llegar a ser bastante compleja. Aquí presentamos seis formas de configurar alertas sobre sucesos significativos, en orden de fidelidad creciente, para llegar a una opción que ofrezca un buen control sobre los cuatro parámetros de precisión, recuperación, tiempo de detección y tiempo de restablecimiento simultáneamente. Cada uno de los siguientes enfoques aborda un problema diferente, y algunos acaban resolviendo varios problemas al mismo tiempo. Los tres primeros intentos no viables trabajan para las tres últimas estrategias de alerta viables, siendo el enfoque 6 la opción más viable y la más recomendada. El primer método es sencillo de aplicar pero inadecuado, mientras que el método óptimo proporciona una solución completa para defender un SLO tanto a largo como a corto plazo.

A efectos de este debate, los “presupuestos de error” y las “tasas de error” se aplican a todos los SLO, no sólo a los que llevan “error” en su nombre. En la sección “Qué medir: uso de los SLI”, recomendamos utilizar SLI que capturen la proporción de eventos buenos respecto al total de eventos. El presupuesto de error da el número de eventos malos permitidos, y la tasa de error es la relación entre eventos malos y eventos totales.

Para la solución más trivial, puede elegir una ventana de tiempo pequeña (por ejemplo, 10 minutos) y alertar si la tasa de error durante esa ventana supera el SLO.

Por ejemplo, si el SLO es del 99.9% en 30 días, alerte si la tasa de error en los 10 minutos anteriores es ≥ 0.1%:

- alert: HighErrorRate \\
    expr: job:slo_errors_per_request:ratio_rate10m{job="myjob"} >= 0.001

record: job:slo_errors_per_request:ratio_rate10m
expr:
  sum(rate(slo_errors[10m])) by (job)
    /
  sum(rate(slo_requests[10m])) by (job)

record: slo_errors
expr: http_errors

Alertar cuando la tasa de error reciente es igual al SLO significa que el sistema detecta un gasto presupuestario de:

tamaño de la ventana de alerta
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
período de notificación

La Figura 5-1 muestra la relación entre el tiempo de detección y la tasa de error para un servicio de ejemplo con una ventana de alerta de 10 minutos y un SLO del 99.9%.

Figura 5-1. Tiempo de detección para un servicio de ejemplo con una ventana de alerta de 10 minutos y un SLO del 99.9

La Tabla 5-1 muestra los beneficios y desventajas de alertar cuando la tasa de error inmediato es demasiado alta.

Tabla 5-1. Ventajas e inconvenientes de la alerta cuando la tasa de error inmediata es demasiado alta

Podemos ampliar el ejemplo anterior cambiando el tamaño de la ventana de alerta para mejorar la precisión. Al aumentar el tamaño de la ventana, se gasta una cantidad mayor del presupuesto antes de activar una alerta.

Para que la tasa de alertas sea manejable, decide que sólo se le notifique si un evento consume el 5% del presupuesto de errores de 30 días, es decir, una ventana de 36 horas:

- alert: HighErrorRate
   expr: job:slo_errors_per_request:ratio_rate36h{job="myjob"} > 0.001

Ahora, el tiempo de detección es:

1−SLO error
−−−−−−−−−−−− X alerting window size
ratio

La Tabla 5-2 muestra los beneficios y desventajas de alertar cuando la tasa de error es demasiado alta en una ventana de tiempo mayor.

Tabla 5-2. Ventajas e inconvenientes de las alertas cuando la tasa de error es demasiado alta en un intervalo de tiempo mayor

La Figura 5-2 muestra que, aunque el porcentaje de error en un periodo de 36 horas ha descendido a un nivel insignificante, el porcentaje de error medio en 36 horas sigue estando por encima del umbral.

Figura 5-2. Tasa de error en un periodo de 36 horas

La mayoría de los sistemas de monitorización le permiten añadir un parámetro de duración a los criterios de alerta para que la alerta no se dispare a menos que el valor permanezca por encima del umbral durante algún tiempo. Puede verse tentado a utilizar este parámetro como una forma relativamente barata de añadir ventanas más largas:

- alert: HighErrorRate
    expr: job:slo_errors_per_request:ratio_rate1m{job="myjob"} > 0.001
    for: 1h

La Tabla 5-3 muestra las ventajas e inconvenientes de utilizar un parámetro de duración para las alertas.

Tabla 5-3. Ventajas e inconvenientes de utilizar un parámetro de duración para las alertas

Por las razones listadas en la Tabla 5-3, no recomendamos usar duraciones como parte de sus criterios de alerta basados en SLO.¹⁾

La Figura 5-3 muestra la tasa de error media en una ventana de 5 minutos de un servicio con una duración de 10 minutos antes de que se dispare la alerta. Una serie de picos de error del 100% que duran 5 minutos cada 10 minutos nunca dispara una alerta, a pesar de consumir el 35% del presupuesto de errores.

Figura 5-3. Un servicio con picos de error del 100% cada 10 minutos

Cada pico consumió casi el 12% del presupuesto de 30 días y, sin embargo, la alerta nunca saltó.

Para mejorar la solución anterior, se desea crear una alerta con un buen tiempo de detección y una gran precisión. Para ello, puede introducir una tasa de consumo para reducir el tamaño de la ventana manteniendo constante el gasto del presupuesto de alerta.

La Burn Rate es la rapidez con la que, en relación con el SLO, el servicio consume el presupuesto para errores. La Figura 5-4 muestra la relación entre las tasas de consumo y los presupuestos de error.

El servicio de ejemplo utiliza una tasa de consumo de 1, lo que significa que está consumiendo el presupuesto de errores a una tasa que lo deja con exactamente 0 presupuesto al final de la ventana de tiempo del SLO (ver Capítulo 4 de nuestro primer libro). Con un SLO del 99.9% en una ventana temporal de 30 días, una tasa de error constante del 0.1% utiliza exactamente todo el presupuesto para errores: una tasa de agotamiento de 1.

Figura 5-4. Presupuestos de error relativos a los burn rates

La Tabla 5-4 muestra las “burn rates”, sus correspondientes tasas de error y el tiempo que se tarda en agotar el presupuesto de SLO.

Tabla 5-4. “Burn rates” y tiempo hasta el agotamiento completo del presupuesto

Si se mantiene la ventana de alerta fija en una hora y se decide que un gasto presupuestario de error del 5% es lo suficientemente importante como para avisar a alguien, se puede deducir la “burn rate” a utilizar para la alerta.

Para las alertas basadas en la tasa de errores, el tiempo necesario para que se dispare una alerta es:

1−SLO error
−−−−−−−−−−−− x alerting window size x burn rate
ratio

El presupuesto de error consumido en el momento en que se dispara la alerta es:

burn rate x alerting window size
−−−−−−−−−−−−
period

El 5% de un presupuesto de error de 30 días gastado en más de una hora requiere una “burn rate” de 36. La regla de alerta pasa a ser ahora

- alert: HighErrorRate
  expr: job:slo_errors_per_request:ratio_rate1h{job="myjob"} > 36 * 0.001

La Tabla 5-5 muestra las ventajas y limitaciones de las alertas basadas en el “burn rate”.

Tabla 5-5. Ventajas y desventajas de las alertas basadas en “burn rate”

Su lógica de alerta puede utilizar múltiples burn rates y ventanas de tiempo, y disparar alertas cuando las tasas de quemado superen un umbral especificado. Esta opción conserva las ventajas de alertar sobre los porcentajes de grabación y garantiza que no se pasen por alto porcentajes de error más bajos (pero significativos).

También es una buena idea configurar notificaciones de tickets para incidentes que suelen pasar desapercibidos pero que pueden agotar su presupuesto de errores si no se controlan; por ejemplo, un consumo del 10% del presupuesto en tres días. Este índice de errores detecta incidencias importantes, pero como el índice de consumo de presupuesto proporciona tiempo suficiente para abordar la incidencia, no es necesario avisar a nadie.

Recomendamos un consumo de presupuesto del 2% en una hora y del 5% en seis horas como cifras de partida razonables para avisar a alguien, y un consumo de presupuesto del 10% en tres días como una buena referencia para las alertas de tickets. Las cifras adecuadas dependen del servicio y de la carga de páginas de referencia. Para los servicios más activos, y dependiendo de las responsabilidades de guardia durante los fines de semana y días festivos, es posible que desee alertas de tickets para la ventana de seis horas.

La Tabla 5-6 muestra las correspondientes “burn rates“ y ventanas temporales para los porcentajes del presupuesto SLO consumido.

La configuración de las alertas puede tener un aspecto similar:

expr: (
        job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4*0.001)
      or
        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > (6*0.001)
      )
severity: page

expr: job:slo_errors_per_request:ratio_rate3d{job="myjob"} > 0.001
severity: ticket

La Figura 5-5 muestra el tiempo de detección y el tipo de alerta en función de la tasa de error.

Figura 5-5. Tasa de error, tiempo de detección y notificación de alerta

Los múltiples índices de activación le permiten ajustar la alerta para darle la prioridad adecuada en función de la rapidez con la que tenga que responder. Si un problema va a agotar el presupuesto para errores en unas horas o unos días, lo apropiado es enviar una notificación activa. De lo contrario, es más apropiado enviar una notificación basada en un ticket para tratar la alerta al siguiente día laborable.²⁾

En la Tabla 5-7 se enumeran las ventajas y desventajas de utilizar varios “burn rates”

Tabla 5-7. Ventajas e inconvenientes de utilizar varios burn rates

Podemos mejorar las alertas multiventana de la iteración 5 para que sólo nos avisen cuando todavía estemos consumiendo activamente el presupuesto, reduciendo así el número de falsos positivos. Para ello, tenemos que añadir otro parámetro: una ventana más corta para comprobar si el presupuesto de error todavía se está consumiendo cuando activamos la alerta.

Una buena pauta es hacer que la ventana corta dure 1/12 de la ventana larga, como se muestra en la Figura 5-6. El gráfico muestra ambos umbrales de alerta. El gráfico muestra ambos umbrales de alerta. Después de experimentar un 15% de errores durante 10 minutos, la media de la ventana corta supera el umbral de alerta inmediatamente, y la media de la ventana larga supera el umbral después de 5 minutos, momento en el que empieza a dispararse la alerta. La media de la ventana corta cae por debajo del umbral 5 minutos después de que cesen los errores, momento en el que la alerta deja de dispararse. La media de la ventana larga cae por debajo del umbral 60 minutos después de que cesen los errores.

Figura 5-6. Ventanas cortas y largas de alerta

Por ejemplo, puede enviar una alerta a nivel de página cuando supere la tasa de consumo de 14.4 veces tanto en la hora como en los cinco minutos anteriores. Esta alerta sólo se dispara cuando se ha consumido el 2% del presupuesto, pero presenta un mejor tiempo de restablecimiento al dejar de dispararse cinco minutos después, en lugar de una hora después:

expr: (
        job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4*0.001)
      and
        job:slo_errors_per_request:ratio_rate5m{job="myjob"} > (14.4*0.001)
      )
    or
      (
        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > (6*0.001)
      and
        job:slo_errors_per_request:ratio_rate30m{job="myjob"} > (6*0.001)
      )
severity: page

expr: (
        job:slo_errors_per_request:ratio_rate24h{job="myjob"} > (3*0.001)
      and
        job:slo_errors_per_request:ratio_rate2h{job="myjob"} > (3*0.001)
      )
    or
      (
        job:slo_errors_per_request:ratio_rate3d{job="myjob"} > 0.001
      and
        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > 0.001
      )
severity: ticket

Recomendamos los parámetros listados en la Tabla 5-8 como punto de partida para su configuración de alertas basadas en SLO.

Tabla 5-8. Parámetros recomendados para una configuración de alertas SLO del 99.9%

Hemos encontrado que la alerta basada en múltiples burn rates es una forma poderosa de implementar la alerta basada en SLO.

La Tabla 5-9 muestra los beneficios y limitaciones de usar múltiples tasas de quemado y tamaños de ventana.

Tabla 5-9. Ventajas y desventajas de utilizar múltiples burn rates y tamaños de ventana

El enfoque de múltiples ventanas y múltiples tasas de respuesta que acabamos de detallar funciona bien cuando una tasa suficientemente alta de solicitudes entrantes proporciona una señal significativa cuando surge un problema. Sin embargo, estos enfoques pueden causar problemas a los sistemas que reciben un bajo índice de solicitudes. Si un sistema tiene un número bajo de usuarios o periodos naturales de poco tráfico (como las noches y los fines de semana), es posible que tenga que modificar su enfoque.

Es más difícil distinguir automáticamente los eventos sin importancia en los servicios con poco tráfico. Por ejemplo, si un sistema recibe 10 solicitudes por hora, una sola solicitud fallida supone una tasa de error por hora del 10%. Para un SLO del 99.9%, esta petición constituye una tasa de errores 1,000 veces mayor y se cancelaría inmediatamente, ya que consumiría el 13.9% del presupuesto de errores de 30 días. Este escenario permite sólo siete peticiones fallidas en 30 días. Las solicitudes individuales pueden fallar por un gran número de razones efímeras y poco interesantes que no son necesariamente rentables de resolver de la misma manera que las grandes interrupciones sistemáticas.

La mejor solución depende de la naturaleza del servicio: ¿cuál es el impacto³⁾ de una única solicitud fallida? Un objetivo de alta disponibilidad puede ser adecuado si las solicitudes fallidas son únicas, de alto valor y no se vuelven a intentar. Desde una perspectiva empresarial, puede tener sentido investigar cada solicitud fallida. Sin embargo, en este caso, el sistema de alertas notifica el error demasiado tarde.

Recomendamos algunas opciones clave para gestionar un servicio con poco tráfico:

• Generar tráfico artificial para compensar la falta de señal de los usuarios reales.

• Combinar servicios más pequeños en un servicio más grande con fines de supervisión.

• Modificar el producto para que

• Se necesiten más solicitudes para calificar una sola incidencia como fallo.

• El impacto de un único fallo sea menor.

Un sistema puede sintetizar la actividad de los usuarios para detectar posibles errores y peticiones de alta latencia. En ausencia de usuarios reales, su sistema de supervisión puede detectar errores y solicitudes sintéticos, de modo que sus ingenieros de guardia puedan responder a los problemas antes de que afecten a demasiados usuarios reales.

El tráfico artificial proporciona más señales con las que trabajar y permite reutilizar la lógica de supervisión y los valores de SLO existentes. Incluso es posible que ya disponga de la mayoría de los componentes necesarios para generar tráfico, como probadores de caja negra y pruebas de integración.

Generar carga artificial tiene algunas desventajas. La mayoría de los servicios que justifican el soporte de SRE son complejos y tienen una gran superficie de control del sistema. Idealmente, el sistema debería diseñarse y construirse para su monitorización mediante tráfico artificial. Incluso para un servicio no trivial, sólo se puede sintetizar una pequeña parte del número total de tipos de peticiones de usuario. Para un servicio con estados, el mayor número de estados agrava este problema.

Además, si un problema afecta a usuarios reales pero no afecta al tráfico artificial, las peticiones artificiales exitosas ocultan la señal del usuario real, por lo que no se le notifica que los usuarios ven errores.

Si varios servicios con poco tráfico contribuyen a una función general, la combinación de sus solicitudes en un único grupo de nivel superior puede detectar eventos significativos con mayor precisión y con menos falsos positivos. Para que este enfoque funcione, los servicios deben estar relacionados de algún modo: se pueden combinar microservicios que formen parte del mismo producto o varios tipos de solicitudes gestionadas por el mismo binario.

Una desventaja de combinar servicios es que un fallo completo de un servicio individual puede no contar como un evento significativo. Puede aumentar la probabilidad de que un fallo afecte al grupo en su conjunto eligiendo servicios con un dominio de fallo compartido, como una base de datos backend común. Aún así, puede utilizar alertas de mayor duración que acaben detectando estos fallos del 100% para servicios individuales.

Alertar sobre eventos significativos tiene como objetivo proporcionar un aviso suficiente para mitigar los problemas antes de que agoten todo el presupuesto de errores. Si no puede ajustar la supervisión para que sea menos sensible a los eventos efímeros, y la generación de tráfico sintético no es práctica, podría considerar cambiar el servicio para reducir el impacto en el usuario de una única solicitud fallida. Por ejemplo, podría:

• Modificar el cliente para que vuelva a intentarlo, con backoff exponencial y jitter.⁴⁾

• Establecer rutas de retorno que capturen la solicitud para su eventual ejecución, que puede tener lugar en el servidor o en el cliente.

Estos cambios son útiles para sistemas de alto tráfico, pero aún más para sistemas de bajo tráfico: permiten más eventos fallidos en el presupuesto de errores, más señal de monitorización y más tiempo para responder a un incidente antes de que sea significativo.

También es posible que desee reconsiderar si el impacto de un único fallo en el presupuesto de errores refleja con precisión su impacto en los usuarios. Si un pequeño número de errores le hace perder presupuesto de errores, ¿realmente necesita llamar a un ingeniero para que solucione el problema inmediatamente? Si no es así, los usuarios estarían igual de contentos con un SLO más bajo. Con un SLO más bajo, sólo se avisa a un ingeniero en caso de que se produzca una interrupción prolongada.

Una vez que haya negociado la reducción del SLO con las partes interesadas del servicio (por ejemplo, reducir el SLO del 99.9% al 99%), aplicar el cambio es muy sencillo: si ya dispone de sistemas de información, supervisión y alerta basados en un umbral SLO, sólo tiene que añadir el nuevo valor SLO a los sistemas pertinentes.

Reducir el SLO tiene un inconveniente: implica una decisión sobre el producto. Cambiar el SLO afecta a otros aspectos del sistema, como las expectativas en torno al comportamiento del sistema y cuándo aplicar la política de presupuesto de errores. Estos otros requisitos pueden ser más importantes para el producto que evitar un cierto número de alertas de señal baja.

Del mismo modo, aumentar la ventana de tiempo utilizada para la lógica de alerta garantiza que las alertas que activan las páginas sean más significativas y dignas de atención.

En la práctica, utilizamos alguna combinación de los siguientes métodos para alertar sobre servicios con poco tráfico:

• Generación de tráfico falso, cuando es posible y se puede lograr una buena cobertura.

• Modificación de los clientes para que los fallos efímeros tengan menos probabilidades de perjudicar al usuario.

• Agregación de servicios más pequeños que compartan algún modo de fallo

• Fijar umbrales de SLO proporcionales al impacto real de una solicitud fallida

Los servicios con un objetivo de disponibilidad extremadamente bajo o extremadamente alto pueden requerir una consideración especial. Por ejemplo, considere un servicio que tiene un objetivo de disponibilidad del 90%. La Tabla 5-8 dice que hay que avisar cuando se consume el 2% del presupuesto de errores en una sola hora. Como una interrupción del 100% consume sólo el 1.4% del presupuesto en esa hora, esta alerta nunca podría dispararse. Si sus presupuestos de error se establecen para largos periodos de tiempo, puede que necesite ajustar sus parámetros de alerta.

Para servicios con un objetivo de disponibilidad extremadamente alto, el tiempo hasta el agotamiento para una interrupción del 100% es extremadamente pequeño. Una interrupción del 100% para un servicio con un objetivo de disponibilidad mensual del 99.999% agotaría su presupuesto en 26 segundos, lo que es inferior al intervalo de recogida de métricas de muchos servicios de supervisión, por no hablar del tiempo de extremo a extremo para generar una alerta y transmitirla a través de sistemas de notificación como el correo electrónico y los SMS. Incluso si la alerta va directamente a un sistema de resolución automatizada, el problema puede consumir por completo el presupuesto para errores antes de que pueda mitigarlo.

Recibir notificaciones de que sólo te quedan 26 segundos de presupuesto no es necesariamente una mala estrategia; simplemente no es útil para defender el SLO. La única forma de defender este nivel de fiabilidad es diseñar el sistema de forma que la probabilidad de que se produzca una interrupción del 100% sea extremadamente baja. De ese modo, podrá solucionar los problemas antes de que se consuma el presupuesto. Por ejemplo, si inicialmente despliega ese cambio a sólo el 1% de sus usuarios, y quema su presupuesto de errores a la misma tasa del 1%, ahora tiene 43 minutos antes de agotar su presupuesto de errores. En el capítulo 16 se describen las tácticas para diseñar un sistema de este tipo.

Cuando amplíe su servicio, asegúrese de que su estrategia de alerta también sea escalable. Puede tener la tentación de especificar parámetros de alerta personalizados para servicios individuales. Si su servicio comprende 100 microservicios (o, lo que es lo mismo, un único servicio con 100 tipos de solicitudes diferentes), este escenario acumula muy rápidamente una carga de trabajo pesado y cognitivo que no es escalable.

En este caso, le recomendamos encarecidamente que no especifique los parámetros de la ventana de alerta y la tasa de activación de forma independiente para cada servicio, ya que hacerlo se convierte rápidamente en una tarea abrumadora.⁵⁾ Una vez que decida los parámetros de alerta, aplíquelos a todos sus servicios.

Una técnica para gestionar un gran número de SLOs es agrupar los tipos de peticiones en cubos de requisitos de disponibilidad aproximadamente similares. Por ejemplo, para un servicio con SLOs de disponibilidad y latencia, puede agrupar sus tipos de peticiones en los siguientes grupos:

• CRITICAL: Para tipos de solicitud que son los más importantes, como una solicitud cuando un usuario inicia sesión en el servicio.

• HIGH_FAST: Para solicitudes con requisitos de alta disponibilidad y baja latencia. Estas solicitudes implican una funcionalidad interactiva básica, como cuando un usuario pulsa un botón para ver cuánto dinero ha generado su inventario publicitario este mes.

• HIGH_SLOW: Para funciones importantes pero menos sensibles a la latencia, como cuando un usuario hace clic en un botón para generar un informe de todas las campañas publicitarias de los últimos años, y no espera que los datos se devuelvan al instante.

• LOW: Para solicitudes que deben tener cierta disponibilidad, pero para las que las interrupciones son en su mayoría invisibles para los usuarios; por ejemplo, los gestores de sondeo para notificaciones de cuentas que pueden fallar durante largos periodos de tiempo sin impacto para el usuario.

• NO_SLO:Para funcionalidad que es completamente invisible para el usuario, por ejemplo, lanzamientos oscuros o funcionalidad alfa que está explícitamente fuera de cualquier SLO.

Agrupando las peticiones en lugar de poner objetivos únicos de disponibilidad y latencia a todos los tipos de peticiones, puede agrupar las peticiones en cinco bloques, como en el ejemplo de la Tabla 5-10.

Tabla 5-10. Solicitud de bloques de clase según requisitos y umbrales de disponibilidad similares

Estos bloques proporcionan la fidelidad suficiente para proteger la felicidad del usuario, pero suponen menos trabajo que un sistema más complicado y caro de gestionar que probablemente se ajuste con mayor precisión a la experiencia del usuario.

Si establece SLO significativos, comprensibles y representados en métricas, puede configurar las alertas para notificar a una persona de guardia sólo cuando existan amenazas específicas y procesables para el presupuesto de errores.

Las técnicas para alertar sobre eventos significativos van desde alertar cuando la tasa de error supera el umbral de SLO hasta utilizar varios niveles de tasa de errores y tamaños de ventana. En la mayoría de los casos, creemos que la técnica de alerta de múltiples ventanas y tasas de grabación es el enfoque más adecuado para defender los SLO de su aplicación.

Esperamos haberle proporcionado el contexto y las herramientas necesarias para tomar las decisiones de configuración adecuadas para su propia aplicación y organización.

Volver al índice