Atlassian reconstruyó la plataforma de detección de incidentes que alimenta su sistema automatizado de creación de incidentes, basándose en Apache Kafka, Apache Flink sobre Kubernetes y OpenTelemetry. Según las mediciones publicadas después de 18 meses de trabajo, el tiempo que tardaba un evento en llegar a la métrica se redujo de más de 40 segundos a menos de 10 segundos, mientras que la capacidad sostenible aumentó de unos 500 millones de eventos diarios a más de mil millones de eventos diarios al utilizar un muestreo del 50 %.
El proyecto no se presenta como una historia de éxito completa. La tasa de recuperación de los incidentes incluidos en el ámbito de monitorización aumentó desde aproximadamente el 60 % hasta un máximo del 86 % en junio de 2026, antes de caer al 64 % en agosto. La precisión también permaneció por debajo del nivel objetivo, lo que llevó al equipo a separar la calidad del detector en sí del alcance de los productos y experimentos que habían sido equipados con instrumentación.
Una plataforma construida en torno al flujo de eventos
Atlassian gestiona más de diez productos en la nube para millones de inquilinos, y estos productos generan miles de millones de eventos diarios a partir de las interacciones de los usuarios. Los eventos incluyen el inicio y el resultado de la tarea, junto con datos sobre el inquilino, el usuario, el experimento y el código HTTP. La plataforma utiliza estos datos para responder rápidamente a tres preguntas: ¿existe un problema?, ¿cuál es el alcance de su impacto? y ¿qué equipo debe recibir una alerta y con qué nivel de gravedad?
En el nuevo diseño, los eventos se filtran en el bus de Apache Kafka en lugar de consumir todo el flujo dentro de la aplicación. El filtro de suscripción, de unas 770 líneas de YAML, se conserva como parte de la configuración del código. Después, una sola aplicación de Apache Flink 1.20 procesa los eventos en Kubernetes, los enriquece con datos del inquilino, envía las métricas mediante OpenTelemetry y agrupa el impacto de los incidentes en ventanas de 60 segundos.
El equipo utilizó Apache Parquet para almacenar los datos agregados y un almacén multirregional de valores clave, mientras que Impact API proporciona respuestas sobre el número de usuarios e inquilinos afectados. El motor AutoHOT convierte las alertas en incidentes, aplica una matriz de gravedad, evita las alertas transitorias y vuelve a evaluar el impacto cada minuto.
Ganancias de rendimiento y costes
- El número de máquinas virtuales se redujo de unas 90 máquinas, además de las capas de colas y caché, a cuatro contenedores de Kubernetes.
- El coste operativo mensual bajó de unos 20 000 dólares a aproximadamente 650 dólares, una disminución cercana al 97 %.
- La recuperación tras una interrupción del procesamiento pasó a ser posible mediante la reproducción de eventos de Kafka en unos 20 minutos, sin pérdida de datos.
- El tiempo de consulta del panel de impacto disminuyó de unos 10 segundos a aproximadamente un segundo.
- La coincidencia con el flujo antiguo alcanzó el 99,9 % durante una ejecución en paralelo de dos semanas.
El diseño utilizó HyperLogLog para contar los usuarios únicos afectados en lugar de conservar sus identificadores, con un error aproximado del 1,5 %. También se emplearon claves de almacenamiento idempotent para hacer que la reproducción de Kafka pudiera recuperarse sin duplicar filas. El equipo mantuvo los nombres de las métricas antiguas mediante un flujo de StatsD, lo que permitió que los paneles de SLO y los detectores existentes continuaran sin cambios durante la transición.
¿Por qué no bastan las cifras de rendimiento?
Los resultados de los incidentes revelan que acelerar el canal de datos no equivale necesariamente a mejorar la cobertura. Durante nueve meses se produjeron 263 incidentes importantes, pero solo 117 incidentes, es decir, el 44,5 %, afectaron a experimentos equipados con monitorización. De estos incidentes, se detectaron 80, lo que significa que el sistema capturó únicamente el 30,4 % del total de incidentes importantes de ese periodo.
La precisión también varió según el tipo de alerta. La precisión de los incidentes Sev2 creados automáticamente por el sistema fue de aproximadamente el 85 % durante el año fiscal, mientras que la precisión de las alertas tempranas de menor gravedad osciló entre el 70 % y el 79 %. La supresión de las oscilaciones contribuyó a reducir aproximadamente un 80 % los tickets rechazados por alertas transitorias. En cambio, el retraso del sistema de métricas hacía que una disminución de los datos se considerara cero, lo que generó una oleada de falsas alarmas; esto se solucionó añadiendo un retraso mínimo de 120 segundos a los detectores de disminución del volumen.
Limitaciones que permanecieron abiertas
El mayor problema lógico es que el silencio puede parecer salud. Una interrupción completa de una base de datos puede impedir que se cargue la página y, por tanto, no generar eventos de fallo. Del mismo modo, una interrupción del propio flujo de eventos puede dejar ciego al detector. Por ello, el equipo añadió detectores de disminución del volumen de datos y comprobaciones de actualidad de las métricas, y planea incorporar señales independientes como los errores 5xx del perímetro y los sondas sintéticas.
El equipo también descubrió que detectar el incidente y medir su impacto son dos problemas separados. En uno de los incidentes, el ticket se creó pronto, pero el sistema estimó el impacto en unos 2 000 usuarios, mientras que la cifra real superaba los 80 000. Además, la interfaz de Impact API colapsó bajo la presión de unos 100 usuarios simultáneos porque fusionaba los esquemas de HyperLogLog en el momento de la lectura sin agregación previa ni caché.
La principal debilidad sigue siendo que la puerta de enlace de eventos, la suscripción de Kafka y la función de Flink funcionan en una sola región, aunque el motor de decisiones opera en modo activo-activo en dos regiones. Esto significa que una avería regional podría mantener intacta la computación, pero inutilizar la propia fuente de detección.
La lectura editorial de certi.news
El valor principal de la experiencia de Atlassian no reside en elegir Flink o Kafka por separado, sino en vincular las decisiones de arquitectura con métricas operativas revisables: filtrado en el bus, claves idempotent, monitorización de la plataforma con las mismas herramientas de OpenTelemetry y distinción entre recall y cobertura. Los resultados muestran que mejorar la eficiencia puede reducir claramente el coste y el tiempo, pero no soluciona automáticamente las brechas de medición ni los incidentes que no producen señales útiles.
Atlassian planea trasladar los detectores a un almacén de series temporales alimentado mediante OpenTelemetry, ampliar el flujo de Flink a un modo activo-activo entre regiones y añadir agregación diaria y caché delante de Impact API. También aspira a que tanto el recall como la precisión superen el 90 % dentro del ámbito equipado con monitorización, con un tiempo P90 de detección de incidentes Sev3 inferior a 90 minutos. Estos siguen siendo objetivos futuros y no resultados alcanzados según el material publicado.