Surveiller
Détecter les événements et comprendre les impacts sur les services.
RETOUR D’EXPÉRIENCE · RUN & EXPLOITATION
Observabilité : après les projets, il y a le RUN.
Installer une plateforme est une étape. La rendre utile au quotidien, lorsque les applications changent et les incidents surviennent, est une expertise à part entière.
5 min de lecture · Expériences ADN ConsultingRUNMCOSupport N1 · N2 · N3DatadogDynatraceCentreon
L’ESSENTIEL
Observer ne suffit pas : il faut agir.
Résoudre
Qualifier, investiguer et rétablir le service selon le niveau de support.
Améliorer
Adapter les moniteurs, les agents, les procédures et les pratiques.
Audit Datadog, migration Centreon, déploiement Dynatrace : ces projets sont visibles et structurés. Mais une fois livrés, les plateformes doivent encore accompagner les changements applicatifs, les nouveaux environnements cloud et les contraintes opérationnelles. C’est précisément le rôle du RUN : maintenir la supervision efficace dans la durée.
AU QUOTIDIEN
Le RUN, ce n’est pas regarder des dashboards
Une API peut ralentir sans panne franche. Un batch peut dépasser sa durée habituelle tandis que les serveurs restent disponibles. À l’inverse, une alerte peut se répéter sans nécessiter d’intervention. L’enjeu consiste à transformer les métriques, les traces APM et les logs en décisions : qualifier l’événement, comprendre le service concerné, corréler les signaux et mobiliser la bonne expertise.
Une plateforme d’observabilité n’a de valeur que si ses signaux permettent aux équipes de réagir.
ORGANISATION DU SUPPORT
N1, N2, N3 : une chaîne de traitement complémentaire
N1 · Détecter et qualifier
Surveillance des événements, premier diagnostic, application des consignes, ouverture et routage des incidents.
N2 · Investiguer et rétablir
Corrélation des signaux, traitement des incidents récurrents, correction des configurations et des moniteurs.
N3 · Expertiser et fiabiliser
Analyse des problèmes complexes, instrumentation APM, corrections structurelles et automatisation.
ADN accompagne les organisations sur ces activités selon les niveaux et responsabilités prévus dans chaque dispositif. Il ne s’agit pas d’attribuer systématiquement les trois niveaux à chaque consultant : les missions ont des périmètres différents.
Exemple illustratif : une alerte N1 signale une hausse de latence. Le N2 recoupe logs, métriques et traces pour identifier la dépendance en cause. Le N3 peut ensuite revoir l’instrumentation, les seuils et les procédures pour éviter une nouvelle investigation à l’aveugle. Cette séquence décrit la logique d’un dispositif, pas un incident client réel.
NOS EXPÉRIENCES
Quatre consultants, plusieurs réalités du RUN
Les missions enregistrées dans notre suivi illustrent la diversité des interventions en exploitation et expertise observabilité. Les clients restent anonymes.
Hector
RUN de plateforme d’observabilitéUne mission d’exploitation et de suivi opérationnel d’une plateforme d’observabilité dans un système d’information étendu.
João
Expertise observabilité dans la duréeUne mission de longue durée en expertise observabilité, au contact d’un environnement applicatif complexe.
Mariam
DevOps et monitoring applicatifUne intervention associant pratiques DevOps, supervision et observabilité des applications.
Vianney
Monitoring IT et expertise DatadogDes expériences complémentaires : monitoring IT au quotidien et intervention distincte d’expertise Datadog.
Les intitulés de missions sont documentés dans Watcher ; les incidents traités et les résultats chiffrés ne sont pas détaillés faute de validation des consultants.
01 · Détecter02 · Qualifier03 · Résoudre04 · Améliorer
AMÉLIORATION CONTINUE
Faire évoluer sans perturber l’exploitation
Changer un seuil réduit parfois le bruit, mais peut aussi masquer une dégradation. Réduire les logs indexés maîtrise certains coûts, mais risque de rendre une enquête impossible. Mettre à jour un agent peut améliorer la collecte ou introduire une régression. En RUN, chaque évolution mérite donc une mesure de départ, une analyse de risque et une validation après changement.
Les indicateurs de MTTD, de MTTR, de récurrence des incidents et de SLO aident à dépasser le simple nombre de tickets fermés. Le RUN fait alors émerger de nouveaux projets : refonte de l’alerting, instrumentation plus précise, automatisation ou évolution des dashboards métiers.
Construire une plateforme d’observabilité est un projet. La rendre utile chaque jour est un engagement opérationnel.
QUESTIONS FRÉQUENTES
Comprendre le RUN en observabilité
Quelle différence entre projet d’observabilité et RUN ?
Le projet conçoit ou transforme une capacité d’observabilité. Le RUN exploite les outils, qualifie les alertes, contribue au rétablissement et maintient la supervision pertinente.
Quels sont les rôles du N1, N2 et N3 ?
Le N1 surveille et qualifie ; le N2 investigue et rétablit ; le N3 traite les problèmes complexes et les évolutions durables. Leur répartition dépend de chaque organisation.
Quels indicateurs permettent d’améliorer le RUN ?
Le délai de détection (MTTD), le délai de rétablissement (MTTR), la récurrence des incidents et les objectifs de service (SLO) sont des indicateurs utiles s’ils sont définis de façon cohérente.