Atlassian considera que el análisis de la causa raíz de incidentes en entornos de microservicios ya no puede depender únicamente de la revisión manual. Cuando cientos de servicios interconectados operan en varias regiones, un solo fallo genera una gran cantidad de métricas, registros y trazas, mientras que el ingeniero de guardia suele verse obligado a desplazarse entre paneles separados y construir una hipótesis mental sobre el origen del problema y su trayectoria de propagación.
En una publicación del blog de la CNCF, Santosh Balaranganathan, Michael Yoo, James Moessis, James Kieltyka, Jason Lee y Lavender Neesham, de Atlassian, explican un sistema automatizado para el análisis de la causa raíz cuyo objetivo es automatizar la generación de hipótesis, de modo que el equipo de respuesta pueda pasar más rápidamente a la fase de verificación y remediación, en lugar de volver a reunir las pruebas manualmente.
Convertir el análisis de la causa raíz en un problema de correlación de múltiples señales
El diseño se basa en vincular tres capas de evidencia: el tipo de señal, el tiempo y la topología de los servicios. Las señales incluyen métricas, registros y trazas, mientras que la sincronía temporal determina qué eventos pueden estar relacionados, y el grafo de dependencias de servicios ayuda a distinguir entre el servicio que inició el fallo y aquel que se vio afectado posteriormente.
El proceso comienza reduciendo el alcance de la búsqueda mediante un mapa de servicios derivado de OpenTelemetry. En lugar de analizar todos los servicios de la plataforma, el sistema identifica los servicios que se encuentran en la ruta de la experiencia de usuario degradada, creando un alcance que normalmente incluye decenas de servicios en lugar de cientos. El mapa refleja las comunicaciones reales extraídas de las relaciones padre-hijo entre los segmentos temporales del tráfico de producción, no la estructura supuesta en la documentación.
De los datos de monitorización a las hipótesis ordenadas
Una vez definido el alcance, módulos independientes detectan anomalías en cada tipo de señal. En las métricas, Atlassian monitoriza los indicadores RED, es decir, la tasa de solicitudes, la tasa de errores y la duración de las respuestas, utilizando métodos estadísticos como la desviación absoluta mediana y los rangos de percentiles. Cada anomalía produce un valor de intensidad, el valor observado y la línea base respecto de la cual se desvió.
Las trazas distribuidas se examinan en busca de excepciones inesperadas, nuevos patrones de propagación de errores y aumentos de la latencia en segmentos concretos. Los registros utilizan técnicas de agrupación basadas en embeddings para reunir entradas semánticamente similares y, después, destacar grupos de errores nuevos o poco frecuentes en comparación con la distribución habitual del servicio.
Todos los detectores convierten sus resultados en eventos con un esquema unificado que incluye la marca de tiempo, el nombre del servicio, el tipo de señal, el nivel de intensidad y los detalles. Esta capa permite al motor de correlación analizar los eventos sin depender del método mediante el cual cada detector identificó el estado. También permite añadir nuevos detectores o sustituir un modelo estadístico por otro basado en aprendizaje automático sin reconstruir todo el sistema.
El tiempo y el grafo de dependencias para determinar la dirección del fallo
El motor agrupa los eventos cercanos dentro de una ventana temporal configurable, normalmente de más o menos cinco minutos. Cada grupo recibe una puntuación de cohesión temporal: cuanto más cercanos estén los eventos, mayor será la probabilidad de que estén relacionados. Para evitar repetir la misma hipótesis decenas de veces, el sistema utiliza huellas digitales de las secuencias de servicios y combina las cadenas de fallo repetidas en un único grupo, junto con un recuento de las repeticiones. Así, puede describir un patrón de fallo que se repitió 47 veces en cinco minutos en lugar de crear 47 hipótesis idénticas.
A continuación, el sistema identifica el nodo más afectado, o lo que denomina nodo descendente, y luego se desplaza hacia atrás por el grafo de dependencias en busca de servicios anómalos que lo precedieron temporalmente. Si el servicio A llama al servicio B y el problema de B apareció antes que el de A, B se convierte en un candidato más fuerte como origen del fallo, mientras que el problema de A se trata como un efecto posterior. La evaluación final combina la cohesión temporal y la puntuación de la ruta de propagación para ordenar las hipótesis.
El resultado no se limita a una lista de servicios y puntuaciones de confianza. Cada hipótesis incluye el servicio sospechoso, la ruta de propagación y las pruebas presentes en cada nodo, como las métricas que superaron sus límites o los identificadores de las trazas relacionadas con el fallo, además de una narración en lenguaje humano que explica la secuencia de eventos y el motivo por el que se prioriza un origen determinado.
¿Por qué es importante esta metodología para los equipos de operaciones?
El valor práctico no reside en sustituir al ingeniero de respuesta, sino en reducir el tiempo necesario para llegar a una hipótesis que pueda comprobarse. Atlassian conecta el motor de análisis de la causa raíz con una plataforma más amplia de respuesta a incidentes, que incluye la detección del impacto del fallo en los usuarios, la identificación del equipo responsable y un asistente de incidentes capaz de sugerir acciones como revertir una versión o desactivar una marca de funcionalidad basándose en las pruebas disponibles. La plataforma también registra si los ingenieros aceptaron, rechazaron o modificaron la hipótesis para mejorar las ponderaciones con el tiempo.
La experiencia muestra que comenzar con métodos sencillos y explicables puede ser más adecuado que construir modelos complejos de aprendizaje automático para cada señal. Métodos como la desviación absoluta mediana y los rangos de percentiles fueron suficientes para detectar muchas anomalías en las métricas, mientras que se utilizaron técnicas de aprendizaje automático para agrupar registros y analizar la estructura de las trazas, donde los métodos estadísticos resultan menos adecuados.
Sin embargo, la metodología no elimina las limitaciones. La calidad de las hipótesis depende de la coherencia de los datos de monitorización, la precisión del grafo de dependencias de servicios y la capacidad de los detectores para distinguir entre un fallo real y el ruido. Además, la puntuación de confianza no constituye una prueba definitiva de causalidad; por ello, Atlassian destaca la importancia de mostrar el origen de cada evidencia y la narración que la vincula con el resultado. La empresa también estudia utilizar posteriormente un formato basado en modelos de lenguaje que pueda solicitar datos adicionales y modificar las hipótesis, con requisitos de límites de tasa, ejecución aislada y un registro claro del origen de las pruebas.
Lectura editorial de certi.news: el cambio real de este enfoque consiste en trasladar el análisis de incidentes de la comparación manual entre herramientas separadas a un proceso unificado que integra la señal, el tiempo y la topología. Su éxito operativo dependerá de la explicabilidad, la calidad de los datos y los ciclos de retroalimentación, no únicamente del algoritmo de ordenación. Por ello, la modularidad, la eliminación de duplicaciones y la documentación de las pruebas parecen principios más aplicables de inmediato que la promesa de una automatización completa del análisis de la causa raíz.