Estudios de caso de ingeniería SLO – Capítulo 3 (Libro SRE – 7 de 32)

Si bien muchos principios de SRE se formaron dentro de los muros de Google, sus principios han vivido durante mucho tiempo fuera de nuestras puertas. Muchas prácticas estándar de Google SRE se han descubierto en paralelo o han sido adoptadas por muchas otras organizaciones de la industria.

Los SLO son fundamentales para el modelo SRE. Desde que lanzamos el equipo de Ingeniería de confiabilidad del cliente (CRE), un grupo de SRE experimentados que ayudan a los clientes de Google Cloud Platform (GCP) a desarrollar servicios más confiables, casi todas las interacciones con los clientes comienzan y terminan con SLO.

Aquí presentamos dos historias, contadas por dos empresas muy diferentes, que describen sus viajes hacia la adopción de un SLO y un enfoque basado en el presupuesto de errores mientras trabajaban con el equipo de Google CRE. Para obtener una discusión más general sobre los SLO y los presupuestos de error, consulte Implementación de SLO en este libro y el Capítulo 3 de nuestro primer libro.

Historia de SLO de Evernote

por Ben McCormack, Evernote

Evernote es una aplicación multiplataforma que ayuda a personas y equipos a crear, reunir y compartir información. Con más de 220 millones de usuarios en todo el mundo, almacenamos más de 12 mil millones de piezas de información (una combinación de notas basadas en texto, archivos y adjuntos / imágenes) dentro de la plataforma. Detrás de escena, el servicio Evernote es compatible con más de 750 instancias de MySQL.

Introdujimos el concepto de SLO en Evernote como parte de una renovación tecnológica mucho más amplia destinada a aumentar la velocidad de la ingeniería al tiempo que se mantiene la calidad del servicio. Nuestras metas incluyeron:

• Mueva el enfoque de ingeniería lejos del trabajo pesado indiferenciado en los centros de datos y hacia el trabajo de ingeniería de productos que realmente interesaba a los clientes. Con ese fin, dejamos de ejecutar nuestros centros de datos físicos y nos mudamos a una nube pública.
• Revisar el modelo de trabajo de los ingenieros de software y operaciones para respaldar un aumento en la velocidad de las funciones mientras se mantiene la calidad general del servicio.
• Renueve la forma en que consideramos los SLA para asegurarnos de que nos centramos más en cómo las fallas impactan en nuestra gran base de clientes global.

Estos objetivos pueden resultar familiares para las organizaciones de muchas industrias. Si bien ningún enfoque único para realizar este tipo de cambios funcionará en todos los ámbitos, esperamos que compartir nuestra experiencia proporcione información valiosa para otras personas que enfrentan desafíos similares.

¿Por qué adoptó Evernote el modelo SRE?

Al comienzo de esta transición, Evernote se caracterizaba por una división tradicional de operaciones / desarrollo: un equipo de operaciones protegía la santidad del entorno de producción, mientras que un equipo de desarrollo tenía la tarea de desarrollar nuevas funciones de productos para los clientes. Estos objetivos generalmente estaban en conflicto: el equipo de desarrollo se sentía limitado por los largos requisitos operativos, mientras que el equipo de operaciones se frustraba cuando el nuevo código introducía nuevos problemas en la producción. Mientras nos movíamos violentamente entre estos dos objetivos, los equipos de operaciones y desarrollo desarrollaron una relación frustrada y tensa. Queríamos llegar a un medio más feliz que equilibrara mejor las distintas necesidades de los equipos involucrados.

Intentamos abordar las lagunas en esta dicotomía tradicional de varias maneras en el transcurso de más de cinco años. Después de probar un modelo de “Usted lo escribió, usted lo ejecuta” (desarrollo) y un modelo de “Usted lo escribió, nosotros lo ejecutamos por usted” (operaciones), avanzamos hacia un enfoque SRE centrado en SLO.

Entonces, ¿qué motivó a Evernote a moverse en esta dirección?

En Evernote, vemos las disciplinas centrales de operaciones y desarrollo como pistas profesionales independientes en las que los ingenieros pueden especializarse. Un tema se refiere a la entrega continua de un servicio a los clientes, casi las 24 horas del día, los 7 días de la semana. El otro tiene que ver con la extensión y evolución de ese servicio para satisfacer las necesidades del cliente en el futuro. Estas dos disciplinas se han acercado en los últimos años a medida que movimientos como SRE y DevOps enfatizan el desarrollo de software aplicado a las operaciones. (Esta convergencia se ha visto favorecida por los avances en la automatización de los centros de datos y el crecimiento de las nubes públicas, los cuales nos brindan un centro de datos que puede ser controlado completamente por software). En el otro lado del espectro, la propiedad de la pila completa y la implementación continua están cada vez más aplicado al desarrollo de software.

Nos atrajo el modelo SRE porque abarca y acepta plenamente las diferencias entre operaciones y desarrollo, al tiempo que anima a los equipos a trabajar hacia un objetivo común. No intenta transformar a los ingenieros de operaciones en desarrolladores de aplicaciones, o viceversa. En cambio, les da a ambos un marco de referencia común. En nuestra experiencia, un enfoque de presupuesto de error / SLO ha llevado a ambos equipos a tomar decisiones similares cuando se les presentan los mismos hechos, ya que elimina una gran cantidad de subjetividad de la conversación.

Introducción de SLO: un viaje en progreso

La primera parte de nuestro viaje fue el cambio de los centros de datos físicos a Google Cloud Platform. 1 Una vez que el servicio Evernote estuvo en funcionamiento en GCP y se estabilizó, presentamos SLO. Nuestros objetivos aquí eran dos:

• Alinee los equipos internamente en torno a los SLO de Evernote, asegurándose de que todos los equipos estuvieran trabajando dentro del nuevo marco.
• Incorporar el SLO de Evernote en la forma en que trabajamos con el equipo de Google Cloud, que ahora era responsable de nuestra infraestructura subyacente. Dado que ahora teníamos un nuevo socio dentro del modelo general, necesitábamos asegurarnos de que el cambio a GCP no diluyera ni enmascarara nuestro compromiso con nuestros usuarios.

Después de usar activamente SLO durante unos nueve meses, ¡Evernote ya está en la versión 3 de su práctica SLO!

Antes de entrar en los detalles técnicos de un SLO, es importante comenzar la conversación desde el punto de vista de sus clientes: ¿qué promesas está tratando de cumplir? Al igual que la mayoría de los servicios, Evernote tiene muchas funciones y opciones que nuestros usuarios utilizan de diversas formas creativas. Queríamos asegurarnos de que inicialmente nos enfocamos en la necesidad más importante y común del cliente: la disponibilidad del servicio Evernote para que los usuarios accedan y sincronicen su contenido en múltiples clientes . Nuestro viaje de SLO comenzó con ese objetivo. Mantuvimos nuestra primera pasada simple al enfocarnos en el tiempo de actividad. Usando este primer enfoque simple, pudimos articular claramente lo que estábamos midiendo y cómo.

Nuestro primer documento de SLO contenía lo siguiente:

Una definición de los SLO

• Esta fue una medida de tiempo de actividad: 99,95% de tiempo de actividad medido en una ventana mensual, establecido para ciertos servicios y métodos. Elegimos este número en función de las discusiones con nuestros equipos internos de atención al cliente y productos y, lo que es más importante, los comentarios de los usuarios. Elegimos deliberadamente vincular nuestros SLO a un mes calendario en lugar de un período continuo para mantenernos enfocados y organizados cuando realizamos revisiones de servicios.

Que medir y como medirlo

• Que medir
• • Especificamos un punto final de servicio al que podíamos llamar para probar si el servicio funcionaba como se esperaba. En nuestro caso, tenemos una página de estado integrada en nuestro servicio que ejercita la mayor parte de nuestra pila y devuelve un código de estado 200 si todo está bien.

• Cómo medir

• • Queríamos un prober que llamara periódicamente a la página de estado. Queríamos que ese prober estuviera ubicado completamente fuera de nuestro entorno e independiente de él para poder probar todos nuestros componentes, incluida nuestra pila de equilibrio de carga. Nuestro objetivo aquí era asegurarnos de que estábamos midiendo todas y cada una de las fallas tanto del servicio GCP como de la aplicación Evernote. Sin embargo, no queríamos que los problemas aleatorios de Internet desencadenaran falsos positivos. Elegimos utilizar una empresa de terceros que se especializa en la construcción y ejecución de estos sondeos. Seleccionamos Pingdom , pero hay muchos otros en el mercado. Realizamos nuestras mediciones de la siguiente manera:
  • • Frecuencia de la sonda: sondeamos nuestros nodos frontend cada minuto.
  • Ubicación de las sondas: este ajuste es configurable; Actualmente utilizamos múltiples sondas en América del Norte y Europa.
  • Definición de “inactivo”: si una comprobación de sonda falla, el nodo se marca como inactivo no confirmado y luego un segundo palpador geográficamente separado realiza una comprobación. Si la segunda verificación falla, el nodo se marca hacia abajo para fines de cálculo de SLO. El nodo seguirá marcado como inactivo siempre que las solicitudes de sondeo consecutivas registren errores.

Cómo calcular SLO a partir de datos de seguimiento

• Finalmente, documentamos cuidadosamente cómo calculamos el SLO a partir de los datos sin procesar que recibimos de Pingdom. Por ejemplo, especificamos cómo contabilizar las ventanas de mantenimiento: no podíamos asumir que todos nuestros cientos de millones de usuarios conocían nuestras ventanas de mantenimiento publicadas. Por lo tanto, los usuarios desinformados experimentarían estas ventanas como un tiempo de inactividad genérico e inexplicable, por lo que nuestros cálculos de SLO trataron el mantenimiento como un tiempo de inactividad.

Una vez que definimos nuestros SLO, teníamos que hacer algo con ellos. Queríamos que los SLO impulsaran cambios de software y operaciones que hicieran felices a nuestros clientes y los mantuvieran felices. ¿Cuál es la mejor manera de hacer esto?

Usamos el concepto de SLO / presupuesto de error como un método para asignar recursos en el futuro. Por ejemplo, si no cumplimos con el SLO del mes pasado, ese comportamiento nos ayuda a priorizar las correcciones, mejoras y correcciones de errores relevantes. Lo mantenemos simple: los equipos de Evernote y Google realizan una revisión mensual del rendimiento de SLO. En esta reunión, revisamos el desempeño de SLO del mes anterior y realizamos un análisis profundo de las interrupciones. Con base en este análisis del mes pasado, establecemos elementos de acción para mejoras que pueden no haber sido capturadas a través del proceso regular de análisis de causa raíz.

A lo largo de este proceso, nuestro principio rector ha sido “Lo perfecto es enemigo de lo bueno”. Incluso cuando los SLO no son perfectos, son lo suficientemente buenos para orientar las mejoras a lo largo del tiempo. Un SLO “perfecto” sería uno que mide cada posible interacción del usuario con nuestro servicio y da cuenta de todos los casos extremos. Si bien esta es una gran idea en papel, tomaría muchos meses lograrla (si lograr la perfección fuera posible), tiempo que podríamos utilizar para mejorar el servicio. En su lugar, seleccionamos un SLO inicial que cubría la mayoría, pero no todas, las interacciones del usuario, que era un buen indicador de la calidad del servicio.

Desde que comenzamos, hemos revisado nuestros SLO dos veces, de acuerdo con las señales de nuestras revisiones internas del servicio y en respuesta a las interrupciones que afectan al cliente. Debido a que no pretendíamos lograr SLO perfectos desde el principio, nos sentíamos cómodos haciendo cambios para alinearnos mejor con el negocio. Además de nuestra revisión mensual de Evernote / Google sobre el rendimiento de SLO, nos hemos decidido por un ciclo de revisión de SLO de seis meses, que logra el equilibrio adecuado entre cambiar los SLO con demasiada frecuencia y dejar que se vuelvan obsoletos. Al revisar nuestros SLO, también hemos aprendido que es importante equilibrar lo que le gustaría medir con lo que es posible medir.

Desde la introducción de los SLO, la relación entre nuestras operaciones y los equipos de desarrollo ha mejorado sutil pero notablemente. Los equipos ahora tienen una medida común de éxito: eliminar la interpretación humana de la calidad de servicio (QoS) ha permitido que ambos equipos mantengan la misma visión y estándares. Para proporcionar solo un ejemplo, los SLO proporcionaron un terreno común cuando tuvimos que facilitar múltiples lanzamientos en una línea de tiempo comprimida en 2017. Si bien perseguimos un error complejo, el desarrollo del producto solicitó que distribuyéramos nuestro lanzamiento semanal normal en múltiples ventanas separadas, cada una de las cuales que potencialmente impactaría a los clientes. Al aplicar un cálculo de SLO al problema y eliminar la subjetividad humana del escenario, pudimos cuantificar mejor el impacto en el cliente y reducir nuestras ventanas de lanzamiento de cinco a dos para minimizar el dolor del cliente.

Derribando el muro de SLO entre el cliente y el proveedor de la nube

Un muro virtual entre las preocupaciones del cliente y el proveedor de la nube puede parecer natural o inevitable. Si bien Google tiene SLO y SLA (acuerdos de nivel de servicio) para las plataformas de GCP en las que ejecutamos Evernote, Evernote tiene sus propios SLO y SLA. No siempre se espera que dos equipos de ingeniería de este tipo estén informados sobre los SLA de cada uno.

Evernote nunca quiso un muro así. Por supuesto, podríamos haber diseñado una pared divisoria, basando nuestros SLO y SLA en las métricas de GCP subyacentes. En cambio, desde el principio, queríamos que Google entendiera qué características de rendimiento eran más importantes para nosotros y por qué. Queríamos alinear los objetivos de Google con los nuestros, y que ambas empresas vieran los éxitos y fracasos de confiabilidad de Evernote como responsabilidades compartidas. Para lograr esto, necesitábamos una forma de:

• Alinear objetivos
• Asegúrese de que nuestro socio (en este caso, Google) realmente comprenda lo que es importante para nosotros
• Comparta tanto los éxitos como los fracasos

La mayoría de los proveedores de servicios gestionan los SLO / SLA publicados para sus servicios en la nube. Trabajar dentro de este contexto es importante, pero no puede representar de manera integral qué tan bien se está ejecutando nuestro servicio dentro del entorno del proveedor de la nube.

Por ejemplo, un proveedor de nube determinado probablemente ejecute cientos de miles de máquinas virtuales en todo el mundo, que administran para garantizar el tiempo de actividad y la disponibilidad. GCP promete una disponibilidad del 99,95% para Compute Engine (es decir, sus máquinas virtuales). Incluso cuando los gráficos de GCP SLO son verdes (es decir, por encima del 99,95%), la visión de Evernote del mismo SLO puede ser muy diferente: debido a que nuestra huella de máquina virtual es solo un pequeño porcentaje del número global de GCP, interrupciones aisladas en nuestra región (o aisladas por otras razones) pueden “perderse” en el resumen general a un nivel global.

Para corregir escenarios como este, compartimos nuestro SLO y el rendimiento en tiempo real contra SLO con Google. Como resultado, tanto el equipo CRE de Google como Evernote trabajan con los mismos paneles de rendimiento. Esto puede parecer un punto muy simple, pero ha demostrado ser una forma bastante poderosa de impulsar un comportamiento verdaderamente centrado en el cliente. Como resultado, en lugar de recibir notificaciones genéricas de tipo “El servicio X se está ejecutando lento”, Google nos proporciona notificaciones que son más específicas de nuestro entorno. Por ejemplo, además de un genérico “El entorno de equilibrio de carga de GCP funciona con lentitud hoy”, también se nos informará que este problema está causando un impacto del 5% en el SLO de Evernote. Esta relación también ayuda a los equipos dentro de Google, quienes pueden ver cómo sus acciones y decisiones impactan a los clientes.

Esta relación bidireccional también nos ha proporcionado un marco muy eficaz para respaldar incidentes importantes. La mayoría de las veces, el modelo habitual de tickets P1 – P5 y los canales de soporte habituales funciona bien y nos permite mantener un buen servicio y una buena relación con Google. Pero todos sabemos que hay momentos en los que un ticket P1 (“gran impacto en nuestro negocio”) no es suficiente, momentos en los que todo su servicio está en juego y usted enfrenta un impacto comercial extendido.

En momentos como estos, nuestros SLO compartidos y nuestra relación con el equipo de CRE se hacen realidad. Tenemos un entendimiento común de que si el impacto de SLO es lo suficientemente alto, ambas partes tratarán el problema como un ticket P1 con un manejo especial. Muy a menudo, esto significa que Evernote y el equipo CRE de Google se movilizan rápidamente en un puente de conferencia compartido. El equipo de Google CRE monitorea el SLO que definimos y acordamos conjuntamente, lo que nos permite estar sincronizados en términos de priorización y respuestas adecuadas.

Estado actual

Después de usar activamente SLO durante unos nueve meses, Evernote ya está en la versión 3 de su práctica SLO. La próxima versión de SLO progresará desde nuestro SLO de tiempo de actividad simple. Planeamos comenzar a sondear las llamadas API individuales y tener en cuenta la vista en el cliente de las métricas / rendimiento para poder representar la QoS del usuario aún mejor.

Al proporcionar una forma estándar y definida de medir la QoS, los SLO han permitido a Evernote enfocarse mejor en cómo se está ejecutando nuestro servicio. Ahora podemos tener conversaciones basadas en datos, tanto internamente como con Google, sobre el impacto de las interrupciones, lo que nos permite impulsar mejoras en el servicio y, en última instancia, generar equipos de soporte más efectivos y clientes más felices.

La historia de SLO de The Home Depot

por William Bonnell, The Home Depot

The Home Depot (THD) es el minorista de mejoras para el hogar más grande del mundo: tenemos más de 2,200 tiendas en América del Norte, cada una con más de 35,000 productos únicos (y complementados con más de 1.5 millones de productos en línea). Nuestra infraestructura aloja una variedad de aplicaciones de software que dan soporte a casi 400.000 asociados y procesan más de 1.500 millones de transacciones de clientes al año. Las tiendas están profundamente integradas con una cadena de suministro global y un sitio web de comercio electrónico que recibe más de 2 mil millones de visitas al año.

En una actualización reciente de nuestro enfoque de operaciones con el objetivo de aumentar la velocidad y la calidad de nuestro desarrollo de software, THD giró hacia el desarrollo de software ágil y cambió la forma en que diseñamos y administramos nuestro software. Pasamos de equipos de soporte centralizados que admitían paquetes de software grandes y monolíticos a una arquitectura de microservicios dirigida por equipos de desarrollo de software pequeños y operados de forma independiente. Como resultado, nuestro sistema ahora tenía trozos más pequeños de software en constante cambio, que también debían integrarse en toda la pila.

Nuestro cambio a los microservicios se complementó con un cambio hacia una nueva “cultura de libertad y responsabilidad” de propiedad completa. Este enfoque brinda a los desarrolladores la libertad de enviar código cuando lo deseen, pero también los hace responsables conjuntamente de las operaciones de su servicio. Para que este modelo de propiedad conjunta funcione, los equipos de operaciones y desarrollo deben hablar un lenguaje común que promueva la responsabilidad y atraviese la complejidad: los objetivos de nivel de servicio. Los servicios que dependen unos de otros necesitan conocer información como:

• ¿Qué tan confiable es su servicio? ¿Está construido para tres nueves, tres nueves y medio o cuatro nueves (o mejor)? ¿Hay un tiempo de inactividad planificado?
• ¿Qué tipo de latencia puedo esperar en los límites superiores?
• ¿Pueden manejar el volumen de solicitudes que voy a enviar? ¿Cómo maneja la sobrecarga? ¿Su servicio ha logrado sus SLO con el tiempo?

Si cada servicio pudiera brindar respuestas transparentes y consistentes a estas preguntas, los equipos tendrían una visión clara de sus dependencias, lo que permite una mejor comunicación y una mayor confianza y responsabilidad entre los equipos.

El proyecto de cultura SLO

Antes de comenzar este cambio en nuestro modelo de servicio, The Home Depot no tenía una cultura de SLO. Las herramientas de monitoreo y los paneles de control eran abundantes, pero estaban dispersos por todas partes y no rastreaban los datos a lo largo del tiempo. No siempre pudimos identificar el servicio en la raíz de una interrupción determinada. A menudo, comenzamos a solucionar problemas en el servicio de atención al usuario y trabajamos hacia atrás hasta encontrar el problema, perdiendo innumerables horas. Si un servicio requería un tiempo de inactividad planificado, sus servicios dependientes se sorprendían. Si un equipo necesitara construir un servicio de tres nueves y medio, no sabría si el servicio del que tenían una fuerte dependencia podría respaldarlos con un tiempo de actividad aún mejor (cuatro nueves). Estas desconexiones causaron confusión y decepción entre nuestros equipos de operaciones y desarrollo de software.

Necesitábamos abordar estas desconexiones mediante la construcción de una cultura común de SLO. Hacerlo requería una estrategia global para influir en las personas, los procesos y la tecnología. Nuestros esfuerzos abarcaron cuatro áreas generales:

Vernáculo común

• Defina SLO en el contexto de THD. Defina cómo medirlos de forma coherente.

Evangelización

• Haga correr la voz en toda la empresa.
• • Cree material de capacitación para vender por qué son importantes los SLO, programas itinerantes en toda la empresa, blogs internos y materiales promocionales como camisetas y calcomanías.
  • Reclute a algunos de los primeros usuarios para implementar SLO y demostrar el valor a los demás.
  • Establezca un acrónimo pegadizo (VALET; como se explica más adelante) para ayudar a difundir la idea.
  • Cree un programa de capacitación (Academia FiRE: Fundamentos en ingeniería de confiabilidad) para capacitar a los desarrolladores en SLO y otros conceptos de confiabilidad. 2

Automatización

• Para reducir la fricción de la adopción, implemente una plataforma de recopilación de métricas para recopilar automáticamente indicadores de nivel de servicio para cualquier servicio implementado en producción. Posteriormente, estos SLI se pueden convertir más fácilmente en SLO.

Incentivo

• Establezca metas anuales para que todos los gerentes de desarrollo establezcan y midan SLO para sus servicios.

Establecer una lengua vernácula común fue fundamental para que todos estuvieran en la misma página. También queríamos mantener este marco lo más simple posible para ayudar a que la idea se extendiera más rápido. Para comenzar, analizamos críticamente las métricas que monitoreamos en nuestros diversos servicios y descubrimos algunos patrones. Cada servicio monitoreaba alguna forma de su volumen de tráfico , latencia , errores y utilización, métricas que se relacionan estrechamente con las Cuatro Señales Doradas de Google SRE . Además, muchos servicios monitoreaban el tiempo de actividad o la disponibilidad de manera distinta a los errores. Desafortunadamente, en general, todas las categorías de métricas se monitorearon de manera inconsistente, se nombraron de manera diferente o tenían datos insuficientes.

Ninguno de nuestros servicios tenía SLO. La métrica más cercana que tenían nuestros sistemas de producción a un SLO de cara al cliente eran los tickets de soporte. La forma principal (y a menudo única) en la que medimos la confiabilidad de las aplicaciones implementadas en nuestras tiendas fue rastreando la cantidad de llamadas de soporte que recibe nuestro servicio de soporte interno.

Nuestro primer conjunto de SLO

No pudimos crear SLO para todos los aspectos de nuestros sistemas que pudieran medirse, por lo que tuvimos que decidir qué métricas o SLI también deberían tener SLO.

Disponibilidad y latencia para llamadas a API

Decidimos que cada microservicio tenía que tener SLO de disponibilidad y latencia para sus llamadas a API que fueron llamadas por otros microservicios. Por ejemplo, el microservicio Cart se denomina microservicio de inventario. Para esas llamadas a la API, el microservicio de Inventario publicó SLO que el microservicio de Cart (y otros microservicios que necesitaban Inventario) podían consultar para determinar si el microservicio de Inventario podía cumplir con sus requisitos de confiabilidad.

Utilización de la infraestructura

Los equipos de THD miden la utilización de la infraestructura de diferentes formas, pero la medida más típica es la utilización de la infraestructura en tiempo real con una granularidad de un minuto. Decidimos no establecer SLO de utilización por varias razones. Para empezar, los microservicios no están demasiado preocupados con esta métrica; a sus usuarios realmente no les importa la utilización siempre que pueda manejar el volumen de tráfico, su microservicio esté funcionando, esté respondiendo rápidamente, no arroje errores, y usted ‘ no está en peligro de quedarse sin capacidad. Además, nuestro inminente cambio a la nube significaba que la utilización sería una preocupación menor, por lo que la planificación de costos eclipsaría la planificación de la capacidad. (Todavía necesitaríamos monitorear la utilización y realizar la planificación de la capacidad, pero no necesitamos incluirlo en nuestro marco de SLO).

Volumen de tráfico

Debido a que THD aún no tenía una cultura de planificación de la capacidad, necesitábamos un mecanismo para que los equipos de software y operaciones comunicaran cuánto volumen podía manejar su servicio. El tráfico era fácil de definir como solicitudes a un servicio, pero teníamos que decidir si debíamos realizar un seguimiento de las solicitudes promedio por segundo, las solicitudes máximas por segundo o el volumen de solicitudes durante el período de tiempo del informe. Decidimos realizar un seguimiento de los tres y dejar que cada servicio seleccione la métrica más adecuada. Debatimos si establecer o no un SLO para el volumen de tráfico porque esta métrica está determinada por el comportamiento del usuario, más que por factores internos que podemos controlar. En última instancia, decidimos que, como minoristas, necesitábamos ajustar el tamaño de nuestro servicio para picos como el Black Friday, por lo que establecimos un SLO de acuerdo con la capacidad máxima esperada.

Latencia

Dejamos que cada servicio defina su SLO de latencia y determinamos dónde medirlo mejor. Nuestra única solicitud fue que un servicio complementara nuestro monitoreo de rendimiento común de caja blanca con monitoreo de caja negra para detectar problemas causados por la red u otras capas como cachés y proxies que fallan fuera del microservicio. También decidimos que los percentiles eran más apropiados que los promedios aritméticos. Como mínimo, los servicios debían alcanzar una meta del percentil 90; Los servicios orientados al usuario tenían un objetivo preferido del percentil 95 y / o 99.

Errores

Los errores eran algo complicados de explicar. Dado que estábamos tratando principalmente con servicios web, tuvimos que estandarizar qué constituye un error y cómo devolver errores. Si un servicio web encontró un error, naturalmente estandarizamos los códigos de respuesta HTTP:

• Un servicio no debe indicar un error en el cuerpo de una respuesta 2xx; más bien, debería arrojar un 4xx o un 5xx.
• Un error causado por un problema con el servicio (por ejemplo, falta de memoria) debería generar un error 5xx.
• Un error causado por el cliente (por ejemplo, enviar una solicitud con formato incorrecto) debería generar un error 4xx.

Después de mucha deliberación, decidimos rastrear los errores 4xx y 5xx, pero usamos errores 5xx solo para establecer SLO. De manera similar a nuestro enfoque para otros elementos relacionados con SLO, mantuvimos esta dimensión genérica para que diferentes aplicaciones pudieran aprovecharla para diferentes contextos. Por ejemplo, además de los errores HTTP, los errores de un servicio de procesamiento por lotes pueden ser el número de registros que no se pudieron procesar.

Entradas

Como se mencionó anteriormente, los tickets fueron originalmente la forma principal en la que evaluamos la mayor parte de nuestro software de producción. Por razones históricas, decidimos seguir rastreando tickets junto con nuestros otros SLO. Puede considerar esta métrica como análoga a algo como “nivel de operación del software”.

AYUDANTE DE CÁMARA

Resumimos nuestros nuevos SLO en un acrónimo útil: VALET.

Volumen (tráfico)

• ¿Cuánto volumen de negocio puede manejar mi servicio?

Disponibilidad

• ¿Está activo el servicio cuando lo necesito?

Latencia

• ¿El servicio responde rápido cuando lo uso?

Errores

• ¿El servicio arroja un error cuando lo uso?

Entradas

• ¿El servicio requiere intervención manual para completar mi solicitud?

Evangelización de SLO

Armados con un acrónimo fácil de recordar, nos propusimos evangelizar los SLO a la empresa:

• Por qué los SLO son importantes
• Cómo los SLO apoyan nuestra cultura de “libertad y responsabilidad”
• Que se debe medir
• Que hacer con los resultados

Dado que los desarrolladores ahora eran responsables de la operación de su software, necesitaban establecer SLO para demostrar su capacidad para construir y respaldar software confiable, y también para comunicarse con los consumidores de sus servicios y los gerentes de productos para los servicios de cara al cliente. Sin embargo, la mayoría de esta audiencia no estaba familiarizada con conceptos como SLA y SLO, por lo que necesitaban ser educados sobre este nuevo marco VALET.

Como necesitábamos asegurar el respaldo ejecutivo para nuestro cambio a SLO, nuestra campaña de educación comenzó con el liderazgo senior. Luego nos reunimos con los equipos de desarrollo uno por uno para defender los valores de los SLO. Alentamos a los equipos a pasar de sus mecanismos personalizados de seguimiento de métricas (que a menudo eran manuales) al marco de VALET. Para mantener el impulso, enviamos un informe SLO semanal en formato VALET, que combinamos con comentarios sobre conceptos generales de confiabilidad y lecciones aprendidas de eventos internos, a la alta dirección. Esto también ayudó a enmarcar métricas comerciales como las órdenes de compra creadas (Volumen) o las órdenes de compra que no se procesaron (Errores) en términos de VALET.

También escalamos nuestro evangelismo de varias maneras:

• Creamos un sitio interno de WordPress para alojar blogs sobre VALET y confiabilidad, con enlaces a recursos útiles.
• Realizamos charlas técnicas internas (incluido un orador invitado de Google SRE) para discutir conceptos generales de confiabilidad y cómo medir con VALET.
• Llevamos a cabo una serie de talleres de formación de VALET (que luego se convertirían en FiRE Academy) y abrimos la invitación a quienes quisieran asistir. La asistencia a estos talleres se mantuvo fuerte durante varios meses.
• Incluso creamos pegatinas y camisetas para portátiles VALET para respaldar una campaña de marketing interna integral.

Pronto, todos en la empresa conocieron VALET y nuestra nueva cultura de SLO comenzó a afianzarse. La implementación de SLO incluso comenzó a incluirse oficialmente en las revisiones de desempeño anuales de THD para los gerentes de desarrollo. Si bien aproximadamente 50 servicios capturaban e informaban regularmente sobre sus SLO semanalmente, estábamos almacenando las métricas ad hoc en una hoja de cálculo. Aunque la idea de VALET se había extendido como la pólvora, necesitábamos automatizar la recopilación de datos para fomentar una adopción generalizada.

Automatización de la recopilación de datos de VALET

Si bien nuestra cultura de SLO ahora tiene una base sólida, la automatización de la recopilación de datos de VALET aceleraría la adopción de SLO.

Informes TPS

Creamos un marco para capturar automáticamente los datos de VALET para cualquier servicio que se implementó en nuestro nuevo entorno de GCP. A este marco lo llamamos TPS Reports , un juego con el término que usamos para las pruebas de volumen y rendimiento (transacciones por segundo) y, por supuesto, para burlarnos 3 de la idea de que varios gerentes podrían querer revisar estos datos. Creamos el marco de trabajo de TPS Reports sobre la plataforma de base de datos BigQuery de GCP. Todos los registros generados por nuestra interfaz de servicio web se enviaron a BigQuery para que los procese TPS Reports. Finalmente, también incluimos métricas de una variedad de otros sistemas de monitoreo, como la sonda de disponibilidad de Stackdriver.

TPS Reports transformó estos datos en métricas VALET por hora que cualquiera podría consultar. Los servicios recién creados se registraron automáticamente en los informes de TPS y, por lo tanto, se pudieron consultar de inmediato. Dado que todos los datos se almacenaron en BigQuery, pudimos informar de manera eficiente sobre las métricas de VALET a lo largo de los períodos de tiempo. Usamos estos datos para crear una variedad de informes y alertas automatizados. La integración más interesante fue un chatbot que nos permitía informar directamente sobre los servicios de VALET en una plataforma de chat comercial. Por ejemplo, cualquier servicio podría mostrar VALET durante la última hora, VALET frente a la semana anterior, servicios fuera de SLO y una variedad de otros datos interesantes directamente dentro del canal de chat.

Servicio VALET

Nuestro siguiente paso fue crear una aplicación VALET para almacenar e informar sobre los datos SLO. Debido a que los SLO se aprovechan mejor como una herramienta de tendencias, el servicio realiza un seguimiento de los SLO con granularidad diaria, semanal y mensual. Tenga en cuenta que nuestros SLO son una herramienta de tendencias que podemos usar para presupuestos de error, pero no están directamente conectados a nuestros sistemas de monitoreo. En cambio, tenemos una variedad de plataformas de monitoreo dispares, cada una con sus propias alertas. Esos sistemas de monitoreo agregan sus SLO a diario y se publican en el servicio VALET para determinar las tendencias. La desventaja de esta configuración es que los umbrales de alerta establecidos en los sistemas de monitoreo no están integrados con los SLO; sin embargo, tenemos la flexibilidad de cambiar los sistemas de monitoreo según sea necesario.

Anticipándonos a la necesidad de integrar VALET con otras aplicaciones que no se ejecutan en GCP, creamos una capa de integración VALET que proporciona una API para recopilar datos VALET agregados para un servicio diariamente. TPS Reports fue el primer sistema en integrarse con el servicio VALET y, finalmente, nos integramos con una variedad de plataformas de aplicaciones locales (más de la mitad de los servicios registrados en VALET).

Tablero de VALET

El Tablero de VALET (que se muestra en la Figura 3-1 ) es nuestra interfaz de usuario para visualizar e informar sobre estos datos y es relativamente sencillo. Permite a los usuarios:

• Registre un nuevo servicio. Por lo general, esto significa asignar el servicio a una o más URL, que pueden tener ya datos de VALET recopilados.
• Establezca objetivos SLO para cualquiera de las cinco categorías de VALET.
• Agregue nuevos tipos de métricas en cada una de las categorías de VALET. Por ejemplo, un servicio puede rastrear la latencia en el percentil 99, mientras que otro rastrea la latencia en el percentil 90 (o ambos). O, un sistema de procesamiento de backend puede rastrear el volumen a nivel diario (órdenes de compra creadas en un día), mientras que un frontend de servicio al cliente puede rastrear las transacciones pico por segundo.

El Tablero de VALET permite a los usuarios informar sobre los SLO para muchos servicios a la vez, y dividir y dividir los datos en una variedad de formas. Por ejemplo, un equipo puede ver las estadísticas de todos sus servicios que no cumplieron con el SLO en la última semana. Un equipo que busca revisar el desempeño del servicio puede ver la latencia en todos sus servicios y los servicios de los que dependen. El Tablero de VALET almacena los datos en una simple base de datos de Cloud SQL, y los desarrolladores utilizan una popular herramienta de informes comerciales para crear informes.

Estos informes se convirtieron en la base de una nueva práctica recomendada con los desarrolladores: revisiones regulares de SLO de sus servicios (normalmente, semanal o mensual). Con base en estas revisiones, los desarrolladores pueden crear elementos de acción para devolver un servicio a su SLO, o quizás decidir que un SLO poco realista necesita ser ajustado.

Figura 3-1. El tablero de VALET

La proliferación de SLO

Una vez que los SLO se cimentaron firmemente en la mente colectiva de la organización y se dispusieron los informes y la automatización efectivos, los nuevos SLO proliferaron rápidamente. Después de realizar un seguimiento de los SLO de unos 50 servicios a principios de año, a finales de año estábamos realizando un seguimiento de los SLO de 800 servicios, registrándose unos 50 nuevos servicios por mes en VALET.

Debido a que VALET nos permitió escalar la adopción de SLO en THD, el esfuerzo de tiempo requerido para desarrollar la automatización valió la pena. Sin embargo, otras empresas no deberían tener miedo de adoptar un enfoque basado en SLO si no pueden desarrollar una automatización igualmente compleja. Si bien la automatización proporcionó beneficios adicionales a THD, existen beneficios al escribir SLO en primer lugar.

Aplicación de VALET a aplicaciones por lotes

A medida que desarrollamos informes sólidos sobre los SLO, descubrimos algunos usos adicionales para VALET. Con un pequeño ajuste, las aplicaciones por lotes pueden encajar en este marco de la siguiente manera:

Volumen

• El volumen de registros procesados

Disponibilidad

• Con qué frecuencia (como porcentaje) se completó el trabajo en un tiempo determinado

Latencia

• La cantidad de tiempo que tarda el trabajo en ejecutarse

Errores

• Los registros que no se procesaron

Entradas

• La cantidad de veces que un operador debe corregir manualmente los datos y reprocesar un trabajo.

Usando VALET en las pruebas

Dado que estábamos desarrollando una cultura SRE al mismo tiempo, descubrimos que VALET respaldaba nuestra automatización de pruebas destructivas (ingeniería del caos) en nuestros entornos de preparación. Con el marco de TPS Reports implementado, podríamos ejecutar automáticamente pruebas destructivas y registrar el impacto (o, con suerte, la falta de impacto) en los datos de VALET del servicio.

Aspiraciones futuras

Con 800 servicios (y creciendo) recopilando datos de VALET, tenemos una gran cantidad de datos operativos útiles a nuestra disposición. Tenemos varias aspiraciones para el futuro.

Ahora que estamos recopilando SLO de forma eficaz, queremos utilizar estos datos para tomar medidas. Nuestro siguiente paso es una cultura de presupuesto de error similar a la de Google, mediante la cual un equipo deja de impulsar nuevas funciones (distintas de las mejoras en la confiabilidad) cuando un servicio está fuera del SLO. Para proteger las demandas de velocidad de nuestro negocio, tendremos que esforzarnos por encontrar un buen equilibrio entre el plazo de presentación de informes de SLO (semanal o mensual) y la frecuencia de incumplimiento de los SLO. Como muchas empresas que adoptan presupuestos de error, estamos sopesando los pros y los contras de las ventanas móviles frente a las ventanas fijas.

Queremos perfeccionar aún más VALET para realizar un seguimiento de los puntos finales detallados y los consumidores de un servicio. Actualmente, incluso si un servicio en particular tiene varios puntos finales, solo realizamos un seguimiento de VALET en todo el servicio. Como resultado, es difícil distinguir entre diferentes operaciones (por ejemplo, una escritura en el catálogo versus una lectura en el catálogo; mientras monitoreamos y alertamos sobre estas operaciones por separado, no hacemos un seguimiento de los SLO). Del mismo modo, también nos gustaría diferenciar los resultados de VALET para diferentes consumidores de un servicio.

Aunque actualmente realizamos un seguimiento de los SLO de latencia en la capa de servicio web, también nos gustaría realizar un seguimiento de un SLO de latencia para los usuarios finales. Esta medición capturaría cómo factores como las etiquetas de terceros, la latencia de Internet y el almacenamiento en caché de CDN afectan el tiempo que tarda una página en comenzar a renderizarse y completar la renderización.

También nos gustaría extender los datos de VALET a las implementaciones de aplicaciones. Específicamente, nos gustaría usar la automatización para verificar que VALET esté dentro de la tolerancia antes de implementar un cambio en el siguiente servidor, zona o región.

Comenzamos a recopilar información sobre las dependencias del servicio y hemos creado un prototipo de gráfico visual que muestra dónde no estamos alcanzando las métricas de VALET a lo largo de un árbol de llamadas. Este tipo de análisis será aún más fácil con las plataformas de malla de servicios emergentes.

Finalmente, creemos firmemente que los SLO para un servicio deben ser establecidos por el propietario de la empresa del servicio (a menudo llamado gerente de producto) en función de su importancia para la empresa. Como mínimo, queremos que los propietarios de negocios establezcan el requisito de tiempo de actividad de un servicio y utilicen ese SLO como un objetivo compartido entre la gestión y el desarrollo de productos. Aunque los tecnólogos encontraron que VALET era intuitivo, el concepto no era tan intuitivo para los gerentes de producto. Nos esforzamos por simplificar los conceptos de VALET utilizando terminología relevante para ellos: simplificamos la cantidad de opciones para el tiempo de actividad y proporcionamos métricas de ejemplo. También destacamos la importante inversión que se requiere para pasar de un nivel a otro. A continuación, se muestra un ejemplo de métricas VALET simplificadas que podríamos proporcionar:

• 99,5%: aplicaciones que no utilizan los asociados de la tienda o un MVP de un nuevo servicio
• 99,9%: adecuado para la mayoría de los sistemas que no venden en THD
• 99,95%: sistemas de venta (o servicios que admiten sistemas de venta)
• 99,99%: servicios de infraestructura compartida

Transmitir métricas en términos comerciales y compartir un objetivo visible (¡un SLO!) Entre el producto y el desarrollo reducirá muchas expectativas desalineadas sobre la confiabilidad que a menudo se ven en las grandes empresas.

Resumen

Introducir un nuevo proceso, y mucho menos una nueva cultura, en una gran empresa requiere una buena estrategia, la aceptación de los ejecutivos, un fuerte evangelismo, patrones de adopción fáciles y, sobre todo, paciencia. Pueden pasar años antes de que un cambio significativo como los SLO se establezca firmemente en una empresa. Nos gustaría enfatizar que The Home Depot es una empresa tradicional; Si podemos introducir un cambio tan grande con éxito, usted también puede hacerlo. Tampoco tiene que abordar esta tarea de una vez. Si bien implementamos los SLO pieza por pieza, el desarrollo de una estrategia de evangelización integral y una estructura de incentivos clara facilitó una transformación rápida: pasamos de 0 a 800 servicios respaldados por SLO en menos de un año.

Conclusión

Los SLO y los presupuestos de errores son conceptos poderosos que ayudan a abordar muchos conjuntos de problemas diferentes. Estos estudios de caso de Evernote y The Home Depot presentan ejemplos muy reales de cómo la implementación de una cultura SLO puede acercar el desarrollo de productos y las operaciones. Hacerlo puede facilitar la comunicación e informar mejor las decisiones de desarrollo. En última instancia, resultará en mejores experiencias para sus clientes, ya sean clientes internos, externos, humanos u otros servicios.

Estos dos estudios de caso destacan que la cultura SLO es un proceso continuo y no una solución o arreglo de una sola vez. Si bien comparten fundamentos filosóficos, los estilos de medición, SLI, SLO y detalles de implementación de THD y Evernote son marcadamente diferentes. Ambas historias complementan la propia visión de Google sobre los SLO al demostrar que la implementación de SLO no necesita ser específica de Google. Así como estas empresas adaptaron los SLO a sus propios entornos únicos, otras empresas y organizaciones también pueden hacerlo.

1 Pero esa es una historia para otro libro; vea más detalles en https://bit.ly/2spqgcl .

2 Las opciones de capacitación van desde un manual de una hora hasta talleres de medio día y una inmersión intensa de cuatro semanas con un equipo de SRE maduro, con una ceremonia de graduación y una insignia de FiRE.

3 Como se hizo famoso en la película de 1999 Office Space.

? SIGUIENTE
? ANTERIOR

Licencia

: Publicado por O’Reilly Media, Inc. bajo licencia CC BY-NC-ND 4.0