Datadog

Datadog expose un ensemble étendu de types d'objets : incidents, monitors, SLOs, métriques en série temporelle, logs, traces, événements, hosts et dashboards. Cette intégration se concentre sur deux objets — les incidents et les SLOs — qui fournissent ensemble les signaux de performance les plus directs et les plus attribuables pour les équipes d'ingénierie et de fiabilité. Les métriques en série temporelle, les logs et les traces ont été écartés car leur agrégation au niveau individuel ne produit pas d'indicateurs causalement liés à la contribution d'un ingénieur spécifique. Sept KPIs ont été retenus, sélectionnés sur trois critères : capacité d'attribution à un propriétaire résolvable par email, résistance au gaming, et équilibre entre indicateurs avancés et indicateurs retardés.

Réponse aux incidents : lire la vitesse et la sévérité ensemble

Cinq KPIs sont dérivés des incidents, tous attribués au commandant d'incident — l'ingénieur qui prend en charge la remédiation. Ils couvrent trois dimensions distinctes de la performance en astreinte : la vitesse de réponse, l'exposition à la sévérité, et l'impact business.

Vitesse de réponse : MTTA et MTTR

Le MTTA mesure la rapidité avec laquelle l'ingénieur d'astreinte prend en charge un incident après son déclenchement. Le MTTR mesure la durée totale du cycle de résolution. Ces deux indicateurs ne mesurent pas la même chose, et les confondre est une erreur de diagnostic fréquente. Un MTTA faible associé à un MTTR élevé révèle que les incidents sont acquittés rapidement mais que la remédiation est lente — souvent le signe de systèmes complexes insuffisamment documentés ou de runbooks manquants. Le schéma inverse — MTTA élevé, MTTR faible — indique que l'équipe est lente à détecter ou à prendre possession de l'incident, mais résout efficacement une fois engagée, ce qui pointe vers des lacunes dans le routage des alertes ou l'affectation des astreintes. Lire le MTTA comme indicateur avancé et le MTTR comme résultat retardé permet de faire apparaître ces tensions structurelles qu'aucun des deux indicateurs ne révèle seul.

Sévérité et impact business

Les Incidents SEV-1 comptent le nombre d'incidents de sévérité maximale affectés à un commandant. La Durée d'impact client cumule le total des minutes de perturbation côté client sur ces incidents. Ces deux indicateurs entretiennent une relation de calibrage : les Incidents SEV-1 révèlent la fréquence des événements critiques, tandis que la Durée d'impact client en révèle le coût. Un nombre élevé d'incidents SEV-1 associé à une faible Durée d'impact client indique que les incidents critiques sont contenus rapidement ; le même nombre d'incidents SEV-1 associé à une Durée d'impact client élevée indique que la remédiation est lente ou que la portée s'élargit. Le rapport entre ces deux indicateurs est plus informatif que chacune de ces valeurs prise isolément. Le MTTR sert d'explication mécaniste : lorsque la Durée d'impact client est disproportionnée par rapport au nombre d'incidents SEV-1, c'est le MTTR des incidents de ce commandant qu'il faut investiguer.

Charge d'astreinte : les Incidents actifs comme signal de planification

Les Incidents actifs comptent le nombre d'incidents actuellement dans un état actif ou stable attribués à un ingénieur. C'est le seul indicateur de ce bloc qui mesure un état courant plutôt que des résultats passés, ce qui en fait un indicateur avancé de pression de charge plutôt que de performance historique. Une distribution inégale des Incidents actifs entre les ingénieurs sur une période donnée indique que la charge d'astreinte n'est pas partagée équitablement, ce qui prédit une dégradation du MTTA pour les ingénieurs en surcharge. Ce KPI ne mesure pas la performance individuelle de manière isolée ; c'est un input de planification au niveau de l'équipe qui informe la conception des rotations et l'allocation de capacité.

Contrats de fiabilité : conformité et breach des SLOs

Le Taux de conformité SLO mesure le ratio moyen de temps pendant lequel un service respecte son objectif de fiabilité défini, sur l'ensemble des SLOs détenus par un ingénieur. Les SLOs en breach comptent le nombre de SLOs actuellement dans un état breached. Ces deux indicateurs remplissent des fonctions managériales différentes et ne doivent pas être lus comme des substituts l'un de l'autre.

Le Taux de conformité SLO est un indicateur continu : il capture dans quelle mesure les services se maintiennent à proximité ou au-dessus de leurs objectifs sur une fenêtre de reporting. Un taux de conformité de 99,85 % sur un objectif SLO de 99,9 % indique un quasi-manquement sans breach, et la tendance importe autant que la valeur ponctuelle. Les SLOs en breach sont une alarme binaire : ils comptent le nombre de SLOs ayant franchi le seuil, quelle que soit la distance franchie. Ensemble, ces indicateurs produisent une lecture en couches de la santé de la fiabilité. Un taux de conformité élevé associé à un nombre non nul de SLOs en breach signale que la plupart des SLOs sont en bonne santé mais qu'un sous-ensemble a complètement échoué — ce qui serait invisible à partir de la seule figure agrégée de conformité. Ce couplage neutralise le risque de gaming inhérent à la moyenne du taux de conformité, où un grand nombre de SLOs très performants peut masquer un petit nombre de SLOs en breach critique.

Périmètre et limites de l'intégration

Datadog capture les événements du cycle de vie des incidents et les données de conformité des SLOs, mais ne mesure pas la qualité du travail effectué durant un incident. Un ingénieur qui résout les incidents rapidement peut le faire en appliquant des corrections partielles qui produiront des récurrences ; l'API ne distingue pas une résolution durable d'une résolution temporaire. L'analyse post-incident, les améliorations de runbooks et la documentation des causes racines — le travail qui améliore la fiabilité de manière systémique — ne laissent aucune trace structurée dans l'API Datadog et sont donc absents de ces KPIs.

Le modèle d'attribution comporte également une limitation structurelle. Le commandant d'incident est le champ propriétaire utilisé tout au long de cette intégration, mais le commandant est désigné après la déclaration d'un incident, et non en fonction de qui l'a causé ou de qui en est le plus responsable. Dans les grandes équipes d'ingénierie, la rotation des commandants signifie que ces KPIs reflètent autant l'exposition à l'astreinte que la capacité individuelle. Par ailleurs, la propriété des SLOs est attribuée par défaut au créateur du SLO, ce qui peut ne pas correspondre au propriétaire actuel du service si les équipes ou les responsabilités ont évolué depuis la définition du SLO. La fiabilité de ces KPIs dépend directement de la rigueur avec laquelle l'équipe affecte les commandants d'incident, déclare l'impact client et maintient une propriété précise des SLOs.