SRE: Measuring and Managing Reliability

Site Reliability Engineering

Measuring and Managing Reliability

Cómo los SLO lo ayudan a equilibrar el trabajo operativo y del proyecto

¿Cuál es el nivel correcto de confiabilidad para el sistema que atiende?

Para que los SLOs funcionen, todas las partes del negocio deben acordar que son una medida precisa de la experiencia de usuario y usarlos como el principal indicador para la toma de decisiones.

No cumplir con los SLOs debe tener consecuencias, entre las cuales puede ser la documentación de los errores que no permiten cumplir con la confiabilidad del sitio.

Operaciones debe intervenir en las prácticas de desarrollo.

Acuerdo de nivel de servicio (SLA)

Si estás ofreciendo un servicio y este no se cumple bien, deben haber consecuencias parciales para devolver el dinero.

Objetivos de nivel de servicio (SLO)

Debes crear umbrales para no incumplir los SLA, y notificar cuando haya una alerta.

Promesa interna, para cumplir las expectativas del cliente.

Cuando se incumplen los SLOs, es importante no tener interrupciones y eliminar riesgos de la prestación del servicio.

La prueba de felicidad

Establece que los servicios necesitan SLOs que capturen los niveles de rendimiento y disponibilidad, de forma que si apenas se alcanzan, mantendrán contacto con el cliente.

Es decir, si el servicio funciona en el límite de losSLOs, el usuario estará contento con este rendimiento.

Si se cumple o no el SLO, determina el grado de satisfacción de los clientes.

¿Cómo medimos la confiabilidad?

SLI = Indicadores de nivel de servicio

Son una medida cuantitativa, ó métrica de una experiencia de usuario.

Ejemplo: latencia

SLI =

good events/ valid events

Estableciendo objetivos de confiabilidad

Objetivos ambiciosos pero alcanzables.

Desarrollo y operaciones deben ponerse de acuerdo sobre los objetivos.

Iterar - en un intervalo de tiempo se debe revisar losSLOs y determinar si el alcance aún se ajusta a lo establecido.

¿Qué tan confiable debe ser un servicio?

¿Cuándo necesitamos hacer un presupuesto más confiable?

Presupuesto de error

Indica cuán poco confiable se permite que sea el servicio.

99.9% success = 0.1% failure

◼ Puestas en producción fallidas

◼ Mantenimiento planificado

◼ Fallos en el hardware

No hay inconvenientes en usar el presupuesto de error, el inconveniente es cuando este supera lo estipulado, se debe intervenir el servicio para que sea más confiable.

Intercambio de confiabilidad contra otra característica Cumplir los SLOs y mantener el presupuesto de error les permite a los desarrolladores tomar más riesgos y enfocarse en sacar nuevas funcionalidades, en caso contrario es mejor tener una actitud conservadora.

El equipo de operaciones debe detener las puestas en producción cuando se agota el presupuesto de error.

¿Cómo hacemos que un servicio sea más confiable?

Agregar redundancia

TTD - time-to-detect

TTR - time-to-resolution

TBF - tiempo entre fallos

Reducción de los tiempo

TTD - Agregando monitoreo

TTR - Agregando logs de eventos y procesos que permitan encontrar la causa

TBF - Hacer que sea menos probable que ocurra un fallo en particular

Author Postmortems

Métricas y medición

Se necesita medir la experiencia de usuario lo más directamente posible.

Cuantificar si el sitio no carga o es demasiado lento, a través del monitoreo. Servirá para determinar si un usuario es feliz o no. (Estas métricas cuantificables se convierten enSLIs).

Las propiedades de las buenas métricas SLI

Un buen SLI es que tenga una relación predecible con la felicidad de tus usuarios.

¿Funciona nuestro servicio como lo esperan nuestros usuarios?

Expresado como : Buenos eventos/Eventos válidos.

Se sugiere que el SLI se agregue en un periodo de tiempo razonablemente largo.

Una buena métrica, tiene una caída notable durante una interrupción, lo que permite un seguimiento preciso del rendimiento del servicio y no presenta tantas interrupciones o picos en la gráfica, si esto ocurre se debe ajustar la métrica.

Formas de medir los SLI

◼Obteniendo métricas de los registros del servidor (LOGS).

◼Métricas de servidores de aplicaciones.

◼Front-end infra metrics (balanceadores de carga frontales o del proveedor de la nube.

◼Cliente sintético.

◼Instrumentación del cliente.

SLI de uso común

SLI Menú

Solicitud/Respuesta

Disponibilidad

Latencia

Calidad

Procesamiento de datos

Covertura

Exactitud

Frescura

Rendimiento

Almacenamiento

Durabilidad

SLI de Solicitud/Respuesta

Disponibilidad

Un ejemplo de disponibilidad de una máquina virtual; minutos que estuvo en funcionamiento ósea en los que estuvo accesible por SSH.

Latencia

Se debe establecer un umbral entre el 75% y 90% de respuestas exitosas por el sistema, una forma de garantizar esto es tener una cache delante del servicio o aplicaciones que respondan en segundo plano.

Monitorizar colas de trabajo asíncronas.

Calidad

Degradar una parte del servicio, teniendo en cuenta el uso de este, por ejemplo, anuncios menos relevantes para los usuarios que a su vez reducen sus porcentajes de clics.

SLI de Procesamiento de datos

Frescura

La proporción de datos válidos que han sido actualizados más recientemente en un determinado umbral. (datos válidos/temporizador de frescura). Marca de tiempo.

Corrección

Determinar la corrección de los datos procesados.

Cobertura

La proporción de datos válidos que han sido procesados de manera exitosa.

Rendimiento

Las unidades de medida para la tasa de procesamiento de datos.

Gestión de complejidad

1 - 3SLIs - cubriendo la experiencia de usuario.

Priorizar en el caso de que sean muchasSLIs.

No eliminar por completo los sistemas de monitoreo, estos sirven para diagnosticar en el caso de que losSLIs se deterioren.

Gestión de complejidad con agregación

Sumar los datos válidos de las SLIs teniendo en cuenta la experiencia de usuario de un solo sitio que se puede dividir en categorías (agrupar los resultados de las SLIs de diferentes experiencias de usuarios que están relacionadas).

Gestión de complejidad con la

creación

de depositos Creación de categorías en donde almacenar los datos de las peticiones, un ejemplo de estas categorías serían interactivo, segundo plano y escritura.

Establecimiento de objetivos de confiabilidad

Recolectar datos históricos de los SLIs para definir losSLOs. Estos deben ser alcanzables.

SLOs aspiracionales, pueden ser basados en los requisitos y ser alcanzados con el tiempos. Basarse en hipótesis.

Iterar y realizar el feedback de los SLOs para ajustarlos.

¿Los SLI cubren los modos de falla de servicio?

Se debe monitorizar el funcionamiento o la prestación del servicio, es decir si está respondiendo la infraestructura, ya que si hay un error en la prestación del servicio las métricas de los SLIs tendrán un desfase mientras el servicio no funcionebien.Paraestoesútilusarunasonda.

Considerarlosmodosdefallodelainfraestructura.

Riesgos de confiabilidad

El rendimiento del pasado no es un indicador de la confiabilidad del futuro.

¿ El presupuesto de error es realista ?

¿ Podemos esperar gastar menos de ese presupuesto si consideramos horizontes de tiempo más largos, en años en vez de semanas o meses, cuando consideramos eventos de gran impacto en el “long-tail” ?

¿Cuáles son las mayores causas que consumen el presupuesto de error ?

¿ Hay algún problema sencillo de arreglar que pudiera permitirle a nuestro servicio tener mayores niveles de disponibilidad con menos esfuerzo de ingeniería ?

Caracterización del riesgo

Falta de tiempo

1. Tiempo de detección

2. Tiempo de resolución

3. Porcentaje de usuarios impactados

Plantilla maestra para análisis de riesgo

https://goo.gl/bnsPj7

Ejemplo Juego Riesgos

https://goo.gl/GQ4B7H

Análisis de riesgo

Por qué debería documentar su SLO: que documentar y dónde

Documentando su SLO

◼ Indicar el por qué del umbral de su SLO.

◼ Por qué los SLIs son apropiados para medir el SLO.

◼ Cualquier dato que se incluya y excluya de forma deliberada dentro de los SLIs.

SLO ciclos de refinamiento

Desarrollo, pruebas, paginación.

Debe existir un encargado o responsable de los SLOs.

Incluir la información de los metadatos correspondientes a los SLOs dentro del sistema de control de versiones es una buena práctica.

Por qué necesita una política de

presupuesto de errores

Una política de presupuesto de errores describe como tú negocio decide aumentar el trabajo de confiabilidad a cambio del trabajo de funcionalidad cuando esté SLO indica que un servicio no es lo suficientemente confiable.

Guiar a la organización en acciones significativas y apropiadas cuando la confiabilidad de tu servicio es amenazada.

Relacionar la política a varios servicios.

Cómo escribir una política de presupuesto de errores

Si el presupuesto de error está agotado o si está al borde de estarlo, una buena política de presupuesto de error habilita a los equipos de desarrollo y SRE para re-priorizar el trabajo y las características funcionales que mejoran la confiabilidad del servicio.

◼ La política de presupuesto de error debería indicar claramente cuando se ejecuta. Ejemplo: puede ser cuando se haya agotado el presupuesto semanal o cuando el presupuesto esté en riesgo de consumirse.

◼ Debe describir cómo sucede. Detallar los pormenores de la priorización.

◼ Debe incluir las consecuencias si el trabajo no se está realizando.

◼ Una bala de plata debería tener como resultado un análisis post-mortem.

◼ Documentar los nombres de las personas que toman las decisiones en momentos delicados. Puede declarar un código amarillo (El equipo de desarrollo deteniene el desarrollo de nuevas funcionalidades y dedican todo su esfuerzo a solucionar el error).

◼ Firma de todos los participantes gerentes, dueños de producto, desarrolladores y operaciones.

Referencias

https://www.coursera.org/learn/site-reliability -engineering-slos