Reducir el MTTR no es resolver incidentes más rápido

El indicador que todos quieren reducir

A lo largo de esta serie sobre Operaciones Modernas de TI, vimos que muchas organizaciones siguen enfrentando desafíos que van mucho más allá de la disponibilidad de herramientas. Discutimos por qué tantas operaciones todavía pasan buena parte del tiempo apagando incendios, cómo el crecimiento de la observabilidad terminó acompañado por una explosión en el volumen de alertas, por qué detectar un incidente es relativamente simple, pero construir el contexto necesario para identificar su causa raíz sigue siendo uno de los mayores desafíos de las operaciones y cómo la observabilidad dejó de ser solo un conjunto de herramientas para convertirse en una nueva forma de operar.

Estas reflexiones nos conducen naturalmente a uno de los indicadores más seguidos por las organizaciones: el MTTR (Mean Time to Recovery o Mean Time to Restore), la métrica que representa el tiempo necesario para restablecer un servicio tras la ocurrencia de un incidente. Presente entre los principales indicadores utilizados para evaluar la eficiencia operacional, forma parte del día a día de los equipos de infraestructura, SRE, NOC e ingeniería de plataformas.

No por casualidad, el MTTR también figura entre las métricas seguidas por los frameworks modernos de ingeniería de confiabilidad, como las métricas DORA, que utilizan el tiempo de recuperación de servicios como uno de los parámetros para evaluar el desempeño operacional de las organizaciones.

Durante muchos años, reducir el MTTR parecía una consecuencia natural de la evolución tecnológica.

A medida que surgían nuevas herramientas, creíamos que los incidentes se resolverían cada vez más rápido. Automatizamos procedimientos operacionales, desarrollamos mecanismos de rollback, perfeccionamos pipelines de despliegue, ampliamos la cobertura del monitoreo e invertimos en plataformas capaces de identificar anomalías pocos segundos después de su aparición. En paralelo, los equipos pasaron a documentar procedimientos, crear playbooks y estandarizar procesos de respuesta a incidentes.

Era razonable imaginar que toda esa evolución produciría operaciones significativamente más rápidas.

En muchos aspectos, realmente lo hizo.

Hoy logramos detectar indisponibilidades en cuestión de segundos, activar automáticamente a los equipos responsables, ejecutar rutinas de recuperación sin intervención humana y seguir prácticamente todo lo que ocurre dentro de un entorno tecnológico. Si comparamos esas capacidades con las disponibles hace quince o veinte años, la diferencia es impresionante.

Aun así, basta conversar con profesionales que viven el día a día de un NOC, de un equipo de SRE o de un centro de operaciones para percibir una sensación bastante conocida. A pesar de toda esa evolución, algunos incidentes siguen consumiendo mucho más tiempo del que deberían. No porque la solución técnica sea particularmente compleja, sino porque descubrir qué solución debe aplicarse se ha vuelto un desafío cada vez mayor.

Esta percepción empezó a llamar mi atención acompañando proyectos en organizaciones de distintos sectores. Cambiaban las herramientas, cambiaban las arquitecturas, cambiaban los niveles de madurez operacional. El patrón, sin embargo, seguía siendo prácticamente el mismo. Cuando ocurría un incidente importante, la mayor parte del tiempo inicial no se consumía corrigiendo el problema, sino intentando comprenderlo.

A primera vista, esa diferencia parece solo una cuestión de interpretación. En la práctica, cambia por completo la forma en que vemos el propio MTTR.

Siempre que analizamos este indicador, nuestra tendencia natural es imaginar que mide la velocidad con que un equipo logra restaurar un servicio. La palabra “recuperación” nos lleva de inmediato a la ejecución técnica. Pensamos en reiniciar aplicaciones, restaurar servidores, revertir despliegues, aumentar capacidad computacional o sustituir componentes defectuosos.

Esa imagen, sin embargo, representa solo una parte de la realidad.

Antes de que ocurra cualquiera de esas acciones, existe una etapa silenciosa, poco visible y, muchas veces, responsable de la mayor parte del tiempo consumido durante un incidente. Es el período en el que el equipo todavía intenta responder la pregunta más importante de todas:

¿Qué está pasando realmente?

La parte más lenta de un incidente rara vez aparece en los indicadores

Imagine una gran empresa de comercio electrónico en un día de alta demanda, durante una campaña promocional que concentra miles de accesos simultáneos y mueve una parte relevante de la facturación diaria.

Poco después del inicio de las ventas, el monitoreo empieza a registrar un aumento en el tiempo de respuesta de algunos servicios. Casi simultáneamente, la plataforma de observabilidad identifica un crecimiento en la latencia de determinadas APIs. El Service Desk empieza a recibir tickets de clientes que no logran concluir sus compras. El equipo responsable de las bases de datos percibe un aumento en las colas de procesamiento, mientras que los profesionales de infraestructura observan un consumo inusual de recursos en parte del entorno de nube. Al mismo tiempo, los indicadores de negocio empiezan a mostrar una caída inesperada en la conversión de las ventas.

Ninguna de esas informaciones es incorrecta. Todas representan síntomas reales. El problema es que ninguna de ellas explica, por sí sola, el origen del incidente.

En ese momento, nadie puede afirmar si todas esas señales forman parte del mismo problema, si hay múltiples incidentes ocurriendo al mismo tiempo o si algunas alertas son solo consecuencias de una falla iniciada en otro punto de la arquitectura.

Es exactamente en ese instante que comienza el verdadero trabajo de la operación.

Los analistas pasan a comparar dashboards, revisar logs, consultar cambios recientes, verificar dependencias entre aplicaciones, confirmar los despliegues realizados en las últimas horas e intercambiar hipótesis con otros equipos. Poco a poco, lo que parecía un conjunto desordenado de eventos empieza a ganar coherencia. Algunas posibilidades se descartan, otras pasan a tener más sentido y surgen nuevas evidencias a medida que las hipótesis anteriores dejan de explicar el comportamiento observado.

Solo después de que esa comprensión empieza a formarse el equipo logra decidir cuál debe ser la primera acción técnica.

Curiosamente, cuando el incidente termina, todo ese proceso suele desaparecer detrás de un único número.

El informe ejecutivo dirá que el MTTR fue de sesenta, noventa o ciento veinte minutos. El indicador se comparará con períodos anteriores, se discutirán metas y se definirán nuevos planes de acción. Casi nunca, sin embargo, ese número revela dónde se consumió efectivamente el tiempo.

Esa diferencia ayuda a explicar por qué organizaciones con herramientas semejantes, profesionales igualmente experimentados y niveles comparables de automatización presentan resultados tan distintos ante incidentes parecidos. En muchos casos, la velocidad de la recuperación está menos relacionada con la rapidez con que se ejecuta una solución que con la rapidez con que el equipo logra comprender el problema que necesita resolver.

Esta quizá sea una de las transformaciones más importantes por las que han pasado las operaciones de TI en los últimos años. Durante mucho tiempo, reducir el MTTR significaba acelerar los procedimientos de recuperación. Hoy, cada vez más, significa reducir el tiempo necesario para transformar decenas o cientos de señales aparentemente desconectadas en una explicación consistente de lo que realmente ocurrió.

Este cambio no ocurrió porque los equipos hayan perdido eficiencia. Ocurrió porque la propia naturaleza de los entornos tecnológicos cambió. Y es justamente esa transformación la que empezaremos a explorar a continuación.

La complejidad cambió de lugar

Durante mucho tiempo, la complejidad de las operaciones de TI estuvo concentrada en la propia infraestructura. Grandes datacenters, equipos especializados, enlaces redundantes y entornos altamente centralizados exigían un conocimiento técnico profundo para mantenerse en funcionamiento.

La operación era desafiante porque la tecnología era compleja. Hoy, ese escenario cambió significativamente.

La infraestructura se volvió más estandarizada, más automatizada y, en muchos aspectos, más simple de administrar. La computación en la nube redujo el esfuerzo para aprovisionar nuevos entornos. Los contenedores estandarizaron el despliegue de aplicaciones. Las plataformas gestionadas pasaron a asumir actividades que antes exigían equipos especializados. La infraestructura como código trajo repetibilidad a procesos que históricamente dependían de intervención manual.

Sería natural imaginar que, ante esa evolución, las operaciones también se volverían más simples.

Lo que ocurrió, sin embargo, fue algo diferente. La complejidad no desapareció. Migró de la infraestructura a las relaciones entre los componentes que forman los entornos modernos.

En lugar de estar concentrada dentro de un servidor, de un equipo de red o de una base de datos específica, pasó a existir en la forma en que cientos de componentes necesitan funcionar de manera coordinada. Un servicio aparentemente simple puede depender de decenas de microservicios, APIs, colas de mensajes, bases de datos distribuidas, servicios gestionados en la nube e integraciones con proveedores externos.

Cada uno de esos elementos puede operar correctamente de forma aislada y, aun así, la experiencia final del usuario verse completamente comprometida. Este cambio es sutil, pero altera profundamente la manera en que un incidente necesita ser investigado.

Cuando causa y síntoma dejan de coincidir

Hace algunos años, cuando una aplicación presentaba indisponibilidad, era relativamente común que el origen del problema estuviera cerca del propio síntoma. Un servidor sobrecargado, una interfaz de red con falla, una base de datos indisponible o un error de configuración normalmente explicaban buena parte del comportamiento observado.

Naturalmente había excepciones, pero en la mayoría de las situaciones la relación entre causa y efecto era lo bastante directa para orientar rápidamente la investigación. En las arquitecturas actuales, esa proximidad prácticamente dejó de existir.

Un aumento en el tiempo de respuesta percibido por el usuario puede originarse en un cambio de configuración realizado horas antes en un servicio aparentemente sin relación con esa aplicación.

Un pequeño aumento de latencia en una API puede provocar colas en otro componente que, a su vez, degrada un tercer servicio y produce síntomas completamente diferentes de los generados por la causa original. En pocos minutos, el incidente deja de ser un evento localizado y pasa a propagarse por toda la arquitectura como una cadena de efectos sucesivos.

En este contexto, el desafío deja de ser identificar dónde apareció la primera alerta. El verdadero desafío pasa a ser comprender cómo se relacionan todos esos eventos.

Esta quizá sea una de las mayores diferencias entre operar una infraestructura tradicional y operar un entorno distribuido moderno.

Escasez de contexto, no de datos

El volumen de información dejó de ser el principal problema.

Hoy, prácticamente todas las organizaciones logran recolectar métricas, logs, traces, eventos de infraestructura, indicadores de aplicaciones e información sobre la experiencia del usuario. En muchos entornos hay, incluso, información en exceso.

Lo que sigue siendo escaso es la capacidad de transformar todo eso en una explicación consistente de lo que realmente está ocurriendo. Esta distinción cambia por completo la forma en que interpretamos un incidente.

Cuando distintas herramientas presentan decenas de alertas simultáneas, nuestra primera reacción suele ser descubrir cuál de ellas “encontró” primero el problema. En la práctica, sin embargo, ninguna herramienta encontró el problema completo. Cada una registró solo lo que era capaz de observar desde su propia perspectiva.

El monitoreo identifica cambios de disponibilidad. La observabilidad evidencia cambios de comportamiento. Las herramientas de APM muestran la degradación del desempeño. Los logs registran eventos específicos. Las plataformas de ITSM informan el impacto percibido por los usuarios.

Todas esas informaciones son correctas. Ninguna de ellas, por sí sola, representa el incidente.

Es justamente por eso que las organizaciones más maduras dejaron de invertir solo en ampliar la recolección de datos y pasaron a concentrar esfuerzos en la construcción de contexto. El objetivo dejó de ser simplemente ver más componentes de la arquitectura. Pasó a ser comprender cómo se relacionan esos componentes durante un evento operacional.

Esta diferencia puede parecer solo conceptual, pero produce efectos extremadamente concretos en el día a día de los equipos.

Cuando el contexto tarda en construirse, distintos especialistas inician investigaciones paralelas, cada uno concentrado en la parte del entorno de la que es responsable. Infraestructura analiza infraestructura. Base de datos analiza base de datos. Redes investigan redes. Desarrollo revisa aplicaciones. Cloud verifica recursos computacionales. Todos trabajan intensamente, pero no siempre trabajan sobre el mismo problema.

No se trata de falta de competencia ni de falta de dedicación. Lo que con frecuencia falta es una visión compartida capaz de conectar todas esas piezas antes de que el tiempo siga corriendo.

Es en ese momento cuando empezamos a percibir que el MTTR no depende solo de la calidad de las personas ni de la eficiencia de las herramientas. Depende, sobre todo, de la velocidad con que una organización logra transformar información fragmentada en una comprensión colectiva del incidente.

Esta quizá sea la actividad más difícil de las operaciones modernas, no porque falten datos, sino porque nunca produjimos tantos datos, distribuidos en tantos lugares diferentes, para explicar un único problema.

Esa es la nueva complejidad con la que las operaciones conviven a diario. Una complejidad que no está escondida dentro de la tecnología, sino distribuida entre las innumerables relaciones que la propia tecnología pasó a establecer. Es justamente en ese entorno donde el tiempo invisible del MTTR empieza a consumirse, mucho antes de que se ejecute la primera acción correctiva.

Cuando cada equipo ve solo una parte del problema

Existe una característica presente en prácticamente todas las operaciones modernas que rara vez recibe la atención que merece. Cuanto mayor es la organización, mayor tiende a ser el nivel de especialización de los equipos responsables de sostenerla.

Esa evolución fue necesaria. Al fin y al cabo, sería inviable esperar que un único profesional dominara, con la misma profundidad, infraestructura en la nube, redes, bases de datos, Kubernetes, seguridad, observabilidad, desarrollo de aplicaciones, integración continua y experiencia del usuario. La especialización hizo a los equipos más eficientes, elevó la calidad técnica y permitió que las organizaciones acompañaran la creciente sofisticación tecnológica de los últimos años.

También produjo un efecto colateral importante.

A medida que cada equipo pasó a conocer profundamente una parte de la arquitectura, se volvió cada vez más difícil que existiera alguien capaz de comprender la arquitectura como un todo.

Esta situación queda particularmente evidente durante un incidente crítico.

Los profesionales de infraestructura empiezan verificando el consumo de CPU, memoria, discos, máquinas virtuales y clusters. Los especialistas en bases de datos analizan conexiones, consultas lentas, bloqueos y colas de procesamiento. El equipo responsable de las aplicaciones revisa logs, despliegues recientes y métricas de desempeño. Redes investigan latencia, pérdida de paquetes y utilización de enlaces. Seguridad verifica eventos que puedan indicar bloqueos o ataques, mientras el Service Desk sigue recibiendo nuevos tickets y los gestores acompañan, bajo presión creciente, el impacto sobre el negocio.

Ninguno de esos equipos está siguiendo un camino equivocado. En realidad, todos están haciendo exactamente lo que deberían hacer. El problema es que cada uno observa el incidente por una ventana diferente.

Cada grupo tiene herramientas propias, indicadores específicos, lenguajes distintos y prioridades naturalmente alineadas con sus responsabilidades. Individualmente, todas esas visiones tienen sentido. Colectivamente, sin embargo, rara vez producen una comprensión inmediata de lo que está ocurriendo.

Es como intentar armar un rompecabezas en el que cada persona tiene solo algunas piezas y nadie conoce la imagen completa. Cuanto mayor es el número de piezas, mayor es el esfuerzo necesario para descubrir cómo se conectan.

Quizá sea justamente por eso que los grandes incidentes suelen movilizar a tanta gente al mismo tiempo. No porque todos sean necesarios para ejecutar la solución técnica, sino porque alguien necesita reunir interpretaciones diferentes hasta que una explicación única empiece a tener sentido.

El verdadero acelerador del MTTR

Durante muchos años, nos acostumbramos a asociar operaciones más maduras con operaciones más automatizadas. Esa relación sigue siendo verdadera, pero quizá ya no sea suficiente para explicar por qué algunas organizaciones logran responder a los incidentes con mucha más eficiencia que otras.

Cuando observamos empresas reconocidas por su excelencia operacional, es común imaginar que la diferencia está en tecnologías más sofisticadas o en equipos significativamente más experimentados. Esos factores sin duda influyen. Sin embargo, al analizar cómo esas organizaciones conducen sus procesos de respuesta a incidentes, emerge un patrón menos evidente, pero probablemente más importante.

No se diferencian solo por la velocidad con que ejecutan procedimientos técnicos. Se diferencian, sobre todo, por la velocidad con que construyen una comprensión compartida del incidente.

Esta distinción es sutil, pero altera por completo la forma en que interpretamos el MTTR.

Imagine dos organizaciones con arquitecturas semejantes, herramientas equivalentes y equipos igualmente calificados. Ocurre en ambas un incidente prácticamente idéntico. Al final de la investigación, las dos llegan a la misma conclusión técnica y aplican exactamente la misma corrección. Aun así, una restaura el servicio en cuarenta minutos, mientras que la otra tarda dos horas.

¿Qué explica esa diferencia?

Difícilmente la respuesta estará en los últimos minutos del incidente, cuando finalmente se aplicó la solución. En la mayoría de los casos, estará concentrada en la primera hora, cuando los equipos todavía intentaban descubrir cuál era, de hecho, el problema que necesitaban resolver.

Esta percepción ayuda a comprender por qué algunas organizaciones logran reducir continuamente sus indicadores operacionales incluso sin cambios radicales en la infraestructura. La ganancia no viene necesariamente de la ejecución más rápida de procedimientos técnicos. Resulta de la reducción del tiempo gastado eliminando hipótesis incorrectas, correlacionando información dispersa, comprendiendo relaciones de dependencia y construyendo una visión común del incidente antes de tomar la decisión.

Es como llegar a un cruce desconocido. Quien conoce el camino recorre solo el tiempo necesario para llegar al destino. Quien todavía intenta descubrir qué carretera seguir puede permanecer mucho más tiempo detenido que efectivamente conduciendo.

En las operaciones de TI ocurre algo semejante.

La recuperación propiamente dicha suele representar solo la etapa final de un proceso mucho mayor. Antes de ella existe un recorrido invisible, compuesto por investigación, interpretación, validación de evidencias, eliminación de hipótesis y toma de decisiones. Cuanto más rápidamente se concluye ese recorrido, menor tiende a ser el MTTR.

Este cambio de perspectiva también ayuda a explicar por qué tantas organizaciones siguen enfrentando dificultades incluso después de ampliar significativamente sus inversiones en observabilidad.

La observabilidad representa un avance extraordinario. Amplía nuestra capacidad de comprender el comportamiento de los sistemas, permitiendo analizar no solo que algo falló, sino también cómo esa falla evolucionó a lo largo del tiempo. Sin embargo, ver más no significa, automáticamente, comprender más.

Un entorno moderno puede producir millones de métricas, miles de millones de logs y miles de traces todos los días. Ninguno de esos datos, por sí solo, responde la pregunta que moviliza a toda la operación durante un incidente: ¿cuál es la explicación más probable de todo lo que se está observando?

Es justamente en este punto donde empieza a surgir una nueva capa de madurez operacional.

Durante muchos años invertimos para ampliar nuestra capacidad de recolección de información. Hoy, el desafío pasa a ser reducir el esfuerzo necesario para conectar esa información y transformarla en entendimiento.

Este quizá sea el principal cambio por el que están pasando las operaciones modernas. El problema dejó de ser la falta de visibilidad. Pasó a ser el exceso de fragmentación.

Cuando cada herramienta presenta solo una parte de la realidad, la responsabilidad de conectar todas esas partes termina recayendo sobre las personas. Son ellas quienes necesitan comparar horarios, identificar relaciones de dependencia, correlacionar eventos, interpretar comportamientos aparentemente independientes y construir una narrativa capaz de explicar el incidente.

Cuanto más distribuido el entorno, mayor tiende a ser ese esfuerzo cognitivo.

Y cuanto mayor ese esfuerzo, mayor tiende a ser el tiempo invisible que antecede a cualquier acción correctiva.

Quizá sea justamente por eso que tantas organizaciones creen estar enfrentando un problema de velocidad cuando, en realidad, enfrentan un problema de comprensión.

No faltan profesionales competentes. No faltan herramientas. No faltan datos.

Lo que frecuentemente falta es un mecanismo capaz de reducir el intervalo entre el momento en que aparecen las primeras señales y el instante en que la operación logra comprender, con seguridad, lo que realmente está ocurriendo.

Es en ese intervalo donde el MTTR empieza a decidirse.

Mucho antes de la recuperación. Mucho antes de la ejecución técnica. Mucho antes de la primera acción correctiva. Es ahí donde las operaciones maduras empiezan a diferenciarse de las demás.

Comprender primero. Resolver después.

A lo largo de esta serie de artículos, vimos cómo las operaciones de TI pasaron por una transformación profunda.

En el primer artículo, discutimos por qué tantos equipos siguen apagando incendios incluso rodeados de herramientas cada vez más sofisticadas.

En el segundo, reflexionamos sobre la paradoja de monitorear prácticamente todo y, aun así, convivir con un volumen creciente de alertas.

Este artículo añade una pieza más a esa misma reflexión al mostrar que reducir el MTTR depende, ante todo, de la capacidad de comprender rápidamente lo que realmente está ocurriendo.

Quizá el MTTR nunca haya sido solo un indicador de recuperación.

Cada vez más, se convierte en un indicador de la capacidad que posee una organización para construir entendimiento frente a un incidente.

Esa diferencia parece pequeña. En la práctica, cambia por completo las prioridades de la operación.

Si el mayor consumo de tiempo ocurre antes de la ejecución técnica, reducir el MTTR deja de significar solo automatizar procedimientos o acelerar correcciones. Pasa a significar reducir el tiempo necesario para construir entendimiento, conectar información dispersa y ofrecer a los equipos condiciones para tomar mejores decisiones en el menor intervalo posible.

En otras palabras, el verdadero acelerador del MTTR no es ejecutar más rápido. Es comprender más temprano.

En los próximos años, seguiremos produciendo volúmenes cada vez mayores de datos operacionales. Seguiremos ampliando nuestra capacidad de monitoreo y observabilidad. Seguiremos automatizando procesos que hoy todavía dependen de intervención humana.

Nada de eso, sin embargo, eliminará el principal desafío de las operaciones modernas: transformar información en entendimiento.

Porque, al final, los incidentes nunca fueron solo problemas técnicos. Son, ante todo, problemas de comprensión.

Es justamente por eso que las próximas grandes transformaciones en las operaciones de TI probablemente no estarán relacionadas con la capacidad de generar más datos, sino con la capacidad de ayudar a los equipos a comprender, en pocos segundos, lo que hoy lleva largos minutos y, en algunos casos, horas descubrir.

Es exactamente en este punto donde la Inteligencia Artificial empieza a dejar de ser solo una promesa tecnológica para asumir un papel estratégico en las operaciones modernas.

Pero ese ya es el tema del próximo artículo.

Para reflexionar

Las operaciones modernas no sufren por falta de datos. Sufren por la dificultad de transformar datos en entendimiento.

Cuanto más distribuidos se vuelven los entornos tecnológicos, mayor pasa a ser el desafío de conectar información, identificar relaciones de causa y efecto y comprender rápidamente lo que realmente está ocurriendo.

Quizá sea justamente esa la próxima frontera de la evolución de las operaciones de TI: no producir más información, sino ofrecer a los equipos el contexto necesario para tomar mejores decisiones, con más rapidez y más confianza.

Porque reducir el MTTR nunca fue solo una cuestión de recuperar servicios más rápidamente. Es, ante todo, una cuestión de comprender los incidentes antes de que se conviertan en impactos para el negocio.

Sobre el autor

Paulo Florêncio de Menezes es emprendedor, socio y cofundador de empresas como Target Solutions, BiPTT y ARGUS.

Es graduado en Procesamiento de Datos por la Universidad Federal del Amazonas (UFAM), tiene un MBA en Gestión Empresarial por la Fundação Dom Cabral (FDC) y una Maestría Profesional en Economía por la Fundação Getulio Vargas (FGV).

En su investigación de Maestría, desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.