Un serveur peut afficher une charge élevée sans perturber les utilisateurs ; une application peut être indisponible alors que tous les serveurs paraissent sains. Pour piloter la continuité, il faut observer le service rendu, comprendre ses dépendances et savoir quoi faire lorsqu’il se dégrade. La supervision devient alors un processus opérationnel, et non une collection d’écrans.
Partir des parcours qui comptent
Prenons un parcours de commande à titre d’exemple : consulter le catalogue, s’identifier, payer, recevoir une confirmation. Chaque étape dépend d’applications, de réseaux, de données et parfois de prestataires externes. La cartographie de ces dépendances permet d’attribuer un impact métier à une panne technique. Un point de vente, un portail client ou un outil interne n’auront pas les mêmes horaires critiques ni les mêmes attentes de rétablissement.
- Décrire pour chaque service son propriétaire, ses périodes sensibles et les symptômes visibles par l’utilisateur.
- Relier les composants techniques au parcours concerné et identifier les dépendances hors du contrôle direct de l’équipe.
- Définir ce qui justifie une intervention immédiate, une analyse différée ou une simple observation.
Concevoir des signaux exploitables
L’observabilité aide à comprendre le fonctionnement d’un service à partir de ses signaux : les métriques mesurent son état, les journaux enregistrent les événements et les traces suivent les requêtes entre les composants. OpenTelemetry décrit ces familles de signaux, mais le choix des outils vient après la définition des questions à résoudre. Une alerte « espace disque à 80 % » n’a de valeur que si l’on connaît la vitesse de croissance, le service exposé et l’action possible.
Il faut aussi éviter l’alerte répétée qui n’appelle aucune décision. Dédupliquer les événements liés, tenir compte des périodes de maintenance et revoir les seuils à partir des incidents réels rend le dispositif plus fiable. Les signaux sensibles doivent être protégés et conservés selon un périmètre défini.
- Associer à chaque alerte un contexte, un niveau de priorité, une équipe responsable et une première action.
- Vérifier régulièrement les alertes sans suite et les incidents détectés trop tard.
Organiser la réponse avant l’incident
Quand une dégradation est détectée, l’équipe a besoin d’un chemin court : qualification, responsable, diagnostic initial, escalade, communication et validation du retour à la normale. Un guide d’intervention peut préciser où consulter l’état du service, quels changements récents vérifier et à quel moment solliciter un fournisseur. Il doit être utilisable sous pression, y compris par une personne qui n’a pas conçu l’architecture.
Un exercice simple peut révéler qu’une alerte est reçue par une boîte non surveillée, qu’un accès manque ou que la procédure de restauration est obsolète. Ces défauts sont plus importants qu’un tableau de bord supplémentaire.
Mesurer ce que la supervision améliore
Le nombre d’alertes générées n’est pas un indicateur de succès. Suivez plutôt la part d’alertes qui déclenchent une action utile, le temps entre le premier symptôme et la détection, le temps de rétablissement, les incidents récurrents et les services les plus touchés. Relisez ces résultats avec les responsables métiers : l’objectif est de réduire l’impact vécu, pas uniquement d’obtenir des voyants verts.
Pour commencer, sélectionnez quelques services critiques, documentez leur parcours, testez l’escalade puis étendez progressivement le périmètre. Cette séquence donne une base vérifiable à une amélioration continue.
À retenir
Une supervision mature relie chaque signal à un service, une décision et un responsable ; elle mesure aussi la qualité de la réaction.
