Une PME peut surveiller trop de métriques et manquer un incident. Ce guide relie observabilité, objectifs de service, alertes utiles et actions concrètes pour l’équipe.
Partir d’un parcours utilisateur
Commencez par les actions qui font fonctionner l’activité : se connecter, consulter une commande, envoyer un formulaire, générer un document ou recevoir une notification. Pour chaque parcours, indiquez la dépendance principale, le résultat attendu et la personne qui traite un incident.
Cette liste donne un contexte aux métriques. Une base de données peut afficher une charge normale alors qu’un paiement échoue à cause d’un service externe. À l’inverse, une alerte sur un disque presque plein peut rester sans conséquence immédiate si la croissance est lente et documentée.
Distinguer métriques, journaux et traces
Les métriques résument un état dans le temps : taux d’erreur, durée des requêtes, mémoire utilisée ou nombre de files en attente. Elles sont adaptées aux tendances et aux seuils. Les journaux décrivent des événements précis, avec une heure, un service et un identifiant de corrélation. Les traces suivent une requête à travers plusieurs composants.
Utilisez le même identifiant de requête dans les journaux d’une API, d’un worker et d’un service de notification. Une équipe peut alors passer de l’erreur visible par l’utilisateur à l’opération qui l’a produite. Évitez d’enregistrer des mots de passe, des jetons, des données de paiement ou des informations personnelles dont le diagnostic ne nécessite pas la présence.
Écrire un SLO mesurable
Un SLO décrit un niveau de service visé pendant une période donnée. Pour une page critique, il peut combiner disponibilité et latence : par exemple, 99,5 % des requêtes réussissent sur un mois et 95 % répondent sous un seuil défini. Les valeurs doivent venir des besoins de l’activité et d’une mesure de départ.
Ne promettez pas une précision que votre instrumentation ne permet pas de vérifier. Si les requêtes lentes sont comptées uniquement côté navigateur, vous ne saurez pas toujours si le problème vient du réseau, de l’API ou de la base. Définissez le point de mesure avant de fixer le chiffre.
Le budget d’erreur traduit le SLO en décision d’exploitation. Une équipe qui a consommé la plus grande partie de son budget peut reporter une amélioration non urgente et traiter la fiabilité. Cette règle fonctionne seulement si les erreurs sont mesurées de façon stable et si une personne peut la faire appliquer.
Construire des alertes qui déclenchent une action
Une alerte doit répondre à trois questions : quel service est touché, quelle action faut-il tenter et qui reçoit la notification ? Une alerte sur la seule utilisation CPU produit souvent du bruit. Reliez-la à une durée, à un taux d’erreur, à une file qui augmente ou à une saturation observée par les utilisateurs.
Séparez les notifications urgentes des rapports. Une panne qui exige une intervention immédiate ne doit pas être noyée dans une liste quotidienne de tendances. Pour chaque alerte, ajoutez un lien vers une procédure courte : vérifier la version déployée, comparer le trafic, examiner les dépendances, puis décider d’un retour arrière ou d’une escalade.
Testez aussi la réception. Une règle correcte ne sert à rien si elle arrive dans une boîte non surveillée, si elle ne mentionne pas l’environnement ou si elle ne contient pas de lien vers les journaux. Après un incident, supprimez les règles qui n’ont déclenché aucune action et ajustez celles qui ont répété la même information.
Conserver un historique exploitable
Les tableaux de bord doivent afficher une période assez longue pour comparer une journée habituelle avec un pic de trafic ou une version précédente. Gardez les changements de configuration, les déploiements et les incidents sur la même ligne temporelle. Une annotation de déploiement peut expliquer une hausse qui aurait sinon été attribuée à l’infrastructure.
Une PME n’a pas besoin de dizaines de tableaux de bord. Un écran par parcours critique, un écran d’infrastructure et une vue des coûts suffisent souvent pour commencer. Chaque graphique doit avoir une unité, une période et une description. Les personnes de permanence doivent savoir quoi regarder sans demander au développeur qui a créé la vue.
Faire évoluer le dispositif
Révisez les SLO après un changement d’architecture, de trafic ou de contrat. Mesurez les faux positifs des alertes, le temps nécessaire pour trouver la cause et les étapes qui manquent dans les procédures. Organisez une courte revue après chaque incident significatif, en vous concentrant sur les signaux et les décisions observables.
La documentation Google sur les SLO et l’observabilité dans nos pratiques DevOps peuvent servir de base de travail. Pour une architecture plus large, notre accompagnement DevOps et cloud au Maroc aide à relier supervision, livraison et responsabilités.
Sources : Google SRE, Service Level Objectives, OpenTelemetry, documentation.