Buscando SRE

Capítulo 4. Utilizar métricas de incidencias para mejorar la SRE a escala

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Martin Check, Microsoft

Tanto si tu servicio busca añadir su próxima docena de usuarios como sus próximos mil millones de usuarios, tarde o temprano acabarás en una conversación sobre cuánto invertir en qué áreas para mantener la fiabilidad a medida que el servicio se amplía. En este capítulo, echamos un vistazo a cómo utilizar las métricas de incidencias para centrar las inversiones mediante un caso práctico de Microsoft Azure. Aplica las lecciones que hemos aprendido trabajando en la fiabilidad del servicio en una variedad de servicios, que van desde las startups hasta los servicios empresariales, pasando por la escala de la nube. Azure es un caso de estudio especialmente bueno, ya que la enorme escala, el crecimiento y la diversidad de ofertas de productos amplifican los temas típicos de fiabilidad. Mostramos cómo el uso de datos y algunas técnicas innovadoras para analizar e informar sobre estos temas nos ayudó a impulsar mejoras.

El ciclo virtuoso al rescate: Si no lo mides...

Como en cualquier esfuerzo de gestión de problemas, empezamos por examinar los datos. Sin embargo, cuando fuimos a hacerlo, resultó que teníamos miles de fuentes de datos, telemetría de servicios, métricas de gestión de incidencias, métricas de implementación, y así un largo etcétera. De hecho, teníamos tantas fuentes de datos que consultar que decidir qué datos consultar y en qué orden abordar los problemas resultaba complicado. Tras estudiar las buenas prácticas del sector y consultar a expertos, al final nos decidimos por un sistema llamado ciclo virtuoso, que se muestra en la Figura 4-1, para sustentar nuestros esfuerzos de mejora. El ciclo virtuoso creó un marco que podíamos utilizar para ver la eficacia de nuestro monitoreo en función de la rapidez con que detectábamos las averías, lo bien que aprendíamos de las averías midiendo el proceso de análisis de la causa raíz (RCA) y las reparaciones, y la rapidez con que se corregían esos fallos. Luego podíamos examinar la calidad de nuestro código y la velocidad de implementación para ver lo rápido que habíamos recorrido el ciclo completo.

Figura 4-1. El ciclo virtuoso

Como SRE, sabemos que cada minuto de tiempo de inactividad importa, así que empezamos por encontrar las métricas clave que nos dijeran lo eficaces que éramos respondiendo a las incidencias y reparándolas. Esto significaba que primero teníamos que definir las métricas que eran representativas y luego llegar a un acuerdo sobre las definiciones y los tiempos de inicio/fin. Profundicemos en las métricas que elegimos y por qué pensamos que eran tan importantes:

Tiempo de detección (TTD)

El Tiempo hasta la Detección es el tiempo transcurrido desde el inicio del impacto hasta el momento en que un incidente es visible para un operador. Iniciamos el contador cuando el impacto se hace visible por primera vez para el cliente, aunque nuestro monitoreo no lo haya detectado. Suele coincidir con el momento en que se incumple el Acuerdo de Nivel de Servicio (ANS).

Lo creas o no, el TTD es la métrica más importante para los incidentes que requieren una acción manual de mitigación. Esta medida determina la calidad y precisión de tu monitoreo. Si no conoces el dolor de tus clientes, no puedes iniciar el proceso de recuperación, y desde luego no puedes activar la automatización para responder o mitigar. Y lo que es aún más importante, no puedes comunicar a tus clientes que conoces el problema y estás trabajando en él. El reto con el TTD es equilibrar la sensibilidad del monitoreo de modo que encuentres todos los problemas de los clientes con rapidez y precisión, sin interrumpir constantemente a tus ingenieros por problemas que no afectan a los clientes.

Tiempo para comprometerse (TTE)

Es el tiempo que transcurre desde la detección hasta que interviene el ingeniero adecuado. Esto puede ser difícil de determinar durante el evento, y a veces incluso después. Puede ser difícil mirar hacia atrás a través de la niebla de guerra para precisar esto en un solo ingeniero, por lo que está bien hacer una aproximación con el primer ingeniero en la escena. Esta métrica es muy importante para ver la eficacia con la que somos capaces de movilizar la respuesta, y tiene en cuenta tanto el tiempo de triaje (determinar la gravedad y la propiedad) como el tiempo para escalar y movilizar a los intervinientes. Hay muchas formas de mejorar esto: sistemas automatizados de escalado y localización, expectativas claras para los modelos de asistencia de guardia y de seguimiento al sol, e incluso un mejor monitoreo pueden ayudar a garantizar que la alerta llegue al ingeniero de guardia adecuado la primera vez.

Tiempo de reparación (TTF)

Es el tiempo que tarda la persona que responde en mitigar el problema.

Todas estas métricas, sumadas (TTD + TTE + TTF) están representadas por el Tiempo de Mitigación (TTM), el tiempo de ciclo completo a través de la interrupción, como se representa en la Figura 4-2.

Figura 4-2. Ejemplo de desglose del tiempo de mitigación de una interrupción

Puedes tener métricas, definiciones o umbrales diferentes, pero lo único que importa es que tu grupo se ponga de acuerdo sobre la taxonomía y las medidas comunes. El acuerdo sobre la taxonomía es especialmente importante porque si no se acuerda el evento de mitigación, podemos tener desconexiones, ya que algunos equipos podrían intentar desvincularse antes de que el incidente esté totalmente resuelto. Esto se vuelve especialmente crítico después del incidente para garantizar una taxonomía común durante las reuniones de revisión del incidente para hablar de dónde hay oportunidades de mejora.

Revisión de Métricas: Si una métrica cae en el bosque...

Una vez definidas estas métricas, reunimos a nuestros líderes de ingeniería para examinar las métricas clave que identificamos como cruciales para impulsar el círculo virtuoso. Así pudimos hacer un seguimiento de nuestros progresos, obtener información y crear planes de acción en las áreas en las que no alcanzábamos nuestros objetivos. Tras definir y acordar las métricas, empezamos a recopilar e informar sobre agregados de datos por servicio para determinar cómo lo estábamos haciendo, encontrar áreas y temas comunes de mejora, y medir el impacto de las mejoras realizadas. La Figura 4-3 muestra un ejemplo de panel de control para medir las métricas de incidencias e implementaciones. Esto nos permitió seguir las tendencias de las métricas de nuestro ciclo de respuesta a incidentes y diseñar mejoras del mismo modo que diseñamos las características del producto.

Figura 4-3. Panel de métricas SRE

Observa que aquí aparecen las métricas de respuesta a incidentes de las que hemos hablado antes: TTD, TTE, TTF y TTM, con tendencias por periodo de tiempo, y medidas en función de los objetivos que habíamos establecido y acordado con los propietarios de los servicios. Si descubríamos que los datos eran escasos, tenían una gran variabilidad o presentaban valores atípicos importantes, aplicábamos percentiles a los datos para normalizarlos lo suficiente. Entonces podíamos examinar los valores atípicos para comprenderlos mejor y llevar los percentiles hacia el 100%.

Métricas Sustitutas

Si observas detenidamente el panel de métricas de la SRE, verás algunas métricas como los saltos del Individuo Directamente Responsable (DRI) (cuántos ingenieros de guardia se necesitan para resolver un incidente) y la autodetección (cuántos incidentes se detectan mediante monitoreo). Se trata de métricas sustitutivas, que son submétricas relacionadas con la métrica de alto nivel "Tiempo hasta" que son más específicas y procesables que las métricas de alto nivel, pero que no indican por sí mismas el éxito. Descubrimos que el uso de métricas sustitutas conducía a mejoras más rápidas y duraderas, porque dar a los responsables de ingeniería elementos de acción y submétricas específicas era una forma más eficaz de impulsar la acción que limitarse a decir a los equipos "hazlo mejor" y "esfuérzate más".

Explorar tus datos es una buena forma de encontrar métricas sustitutivas. Si nos fijamos en la TTE como ejemplo, al investigar incidentes con tiempos de intervención prolongados, encontramos factores que se correlacionaban con los tiempos de intervención elevados o los provocaban, como la intervención de muchos ingenieros para resolver un solo incidente. Esto podía ocurrir debido a lagunas de conocimientos, lagunas de instrumentación o incluso expectativas incoherentes de respuesta de guardia. Para solucionarlo, añadimos la submétrica "#DRIs contratados por puente", que nos permite ver cuántos DRIs están contratados en un incidente determinado. Tener menos DRI comprometidos puede dar lugar a un tiempo de respuesta largo, sobre todo si no se comprometen recursos adicionales cuando deberían. Sin embargo, junto con el TTD y el TTE, es un buen indicador de la eficacia de nuestro monitoreo y diagnóstico para que la alerta llegue pronto al interviniente adecuado.

Del mismo modo, mientras trabajábamos para mejorar el TTD, nos dimos cuenta de que era 10 veces mayor cuando la interrupción era detectada por nuestros clientes en lugar de ser detectada por el monitoreo. Para medirlo, instrumentamos la tasa de autodetección como métrica sustitutiva del TTD. Esto no significa que todos los incidentes de autodetección tengan un buen TTD, pero la detección automatizada es necesaria para obtener un buen TTD. Como es típico de las métricas sustitutas, la detección automatizada es necesaria, pero no suficiente para conseguir un TTD de primera clase.

No se trata de una lista completa de métricas sustitutas, sino sólo de algunos ejemplos para empezar.

Reparar la deuda

Algunos de los mejores conocimientos que obtuvimos durante la revisión métrica procedían del proceso de revisión posterior al incidente. Ya hay mucho material excelente por ahí, así que no voy a profundizar en cómo hacer un buen postmortem (consulta "Lecturas complementarias" para ver algunos ejemplos). Iré directamente a lo que más importa para nuestras revisiones métricas: cada vez que identificamos un error o una oportunidad de mejora, lo registramos y lo registramos como una reparación. Los elementos de reparación son arreglos tecnológicos o de procesos que evitan que se repita una interrupción o reducen su duración. Normalmente, se dividen en elementos a corto plazo y elementos a largo plazo. Los elementos a corto plazo deben desplegarse rápidamente (en una semana) y pueden ser un proceso, un script o un hotfix. Los elementos a largo plazo son correcciones más duraderas, como correcciones de código más exhaustivas (es decir, corregir una clase de problema frente a una instancia de un problema, o corregir una clase de problema en varias líneas de productos), crear un cambio de proceso más amplio (es decir, crear e impartir formación sobre gestión de incidentes en varias organizaciones), o crear herramientas como bots de chat o autoescalado/mitigación. Los elementos de reparación se suelen rastrear en el mismo sistema de gestión del trabajo que utilizas para rastrear los elementos de trabajo del producto, pero lo que importa es que se registren y se pueda informar sobre ellos, y que se distingan de la cartera de pedidos estándar del producto.

El seguimiento de los elementos de reparación nos permite incorporar la deuda operativa al proceso de ingeniería estándar y tratarla igual que el trabajo de características. El diagrama de la Figura 4-4 es un buen ejemplo de lo que ocurre cuando empezamos a hacer un seguimiento de las reparaciones. Suele haber un pico inicial de deuda cuando empezamos a sacar a la luz acciones de reparación antes desconocidas o desenfocadas. Luego, el equipo ajusta sus prácticas para incorporar la deuda de reparación a su ritmo normal de trabajo, y la deuda de reparación desciende. El seguimiento de la deuda de reparación es importante porque estos problemas siempre existieron, pero hasta que no se rastrearon, midieron y compartieron, el equipo de ingeniería no pudo tomar medidas para mejorar el servicio. Esto ayuda a proporcionar una señal al equipo, junto con el presupuesto de errores, sobre cómo priorizar el trabajo de fiabilidad del servicio frente al trabajo de características.

Figura 4-4. Ejemplo de gráfico de deuda de reparación

Deuda de reparación virtual: exorcizar al fantasma de la máquina

No todas las películas tienen un final de Hollywood, y descubrimos que no todos los servicios veían los frutos del rigor en las partidas de reparación. En algunos casos, aunque la deuda por reparaciones era estable, la fiabilidad mes a mes no mejoraba necesariamente. Para estos servicios que tenían una deuda de reparación estable pero no veían mejoras en la fiabilidad, estábamos desconcertados. ¿Por qué no mejoraban si la deuda por reparaciones era estable y parecían bien atendidos? Profundizamos en algunos datos que aún no habíamos analizado, hicimos nuestra mejor imitación de Sherlock Holmes y descubrimos algo sorprendente. Algunos servicios no realizaban un RCA exhaustivo y, como resultado, tenían tasas bajas de finalización de RCA o RCA sin suficientes reparaciones. Esto significaba que los elementos de reparación nunca llegaban a la lista de pendientes y el servicio no tenía la oportunidad de mejorar.

Esto planteó un nuevo reto: ¿cómo medimos la calidad de un postmortem? No sólo tenemos que medir si los elementos de reparación se solucionaron, sino también si se crearon en primer lugar. La mayoría de los postmortem incluyen mucho texto que describe el problema y lo que se hizo para mitigarlo. Ciertamente, podríamos aplicar algo de aprendizaje automático al texto e intentar descifrar la intención, pero eso requeriría una inversión significativa y no sería determinista.

La solución más sencilla estaba delante de nosotros todo el tiempo, en forma de las métricas de "Tiempo para" que adjuntamos a cada incidente y a cada postmortem. Cualquier incidente que no cumpliera un objetivo de tiempo para detectar, comprometer o mitigar debía tener un elemento de reparación correspondiente. Esto significaba que teníamos que tener una taxonomía en el proceso de reparación para adjuntar indicadores de compromiso, diagnóstico y detección, de modo que pudiéramos extraer programáticamente "elementos de reparación perdidos". Luego utilizamos todos los elementos de reparación omitidos para medir lo que llamamos "deuda de reparación virtual".

Visualizar la deuda de reparación virtual se convirtió en una poderosa herramienta para impulsar mejoras. Como se ve en la Figura 4-5, la línea gris que representa la deuda de reparaciones hace que parezca que el equipo está al día con la deuda de reparaciones, pero cuando añades la línea roja punteada que representa las reparaciones omitidas, los elementos de reparación de materia oscura que forman la deuda virtual se hacen patentes. La deuda virtual es especialmente importante porque representa el corpus de elementos de reparación que nunca se registraron y que acabarán perjudicando al servicio en el futuro. Cuando hay deuda virtual, los fallos específicos de TTD y TTM se repetirán una y otra vez hasta que se registren y reparen.

Figura 4-5. Gráfico de la deuda virtual de reparación

Cuadros de mando en tiempo real: El pan y la mantequilla de la SRE

Posiblemente, la parte más importante de la revisión de las métricas sea llevar las métricas y las percepciones a cuadros de mando en tiempo real. Mirar los datos mensualmente o incluso semanalmente no ayuda a impulsar el cambio con suficiente rapidez. Cada servicio, cada componente, necesita poder ver en tiempo real dónde tiene trabajo por hacer, dónde lo está haciendo bien y dónde puede mejorar. Esto significaba crear cuadros de mando que pudieran pivotar por servicio, por responsable, incluso hasta el ingeniero individual propietario del elemento de trabajo.

Aprendizajes: TL;DR

Si quieres simplificarlo todo de este capítulo en una frase, aquí la tienes: mídelo todo, sé implacablemente curioso y no tengas miedo de ensuciarte y revolcarte en tus datos para encontrar las acciones correctas que hay que emprender. En muchos casos, obtener estas percepciones requirió curar a mano un buen montón de datos, pero después de comprender qué métricas importaban, pudimos instrumentarlas y automatizarlas y ayudar a dar visibilidad a las métricas que podían ayudar a mejorar los servicios.

Otras lecturas

Postmortems sin culpa:

• "Postmortems sin culpa y una cultura justa": John Allspaw, Etsy

• "Acciones Postmortem: Planificar el Trabajo y Trabajar el Plan": Sue Lueder y Betsy Beyer, Google

• Más allá de la culpa: aprender del fracaso y del éxito: Dave Zwieback

Utilizar los datos para obtener información operativa:

• "Mejora de las operaciones mediante el análisis de datos": Parviz Deyhim y Arti Garg, Datapipe

• "Análisis de incidentes": Sue Lueder, Google

• "Midiendo el éxito de la gestión de incidencias en Atlassian": Gerry Millar, Atlassian

• "PDA: Una herramienta para la determinación automatizada de problemas": Hai Huang, Raymond Jennings III, Yaoping Ruan, Ramendra Sahoo, Sambit Sahu y Anees Shaikh, Centro de Investigación IBM T.J. Watson

Biografía del colaborador

Martin Check es director de ingeniería de fiabilidad de sitios en el equipo de Microsoft Azure. Ha trabajado en servicios a gran escala en Microsoft durante 14 años en una variedad de funciones, incluyendo diseño e implementación de servicios, respuesta a crisis, gestión de problemas, e incluso liderando equipos a través de la transición DevOps/SRE. En la actualidad, Martin trabaja como gestor de SRE para equipos globales de SRE, donde sigue aprovechando las perspectivas de los datos para impulsar las mejoras de SRE.