Atlassian a reconstruit la plateforme de détection des incidents qui alimente son système automatisé de création d’incidents, en s’appuyant sur Apache Kafka, Apache Flink sur Kubernetes et OpenTelemetry. Selon les mesures publiées après 18 mois de travail, le délai d’arrivée de l’événement jusqu’à la métrique est passé de plus de 40 secondes à moins de 10 secondes, tandis que la capacité soutenue est passée d’environ 500 millions d’événements par jour à plus d’un milliard d’événements par jour avec un échantillonnage à 50 %.
Le projet ne se présente pas comme une réussite achevée. Le taux de rappel des incidents entrant dans le périmètre de surveillance est passé d’environ 60 % à un pic de 86 % en juin 2026, avant de retomber à 64 % en août. La précision est également restée inférieure au niveau cible, ce qui a conduit l’équipe à distinguer la qualité du détecteur lui-même de l’étendue de la couverture des produits et des expériences instrumentés.
Une plateforme conçue autour d’un flux d’événements
Atlassian gère plus de dix produits cloud pour des millions de locataires, et ces produits génèrent chaque jour des milliards d’événements issus des interactions des utilisateurs. Les événements comprennent le début et le résultat de la tâche, ainsi que des données sur le locataire, l’utilisateur, l’expérience et le code HTTP. La plateforme utilise ces données pour répondre rapidement à trois questions : y a-t-il un problème ? Quelle est l’ampleur de son impact ? Et quelle équipe doit être alertée, avec quel niveau de gravité ?
Dans la nouvelle conception, les événements sont filtrés au niveau du bus Apache Kafka au lieu de consommer l’intégralité du flux dans l’application. Le filtre d’abonnement, d’environ 770 lignes de YAML, est conservé dans le cadre de la configuration logicielle. Une seule application Apache Flink 1.20 traite ensuite les événements sur Kubernetes, les enrichit avec des données sur les locataires, envoie les métriques via OpenTelemetry et agrège l’impact des incidents dans des fenêtres de 60 secondes.
L’équipe a utilisé Apache Parquet pour stocker les volumes agrégés, ainsi qu’un magasin de valeurs clés multirégion, tandis que l’Impact API fournit des réponses sur le nombre d’utilisateurs et de locataires affectés. Le moteur AutoHOT transforme les alertes en incidents, applique une matrice de gravité, bloque les alertes transitoires, puis réévalue l’impact chaque minute.
Gains de performance et de coût
- Le nombre de machines virtuelles est passé d’environ 90 machines, en plus des couches de files d’attente et de mise en cache, à quatre conteneurs Kubernetes.
- Le coût mensuel d’exploitation est passé d’environ 20 000 dollars à près de 650 dollars, soit une baisse d’environ 97 %.
- La récupération après un arrêt du traitement est devenue possible en rejouant les événements Kafka en environ 20 minutes, sans perte de données.
- Le délai d’interrogation du tableau de bord d’impact est passé d’environ 10 secondes à près d’une seconde.
- La concordance avec l’ancien pipeline a atteint 99,9 % au cours d’une exécution parallèle de deux semaines.
La conception s’est appuyée sur HyperLogLog pour calculer le nombre d’utilisateurs uniques affectés au lieu de conserver les identifiants des utilisateurs, avec une erreur d’environ 1,5 %. Des clés de stockage idempotent ont également été utilisées afin de rendre le rejeu de Kafka récupérable sans dupliquer les lignes. L’équipe a conservé les anciens noms de métriques via un pipeline StatsD, permettant aux tableaux de bord SLO et aux détecteurs existants de continuer à fonctionner sans modification lors de la transition.
Pourquoi les chiffres de performance ne suffisent-ils pas ?
Les résultats des incidents montrent qu’accélérer le pipeline de données ne signifie pas nécessairement améliorer la couverture. Sur neuf mois, 263 incidents majeurs se sont produits, mais seuls 117 incidents, soit 44,5 %, ont touché des expériences instrumentées. Parmi ces incidents, 80 ont été détectés, ce qui signifie que le système n’a capturé que 30,4 % de l’ensemble des incidents majeurs de cette période.
La précision variait également selon le type d’alerte. La précision des incidents Sev2 créés automatiquement par le système a atteint environ 85 % au cours de l’exercice fiscal, tandis que la précision des alertes précoces moins graves oscillait entre 70 % et 79 %. La suppression des oscillations a contribué à réduire d’environ 80 % les tickets rejetés liés aux alertes transitoires. En revanche, le retard du système de métriques conduisait à interpréter une baisse des données comme zéro, générant une vague de faux positifs ; le problème a été traité par l’ajout d’un délai minimal de 120 secondes aux détecteurs de baisse de volume.
Les limites encore ouvertes
Le principal problème logique est que le silence peut ressembler à un état sain. L’arrêt complet d’une base de données peut empêcher le chargement de la page et, par conséquent, ne produire aucun événement d’échec. De même, l’arrêt du pipeline d’événements peut rendre le détecteur aveugle. L’équipe a donc ajouté des détecteurs de baisse du volume de données et des contrôles de fraîcheur des métriques, et prévoit d’intégrer des signaux indépendants tels que les erreurs 5xx en périphérie et les sondes synthétiques.
L’équipe a également constaté que la détection de l’incident et la mesure de son impact sont deux problèmes distincts. Lors d’un incident, le ticket a été créé rapidement, mais le système a estimé l’impact à environ 2 000 utilisateurs, alors que le nombre réel dépassait 80 000. L’Impact API s’est également effondrée sous la charge d’environ 100 utilisateurs simultanés, car elle fusionnait les schémas HyperLogLog au moment de la lecture, sans préagrégation ni mise en cache.
Le principal point faible demeure le fait que la passerelle d’événements, l’abonnement Kafka et la fonction Flink fonctionnent dans une seule région, alors que le moteur de décision fonctionne selon un modèle actif-actif dans deux régions. Cela signifie qu’une panne régionale peut laisser le calcul opérationnel tout en désactivant la source de détection elle-même.
Lecture éditoriale de certi.news
La valeur fondamentale de l’expérience d’Atlassian ne réside pas dans le choix isolé de Flink ou de Kafka, mais dans le lien établi entre les décisions d’architecture et des métriques opérationnelles vérifiables : filtrage au niveau du bus, clés idempotent, surveillance de la plateforme avec les mêmes outils OpenTelemetry et distinction entre recall et coverage. Les résultats montrent que l’amélioration de l’efficacité peut réduire clairement les coûts et les délais, mais qu’elle ne comble pas automatiquement les lacunes de mesure ni les incidents qui ne produisent pas de signaux côté client.
Atlassian prévoit de déplacer les détecteurs vers un magasin de séries temporelles alimenté via OpenTelemetry, d’étendre le pipeline Flink à un modèle actif-actif entre les régions et d’ajouter une agrégation quotidienne ainsi qu’une mise en cache devant l’Impact API. L’entreprise vise également un recall et une précision supérieurs à 90 % chacun dans le périmètre instrumenté, avec un délai P90 de détection des incidents Sev3 inférieur à 90 minutes. Il s’agit toutefois d’objectifs futurs et non de résultats atteints selon le contenu publié.