3. Casos prácticos de ingeniería SLO

Por Ben McCormack (Evernote) y
William Bonnell (The Home Depot)
con Garrett Plasky (Evernote), Alex Hidalgo
Betsy Beyer y Dave Rensin

Aunque muchos de los principios de la SRE se forjaron entre las paredes de Google, sus principios han vivido durante mucho tiempo fuera de nuestras puertas. Muchas de las prácticas estándar de la SRE de Google se han descubierto en paralelo o han sido adoptadas por muchas otras organizaciones del sector.

Los SLO son fundamentales para el modelo de SRE. Desde que creamos el equipo de Ingeniería de Fiabilidad del Cliente (CRE, por sus siglas en inglés), un grupo de SRE experimentados que ayudan a los clientes de Google Cloud Platform (GCP) a crear servicios más fiables, casi todas las interacciones con los clientes empiezan y terminan con SLO.

A continuación, presentamos dos historias, contadas por dos empresas muy diferentes, que describen sus trayectorias hacia la adopción de un enfoque basado en los SLO y en el presupuesto de errores mientras trabajaban con el equipo de CRE de Google. Para un análisis más general sobre los SLO y los presupuestos de errores, consulte el Capítulo 2 de este libro y el Capítulo 3 de nuestro primer libro.

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,000 millones de piezas de información -una mezcla de notas basadas en texto, archivos y archivos adjuntos/imágenes- en la plataforma. Entre bastidores, el servicio Evernote está soportado por más de 750 instancias 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 ingeniería manteniendo la calidad del servicio. Nuestros objetivos incluían

• Alejar el enfoque de ingeniería del trabajo pesado e indiferenciado en los centros de datos y dirigirlo hacia el trabajo de ingeniería de productos que realmente interesaba a los clientes. Para ello, dejamos de gestionar nuestros centros de datos físicos y nos trasladamos a una nube pública.

• Revisar el modelo de trabajo de los ingenieros de operaciones y software para apoyar un aumento de la velocidad de las funciones, manteniendo al mismo tiempo la calidad general del servicio.

• Renovar nuestra forma de ver los acuerdos de nivel de servicio para asegurarnos de que nos centramos más en cómo afectan los fallos a nuestra gran base de clientes global.

Estos objetivos pueden resultar familiares a organizaciones de muchos sectores. Aunque no existe un enfoque único para llevar a cabo este tipo de cambios que funcione en todos los casos, esperamos que compartir nuestra experiencia proporcione información valiosa para otros que se enfrenten a retos similares.

Al principio de esta transición, Evernote se caracterizaba por una división tradicional entre operaciones y desarrollo: un equipo de operaciones protegía la inviolabilidad del entorno de producción, mientras que un equipo de desarrollo se encargaba de desarrollar nuevas funciones del producto para los clientes. Estos objetivos solían entrar en conflicto: el equipo de desarrollo se sentía limitado por las largas exigencias operativas, mientras que el equipo de operaciones se frustraba cuando el nuevo código introducía nuevos problemas en producción. A medida que oscilábamos entre estos dos objetivos, los equipos de operaciones y desarrollo desarrollaban una relación frustrada y tensa. Queríamos encontrar un término medio que equilibrara mejor las distintas necesidades de los equipos implicados.

A lo largo de más de cinco años, intentamos abordar las lagunas de esta dicotomía tradicional de varias maneras. Después de probar el modelo “Tú lo escribes, tú lo ejecutas” (desarrollo) y el modelo “Tú lo escribes, nosotros lo ejecutamos por ti” (operaciones), nos decantamos por un enfoque de SRE centrado en el SLO.

¿Qué motivó a Evernote a avanzar en esta dirección?

En Evernote, vemos las disciplinas básicas de operaciones y desarrollo como vías profesionales separadas en las que los ingenieros pueden especializarse. Una de ellas se ocupa de la prestación continua de un servicio a los clientes las 24 horas del día, los 7 días de la semana. La otra se ocupa de la ampliación y evolución de ese servicio para satisfacer las necesidades de los clientes en el futuro. Estas dos disciplinas se han acercado entre sí en los últimos años a medida que movimientos como SRE y DevOps hacen hincapié en 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, que nos ofrecen un centro de datos totalmente controlado por software). En el otro lado del espectro, la propiedad full-stack y el despliegue continuo se aplican cada vez más al desarrollo de software.

Nos atrajo el modelo SRE porque acepta plenamente las diferencias entre operaciones y desarrollo, al tiempo que anima a los equipos a trabajar por un objetivo común. No trata de transformar a los ingenieros de operaciones en desarrolladores de aplicaciones, ni viceversa. Por el contrario, proporciona a ambos un marco de referencia común. En nuestra experiencia, un enfoque de presupuesto de errores/SLO ha llevado a ambos equipos a tomar decisiones similares cuando se les presentan los mismos hechos, ya que elimina una buena parte de la subjetividad de la conversación.

La primera parte de nuestro viaje fue el traslado de los centros de datos físicos a Google Cloud Platform.¹⁾ Una vez que el servicio de Evernote estuvo en funcionamiento en GCP y estabilizado, introdujimos los SLO. Nuestros objetivos aquí eran dos

• Alinear los equipos internamente en torno a los SLO de Evernote, asegurándonos de que todos los equipos trabajaban dentro del nuevo marco.

• Incorporar el SLO de Evernote en nuestra forma de trabajar 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 traslado a GCP no diluyera o enmascarara nuestro compromiso con nuestros usuarios.

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

Antes de entrar en los detalles técnicos de un SLO, es importante iniciar la conversación desde el punto de vista de tus clientes: ¿qué promesas intentas mantener? 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 nos centrábamos inicialmente en la necesidad más importante y común de los clientes: la disponibilidad del servicio Evernote para que los usuarios pudieran acceder y sincronizar su contenido en varios clientes. Nuestro viaje SLO comenzó a partir de ese objetivo. Mantuvimos nuestro primer paso simple centrándonos en el tiempo de actividad. Utilizando este sencillo primer enfoque, pudimos articular claramente lo que estábamos midiendo, y cómo.

Nuestro primer documento de SLOs contenía lo siguiente:

Una definición de las SLO
Se trataba de una medida del tiempo de actividad: 99.95% de tiempo de actividad medido en una ventana mensual, establecida para determinados servicios y métodos. Elegimos esta cifra basándonos en conversaciones con nuestros equipos internos de atención al cliente y productos y, lo que es más importante, en las opiniones de los usuarios. Decidimos deliberadamente vincular nuestros SLO a un mes natural en lugar de a un periodo móvil para mantenernos centrados y organizados a la hora de realizar revisiones del servicio.

Qué medir y cómo medirlo

Qué medir
Especificamos un punto final de servicio al que podríamos llamar para comprobar si el servicio funciona como se espera. 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 va bien.

Cómo medir
Queríamos un prober que llamara periódicamente a la página de estado. Queríamos que ese prober estuviera situado completamente fuera e independiente de nuestro entorno para que pudiéramos probar todos nuestros componentes, incluyendo nuestra pila de equilibrio de carga. Nuestro objetivo aquí era asegurarnos de que estábamos midiendo todos y cada uno de los fallos tanto del servicio GCP y la aplicación Evernote. Sin embargo, no queríamos problemas aleatorios de Internet para desencadenar falsos positivos. Hemos optado por utilizar una empresa de terceros que se especializa en la construcción y ejecución de tales probadores. Elegimos Pingdom, pero hay muchos otros en el mercado. Realizamos nuestras mediciones de la siguiente manera:

• Frecuencia de sondeo: Sondeamos nuestros nodos frontales cada minuto.

• Ubicación de las sondas: Este parámetro es configurable; actualmente utilizamos varias sondas en Norteamérica y Europa.

• Definición de “caído”: Si falla la comprobación de un prober, el nodo se marca como caído sin confirmar y, a continuación, un segundo prober separado geográficamente realiza una comprobación. Si la segunda comprobación falla, el nodo se marca como caído a efectos del cálculo de SLO. El nodo seguirá marcado como caído mientras las solicitudes de sonda consecutivas registren errores.

Cómo calcular los SLO a partir de los datos de monitorización
Por último, documentamos cuidadosamente cómo calculamos el SLO a partir de los datos brutos que recibimos de Pingdom. Por ejemplo, especificamos cómo tener en cuenta 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 tiempo de inactividad genérico e inexplicable, por lo que nuestros cálculos de SLO trataron el mantenimiento como tiempo de inactividad.

Una vez definidos nuestros SLO, teníamos que hacer algo con ellos. Queríamos que los SLO impulsaran cambios en el software y las operaciones que hicieran más felices a nuestros clientes y los mantuvieran contentos. ¿Cuál es la mejor manera de hacerlo?

Utilizamos el concepto de presupuesto SLO/error como método para asignar recursos en el futuro. Por ejemplo, si no cumplimos el SLO del mes pasado, ese comportamiento nos ayuda a priorizar las correcciones, mejoras y correcciones de errores pertinentes. Lo mantenemos simple: los equipos de Evernote y Google llevan a cabo una revisión mensual del rendimiento de SLO. En esta reunión, revisamos el rendimiento de SLO del mes anterior y realizamos una inmersión profunda en cualquier interrupción. Basándonos en este análisis del mes anterior, establecemos acciones de mejora que pueden no haber sido detectadas a través del proceso habitual de análisis de la 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 como para guiar las mejoras a lo largo del tiempo. Un SLO “perfecto” sería aquel que midiera todas las posibles interacciones de los usuarios con nuestro servicio y tuviera en cuenta todos los casos extremos. Aunque sobre el papel es una gran idea, nos llevaría muchos meses conseguirlo (si es que la perfección fuera posible), tiempo que podríamos emplear en mejorar el servicio. En su lugar, seleccionamos un SLO inicial que cubría la mayoría de las interacciones de los usuarios, pero no todas, lo que constituía una buena aproximación a la calidad del servicio.

Desde que empezamos, hemos revisado nuestros objetivos dos veces, según las señales de nuestras revisiones internas del servicio y en respuesta a las interrupciones que afectaban a los clientes. Como al principio no aspirábamos a unos SLO perfectos, nos sentimos cómodos haciendo cambios para alinearlos mejor con la empresa. Además de nuestra revisión mensual de Evernote/Google sobre el rendimiento de los SLO, hemos establecido un ciclo de revisión de los SLO de seis meses, que consigue el equilibrio adecuado entre cambiar los SLO con demasiada frecuencia y dejar que se queden obsoletos. Al revisar nuestros SLO, también hemos aprendido que es importante equilibrar lo que te gustaría medir con lo que es posible medir.

Desde la introducción de las SLO, la relación entre nuestros equipos de operaciones y desarrollo ha mejorado sutil pero notablemente. Los equipos tienen ahora una medida común del éxito: eliminar la interpretación humana de la calidad del servicio (QoS) ha permitido a ambos equipos mantener la misma visión y los mismos estándares. Por poner solo un ejemplo, los SLO proporcionaron un terreno común cuando tuvimos que facilitar múltiples lanzamientos en un plazo de tiempo comprimido en 2017. Mientras perseguíamos un error complejo, el equipo de desarrollo de productos nos pidió que repartiéramos nuestro lanzamiento semanal normal en varias ventanas separadas, cada una de las cuales podría afectar 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.

Un muro virtual entre las preocupaciones del cliente y las del proveedor de la nube podría parecer natural o inevitable. Mientras que Google tiene SLO y SLA (acuerdos de nivel de servicio) para las plataformas 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 del otro.

Evernote nunca quiso semejante muro. Por supuesto, podríamos haber diseñado un muro divisorio, basando nuestros SLO y SLA en las métricas subyacentes de GCP. En lugar de eso, desde el principio quisimos que Google comprendiera 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 Evernote en materia de fiabilidad como responsabilidades compartidas. Para conseguirlo, necesitábamos una forma de

• Alinear objetivos

• Asegurarnos de que nuestro socio (en este caso, Google) comprendía realmente lo que es importante para nosotros.

• Compartir los éxitos y los fracasos

La mayoría de los proveedores de servicios se rigen por los SLO/SLA publicados para sus servicios en la nube. Trabajar en este contexto es importante, pero no puede representar de forma holística lo bien que funciona nuestro servicio en el entorno del proveedor de la nube.

Por ejemplo, un proveedor de nube determinado probablemente ejecuta cientos de miles de máquinas virtuales en todo el mundo, que gestiona 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 SLO de GCP 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 sólo un pequeño porcentaje del número global de GCP, las interrupciones aisladas en nuestra región (o aisladas por otras razones) pueden “perderse” en el rollup general a nivel global.

Para corregir este tipo de situaciones, compartimos con Google nuestro SLO y el rendimiento en tiempo real con respecto al SLO. Como resultado, tanto el equipo de Google CRE como Evernote trabajan con los mismos tableros 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 del tipo “El servicio X funciona con lentitud”, Google nos proporciona notificaciones más específicas para nuestro entorno. Por ejemplo, además de un genérico “El entorno de equilibrio de carga de GCP está funcionando lento hoy”, también se nos informará de 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, que pueden ver cómo sus acciones y decisiones repercuten en los clientes.

Esta relación bidireccional también nos ha proporcionado un marco muy eficaz para dar soporte a incidencias importantes. La mayor parte del tiempo, el modelo habitual de tickets P1-P5 y canales de asistencia regulares 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 (“impacto importante en nuestro negocio”) no es suficiente, momentos en los que todo tu servicio está en juego y te enfrentas a un impacto prolongado en el negocio.

En ocasiones como ésta, nuestros SLO compartidos y nuestra relación con el equipo de CRE dan sus frutos. Tenemos un entendimiento común de que si el impacto del SLO es lo suficientemente alto, ambas partes tratarán el problema como un ticket P1 con un tratamiento especial. Muy a menudo, esto significa que el equipo CRE de Evernote y Google se movilizan rápidamente en un puente de conferencia compartido. El equipo CRE de Google supervisa el SLO que hemos definido y acordado conjuntamente, lo que nos permite permanecer sincronizados en cuanto a la priorización y las respuestas adecuadas.

Después de utilizar activamente los SLO durante unos nueve meses, Evernote ya está en la versión 3 de su práctica de SLO. La próxima versión de los SLO avanzará a partir de nuestro simple SLO de tiempo de actividad. Tenemos previsto empezar a sondear las llamadas individuales a la API y tener en cuenta la visión de las métricas/rendimiento en el cliente para poder representar aún mejor la calidad de servicio del usuario.

Al proporcionar una forma estándar y definida de medir la calidad del servicio, las SLO han permitido a Evernote centrarse mejor en cómo funciona nuestro servicio. Ahora podemos mantener 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, conseguir equipos de asistencia más eficaces y clientes más satisfechos.

por William Bonnell, The Home Depot

The Home Depot (THD) es el mayor minorista de artículos para el hogar del mundo: tenemos más de 2,200 tiendas en Norteamérica, cada una de ellas con más de 35,000 productos únicos (y complementadas con más de 1.5 millones de productos en línea). Nuestra infraestructura alberga diversas aplicaciones informáticas que dan soporte a casi 400,000 empleados 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,000 millones de visitas al año.

En una reciente actualización de nuestro enfoque de operaciones para aumentar la velocidad y la calidad de nuestro desarrollo de software, THD pasó al desarrollo de software ágil y cambió la forma de diseñar y gestionar nuestro software. Pasamos de equipos de soporte centralizados que daban soporte a 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 paso a los microservicios se complementó con un cambio a una nueva “cultura de libertad y responsabilidad” de propiedad total. Este enfoque da libertad a los desarrolladores para introducir código cuando quieran, pero también les hace corresponsables de las operaciones de su servicio. Para que este modelo de propiedad conjunta funcione, los equipos de operaciones y desarrollo tienen que hablar un lenguaje común que fomente la responsabilidad y trascienda la complejidad: los objetivos de nivel de servicio. Los servicios que dependen unos de otros necesitan conocer información como:

• ¿Cuál es la fiabilidad de su servicio? ¿Está diseñado para tres nueves, tres nueves y medio o cuatro nueves (o más)? ¿Está previsto un tiempo de inactividad?

• ¿Qué tipo de latencia puedo esperar en los límites superiores?

• ¿Puede gestionar el volumen de solicitudes que voy a enviar? ¿Cómo gestionan la sobrecarga? ¿Ha alcanzado su servicio sus SLO a lo largo del tiempo?

Si todos los servicios pudieran dar respuestas transparentes y coherentes a estas preguntas, los equipos tendrían una visión clara de sus dependencias, lo que permite mejorar la comunicación y aumentar la confianza y la responsabilidad entre equipos.

Antes de iniciar este cambio en nuestro modelo de servicio, The Home Depot no tenía una cultura de SLO. Abundaban las herramientas de supervisión y los tableros de control, pero estaban dispersos por todas partes y no realizaban un seguimiento de los datos a lo largo del tiempo. No siempre éramos capaces de localizar el servicio en el origen de una avería determinada. A menudo, empezábamos a solucionar los problemas en el servicio de cara al usuario y trabajábamos hacia atrás hasta encontrar el problema, lo que nos hacía perder incontables horas. Si un servicio requería un tiempo de inactividad planificado, sus servicios dependientes se veían sorprendidos. Si un equipo necesitaba crear un servicio de tres 9s y medio, no sabía si el servicio del que dependía en gran medida podía darles soporte con un tiempo de actividad aún mejor (cuatro 9s). Estas desconexiones causaban confusión y decepción entre nuestros equipos de desarrollo de software y de operaciones.

Necesitábamos abordar estas desconexiones creando una cultura común de SLO. Para ello era necesaria una estrategia global que influyera en las personas, los procesos y la tecnología. Nuestros esfuerzos abarcaron cuatro áreas generales:

Lenguaje común
Definir las SLO en el contexto de THD. Definir cómo medirlos de forma coherente.

Evangelización
Correr la voz en toda la empresa.

• Cree material de formación para explicar por qué son importantes los SLO, presentaciones itinerantes en toda la empresa, blogs internos y material promocional como camisetas y pegatinas.

• Reclute a algunos de los primeros en adoptar las SLO para que las pongan en práctica y demuestren su valor a los demás.

• Establezca un acrónimo pegadizo (VALET, como se explica más adelante) para ayudar a difundir la idea.

• Crear un programa de formación (FiRE Academy: Fundamentals in Reliability Engineering) para formar a los desarrolladores en SLO y otros conceptos de fiabilidad.²⁾

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 desplegado en producción. Estos SLI pueden convertirse más tarde en SLO.

Incentivos
Establezca objetivos anuales para que todos los directores de desarrollo fijen y midan los SLO de sus servicios.

Establecer un lenguaje común era fundamental para que todos estuvieran de acuerdo. También queríamos que este marco fuera lo más sencillo posible para que la idea se difundiera más rápidamente. Para empezar, echamos un vistazo crítico a las métricas que controlábamos en nuestros distintos servicios y descubrimos algunas pautas. Todos los servicios controlaban de algún modo el volumen de tráfico, la latencia, los errores y la utilización, métricas que se corresponden estrechamente con las cuatro señales de oro de Google SRE. Además, muchos servicios controlaban el tiempo de actividad o la disponibilidad de forma distinta a los errores. Por desgracia, en general, todas las categorías de métricas se supervisaban de forma incoherente, se denominaban de forma diferente o no disponían de datos suficientes.

Ninguno de nuestros servicios tenía SLO. La métrica más parecida a un SLO orientado al cliente que tenían nuestros sistemas de producción eran los tickets de soporte. La principal (y a menudo única) forma de medir la fiabilidad de las aplicaciones desplegadas en nuestras tiendas era hacer un seguimiento del número de llamadas de asistencia que recibía nuestro servicio de asistencia interno.

No podíamos crear SLO para cada aspecto de nuestros sistemas que pudiera medirse, así que tuvimos que decidir qué métricas o SLIs deberían tener también SLOs.

Disponibilidad y latencia de las llamadas a la API

Decidimos que cada microservicio tenía que tener SLOs de disponibilidad y latencia para sus llamadas API que eran llamadas por otros microservicios. Por ejemplo, el microservicio Cart llamaba al microservicio Inventory. Para esas llamadas a la API, el microservicio Inventario publicaba SLO que el microservicio Cesta (y otros microservicios que necesitaran Inventario) podían consultar para determinar si el microservicio Inventario podía cumplir sus requisitos de fiabilidad.

Utilización de la infraestructura

Los equipos de THD miden la utilización de la infraestructura de diferentes formas, pero la medición 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 se preocupan demasiado por esta métrica: a los usuarios no les importa realmente la utilización siempre que se pueda gestionar el volumen de tráfico, el microservicio esté activo, responda rápidamente, no genere errores y no corra el riesgo de quedarse sin capacidad. Además, nuestro inminente traslado a la nube significaba que la utilización sería menos preocupante, por lo que la planificación de costos eclipsaría la planificación de capacidad. (Seguiríamos necesitando supervisar la utilización y realizar una planificación de la capacidad, pero no necesitábamos incluirlo en nuestro marco de SLO).

Volumen de tráfico

Como 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. Era fácil definir el tráfico como peticiones a un servicio, pero teníamos que decidir si debíamos hacer un seguimiento de la media de peticiones por segundo, de los picos de peticiones por segundo o del volumen de peticiones durante el periodo del informe. Decidimos hacer un seguimiento de los tres y dejar que cada servicio seleccionara la métrica más apropiada. Debatimos si establecer o no un SLO para el volumen de tráfico porque esta métrica viene determinada por el comportamiento de los usuarios, más que por factores internos que podamos controlar. Al final, decidimos que, como minoristas, debíamos dimensionar nuestro servicio para picos como el del “Black Friday”, así que establecimos un SLO en función de los picos de capacidad previstos.

Latencia

Dejamos que cada servicio definiera su SLO de latencia y determinara dónde medirla mejor. Nuestra única petición fue que un servicio complementara nuestra monitorización común del rendimiento de caja blanca con monitorización 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 porcentajes eran más apropiados que las medias aritméticas. Como mínimo, los servicios debían alcanzar un objetivo de 90%; los servicios de cara al usuario preferían un objetivo de 95% y/o 99%.

Errores

Resultaba complicado tener en cuenta los errores. Al tratarse principalmente de servicios web, tuvimos que estandarizar qué constituye un error y cómo se devuelven los errores. Si un servicio web encontraba un error, naturalmente estandarizábamos los códigos de respuesta HTTP:

• Un servicio no debe indicar un error en el cuerpo de una respuesta 2xx, sino 4xx o 5xx.

• Un error causado por un problema con el servicio (por ejemplo, falta de memoria) debe arrojar un error 5xx.

• Un error causado por el cliente (por ejemplo, el envío de una solicitud malformada) debería arrojar un error 4xx.

Tras muchas deliberaciones, decidimos hacer un seguimiento tanto de los errores 4xx como de los 5xx, pero utilizamos los errores 5xx sólo para establecer los SLO. De forma similar a nuestro enfoque para otros elementos relacionados con los 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 podrían ser el número de registros que no se han podido procesar.

Tickets

Como se ha mencionado anteriormente, los tickets eran originalmente la forma principal de evaluar la mayor parte de nuestro software de producción. Por razones históricas, decidimos seguir haciendo un seguimiento de los tickets junto con nuestros otros SLO. Puede considerar esta métrica como análoga a algo como “nivel de funcionamiento del software”.

VALET

Resumimos nuestros nuevos SLO en un práctico acrónimo: VALET.

• Volumen (tráfico) - ¿Cuánto volumen de negocio puede gestionar mi servicio?
• Disponibilidad(Availability) - ¿Está disponible el servicio cuando lo necesito?
• Latencia - ¿Responde rápido el servicio cuando lo utilizo?
• Errores - ¿Produce el servicio algún error cuando lo utilizo?
• Tickets - ¿Requiere el servicio intervención manual para completar mi solicitud?

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

• Por qué son importantes los SLO

• Cómo los SLO apoyan nuestra cultura de “libertad y responsabilidad”.

• Qué debe medirse

• Qué hacer con los resultados

Dado que los desarrolladores eran ahora responsables del funcionamiento de su software, necesitaban establecer SLO para demostrar su capacidad de crear y mantener un software fiable, y también para comunicarse con los consumidores de sus servicios y los jefes de producto de los servicios orientados al cliente. Sin embargo, la mayor parte de este público no estaba familiarizado con conceptos como los SLA y los SLO, por lo que necesitaban ser educados en este nuevo marco VALET.

Como necesitábamos el respaldo de los ejecutivos para nuestro paso a las SLO, nuestra campaña educativa empezó con los altos directivos. A continuación, nos reunimos con los equipos de desarrollo uno por uno para hacerles partícipes de los valores de las SLO. Animamos a los equipos a pasar de sus mecanismos personalizados de seguimiento de métricas (a menudo manuales) al marco VALET. Para mantener el impulso, enviamos un informe semanal sobre los SLO en formato VALET, que combinamos con comentarios sobre conceptos generales de fiabilidad y lecciones aprendidas de eventos internos, a la alta dirección. Esto también ayudó a enmarcar métricas empresariales como los pedidos de compra creados (Volumen) o los pedidos de compra que no se procesaron (Errores) en términos de VALET.

También ampliamos nuestra evangelización de varias maneras:

• Creamos un sitio interno en WordPress para alojar blogs sobre VALET y la fiabilidad, con enlaces a recursos útiles.

• Hemos organizado charlas técnicas internas (con un ponente invitado de Google SRE) para debatir conceptos generales de fiabilidad y cómo medirla con VALET.

• Organizamos una serie de talleres de formación sobre VALET (que más tarde se convertirían en la FiRE Academy), a los que se invitó a todo el que quisiera asistir. La asistencia a estos talleres se mantuvo durante varios meses.

• Incluso creamos pegatinas y camisetas de VALET para portátiles como apoyo a una amplia campaña de marketing interno.

Pronto todo el mundo en la empresa conocía VALET, y nuestra nueva cultura de SLO empezó a arraigar. La implementación de los SLO empezó incluso a formar parte de las revisiones anuales del rendimiento de los directores de desarrollo de THD. Mientras unos 50 servicios registraban e informaban semanalmente sobre sus SLO, nosotros almacenábamos las métricas ad hoc en una hoja de cálculo. Aunque la idea de VALET había corrido como la pólvora, necesitábamos automatizar la recogida de datos para fomentar su adopción generalizada.

Aunque nuestra cultura de los SLO ya estaba muy arraigada, la automatización de la recopilación de datos de VALET aceleraría la adopción de los SLO.

Reportes TPS

Creamos un marco para capturar automáticamente los datos VALET de cualquier servicio que se desplegara en nuestro nuevo entorno GCP. Llamamos a este marco TPS Reports, un juego de palabras con el término que utilizamos para las pruebas de volumen y rendimiento (transacciones por segundo) y, por supuesto, para burlarnos³⁾ de la idea de que varios gestores podrían querer revisar estos datos. Construimos el marco TPS Reports sobre la plataforma de base de datos BigQuery de GCP. Todos los registros generados por nuestro frontend de servicio web se introdujeron en BigQuery para su procesamiento por TPS Reports. Con el tiempo, también incluimos métricas de otros sistemas de supervisión, como la sonda de disponibilidad de Stackdriver.

TPS Reports transformó estos datos en métricas VALET horarias que cualquiera podía consultar. Los servicios recién creados se registraban automáticamente en TPS Reports y, por tanto, podían consultarse inmediatamente. Como todos los datos se almacenaban en BigQuery, podíamos elaborar informes eficientes sobre las métricas de VALET en distintos periodos de tiempo. Utilizamos estos datos para crear diversos informes y alertas automatizados. La integración más interesante fue un chatbot que nos permitía informar directamente sobre el VALET de los servicios en una plataforma de chat comercial. Por ejemplo, cualquier servicio podía mostrar el VALET de la última hora, el VALET de la semana anterior, los servicios fuera del SLO y otros datos interesantes directamente en el canal de chat.

Servicio VALET

Nuestro siguiente paso fue crear una aplicación VALET para almacenar e informar sobre los datos de SLO. Dado que los SLO se aprovechan mejor como herramienta de tendencias, el servicio realiza un seguimiento diario, semanal y mensual de los SLO. Tenga en cuenta que nuestras SLO son una herramienta de tendencias que podemos utilizar para los presupuestos de errores, pero no están directamente conectadas a nuestros sistemas de supervisión. En su lugar, disponemos de diversas plataformas de supervisión, cada una con sus propias alertas. Estos sistemas de supervisión agregan sus SLO a diario y los publican en el servicio VALET para establecer tendencias. El inconveniente de esta configuración es que los umbrales de alerta establecidos en los sistemas de supervisión no están integrados con los SLO; sin embargo, tenemos la flexibilidad de cambiar los sistemas de supervisión 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 de VALET que proporciona una API para recopilar diariamente datos agregados de VALET para un servicio. TPS Reports fue el primer sistema en integrarse con el servicio VALET, y con el tiempo lo hicimos con diversas plataformas de aplicaciones locales (más de la mitad de los servicios registrados en VALET).

Tablero VALET

El tablero VALET (mostrado 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

• Registrar un nuevo servicio. Esto normalmente significa asignar el servicio a una o más URL, que ya pueden tener datos VALET recopilados.

• Establecer objetivos SLO para cualquiera de las cinco categorías VALET.

• Añada nuevos tipos de métricas en cada una de las categorías VALET. Por ejemplo, un servicio puede realizar un seguimiento de la latencia en el 99%, mientras que otro realiza un seguimiento de la latencia en el 90% (o ambos). O bien, un sistema de procesamiento backend puede hacer un seguimiento del volumen a nivel diario (pedidos de compra creados en un día), mientras que un frontend de atención al cliente puede hacer un seguimiento de los picos de transacciones por segundo.

El tablero de VALET permite a los usuarios elaborar informes sobre los SLO de varios servicios a la vez, así como dividir los datos de diversas maneras. Por ejemplo, un equipo puede ver las estadísticas de todos los servicios que no alcanzaron el SLO la semana pasada. Un equipo que desee revisar el rendimiento de un servicio puede ver la latencia de todos sus servicios y de los servicios de los que dependen. El tablero VALET almacena los datos en una sencilla base de datos SQL en la nube, y los desarrolladores utilizan una conocida herramienta comercial de generación de informes para crearlos.

Estos informes se convirtieron en la base de una nueva práctica recomendada para los desarrolladores: revisiones periódicas de los SLO de sus servicios (normalmente, semanales o mensuales). Sobre la base de estas revisiones, los desarrolladores pueden crear elementos de acción para devolver un servicio a su SLO, o tal vez decidir que es necesario ajustar un SLO poco realista.

Figura 3-1. El tablero de VALET

Una vez que los SLO estuvieron firmemente arraigados en la mentalidad colectiva de la organización y se implantaron sistemas eficaces de automatización e información, los nuevos SLO proliferaron rápidamente. Después de hacer el seguimiento de unos 50 servicios a principios de año, a finales de año estábamos haciendo el seguimiento de 800 servicios, con unos 50 servicios nuevos al mes registrados en VALET.

Dado que VALET nos permitió ampliar la adopción de SLO en THD, el tiempo necesario para desarrollar la automatización mereció la pena. Sin embargo, otras empresas no deberían tener miedo de adoptar un enfoque basado en el SLO si no pueden desarrollar una automatización de complejidad similar. Aunque la automatización proporcionó a THD beneficios adicionales, escribir las SLO también tiene sus ventajas.

A medida que desarrollábamos informes sólidos en torno a 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 - Volumen de registros procesados
• Disponibilidad - Frecuencia (en porcentaje) con la que el trabajo se ha completado en un tiempo determinado
• Latencia - El tiempo que tarda en ejecutarse el trabajo
• Errores - Los registros que no se han podido procesar
• Tickets - El número de veces que un operador tiene que corregir manualmente los datos y volver a procesar un trabajo

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

Con 800 servicios (y en aumento) que recopilan datos de VALET, disponemos de una gran cantidad de datos operativos útiles. Tenemos varias aspiraciones para el futuro.

Ahora que estamos recopilando SLO de forma efectiva, queremos utilizar estos datos para tomar medidas. Nuestro siguiente paso es una cultura de presupuesto de errores similar a la de Google, por la que un equipo deja de impulsar nuevas funciones (que no sean mejoras de la fiabilidad) cuando un servicio está fuera de SLO. Para proteger las demandas de velocidad de nuestro negocio, tendremos que esforzarnos por encontrar un buen equilibrio entre el marco temporal de los informes de SLO (semanal o mensual) y la frecuencia con la que se incumplen los SLO. Como muchas empresas que adoptan presupuestos por error, estamos sopesando los pros y los contras de las ventanas móviles frente a las ventanas fijas.

Queremos seguir perfeccionando VALET para realizar un seguimiento detallado de los puntos finales y los consumidores de un servicio. En la actualidad, aunque un servicio concreto tenga varios puntos finales, sólo hacemos 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 frente a una lectura en el catálogo; aunque supervisamos 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 los distintos consumidores de un servicio.

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

También nos gustaría ampliar los datos de VALET a los despliegues de aplicaciones. En concreto, nos gustaría utilizar la automatización para verificar que VALET está dentro de los límites de tolerancia antes de implementar un cambio en el siguiente servidor, zona o región.

Hemos empezado a recopilar información sobre las dependencias de los servicios y hemos creado un prototipo de gráfico visual que muestra dónde no se cumplen 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 nuevas plataformas de malla de servicios.

Por último, creemos firmemente que los SLO de un servicio deben ser establecidos por el propietario del servicio (a menudo denominado product manager) en función de su criticidad para la empresa. Como mínimo, queremos que sean los propietarios de la empresa quienes establezcan el requisito de tiempo de actividad de un servicio y utilicen ese SLO como objetivo compartido entre la gestión y el desarrollo del producto. Aunque los tecnólogos encontraron VALET intuitivo, el concepto no lo era tanto para los Product Managers. Nos esforzamos por simplificar los conceptos de VALET utilizando terminología relevante para ellos: hemos simplificado el número de opciones para el tiempo de actividad y hemos proporcionado métricas de ejemplo. También hacemos hincapié en la importante inversión necesaria para pasar de un nivel a otro. He aquí un ejemplo de las métricas simplificadas de VALET que podríamos proporcionar:

• 99.5%: Aplicaciones que no utilizan los empleados de la tienda o un MVP de un nuevo servicio

• 99.9%: Adecuado para la mayoría de los sistemas que no se venden en THD

• 99.95%: Sistemas de venta (o servicios compatibles con sistemas de venta)

• 99.99%: Servicios de infraestructura compartidos

Si las métricas se expresan en términos empresariales y se comparte un objetivo visible (¡un SLO!) entre el producto y el desarrollo, se reducirán muchas de las expectativas desalineadas sobre la fiabilidad que suelen verse en las grandes empresas.

Introducir un nuevo proceso, por no hablar de una nueva cultura, en una gran empresa requiere una buena estrategia, la implicación de los ejecutivos, una fuerte evangelización, patrones de adopción sencillos y, sobre todo, paciencia. Un cambio significativo como los SLO puede tardar años en establecerse firmemente en una empresa. Nos gustaría destacar que The Home Depot es una empresa tradicional; si nosotros podemos introducir con éxito un cambio de tal envergadura, usted también puede hacerlo. Tampoco es necesario abordar esta tarea de una sola vez. Aunque implantamos los SLO pieza a pieza, el desarrollo de una estrategia de evangelización integral y una estructura de incentivos clara facilitaron una rápida transformación: pasamos de 0 a 800 servicios respaldados por SLO en menos de un año.

Los SLO y los presupuestos de errores son conceptos poderosos que ayudan a abordar muchos problemas diferentes. Estos casos prácticos de Evernote y The Home Depot presentan ejemplos muy reales de cómo la implantación de una cultura de SLO puede acercar el desarrollo de productos a las operaciones. Hacerlo puede facilitar la comunicación y fundamentar mejor las decisiones de desarrollo. En última instancia, dará lugar a mejores experiencias para sus clientes, ya sean internos, externos, humanos o de otros servicios.

Estos dos estudios de casos ponen de relieve que la cultura SLO es un proceso continuo y no un arreglo o solución de una sola vez. Aunque comparten fundamentos filosóficos, los estilos de medición, los SLI, los SLO y los detalles de implementación de THD y Evernote son notablemente diferentes. Ambas historias complementan la propia visión de Google sobre los SLO al demostrar que la implementación de los SLO no tiene por qué ser específica de Google. Al igual que estas empresas adaptaron los SLO a sus propios entornos, también pueden hacerlo otras empresas y organizaciones.

Volver al índice