Depuis que je travaille sur un produit livré en service, j’ai appris une leçon vite pis pour de bon: quand t’es responsable de quelque chose qui doit rouler en continu, ne pas voir ce qui se passe, c’est aussi dangereux que de ne pas savoir conduire. Un client peut nous appeler pour dire « ça marche pas » avant même qu’on s’en rende compte. Pis ça, c’est la pire position pour une équipe: apprendre ses propres problèmes par la bouche de ceux qui les subissent. La supervision, ce n’est pas un luxe d’exploitation — c’est ce qui décide si on mène le service ou si le service nous mène.

Le piège, en août 2008, c’est que la « visibilité » se fait vendre comme un produit emballé tout neuf à chaque année. Nouveau nom, nouvelle boîte, nouvelle promesse de tableau de bord magique. Mais le problème de fond n’a jamais été réglé pour de vrai: savoir, à temps, que quelque chose va mal, pis comprendre pourquoi assez vite pour agir. La techno change d’habit, le problème reste le même.

Ce que j’essaie d’inculquer à mon équipe, c’est une distinction simple entre trois niveaux. Il y a la supervision « est-ce que c’est vivant? » — le serveur répond-il, oui ou non. Il y a la supervision « est-ce que c’est en santé? » — les temps de réponse, les erreurs, la charge. Pis il y a la supervision « pourquoi ça va mal? » — les logs, les traces, le détail qui permet de diagnostiquer. La plupart des équipes ont le premier niveau pis pensent être protégées. C’est le deuxième pis le troisième qui sauvent une nuit.

flowchart TD
    A[Le service tourne] --> B{Niveau 1<br/>Est-ce vivant?}
    B -->|Repond| C{Niveau 2<br/>Est-ce en sante?}
    B -->|Mort| Z[Alerte immediate]
    C -->|Lent / erreurs| Y[Alerte avant<br/>que le client appelle]
    C -->|OK| D{Niveau 3<br/>Pourquoi ca varie?}
    D --> E[Logs, traces<br/>pour diagnostiquer]

Ce qui distingue une bonne supervision d’une mauvaise, ce n’est pas le nombre de graphiques. C’est la pertinence des alertes. Une équipe noyée sous cent alertes par jour finit par toutes les ignorer — c’est l’histoire du petit gars qui criait au loup. Une alerte qui se déclenche, ça doit vouloir dire « quelqu’un doit regarder maintenant ». Si ça se déclenche pour rien, on vient de désensibiliser tout le monde, pis le jour où c’est vrai, personne ne bouge.

Côté pratique, je pousse mon monde à mesurer ce que le client ressent, pas juste ce que la machine fait. Un serveur peut être à 20 % de CPU pis quand même offrir une expérience pourrie si une requête importante est lente. La vraie question, c’est: « du point de vue de l’utilisateur, est-ce que ça répond bien? »

Le piège que je nomme à mon équipe, c’est de croire qu’installer un outil de supervision = être protégé. Un outil qui collecte des données que personne ne regarde, c’est du théâtre. La visibilité, ce n’est pas la quantité de données captées; c’est la rapidité avec laquelle on transforme un signal en action. Entre les deux, il y a du monde, des seuils bien réglés pis une vraie habitude de réagir.

Ce que je retiens en cet été 2008, c’est que la supervision, c’est moins une affaire d’outil qu’une affaire de culture. Une équipe qui regarde ses signaux pis qui agit dessus va dormir mieux qu’une équipe qui a le plus beau tableau de bord mais qui ne le consulte jamais. Le but, ce n’est pas de tout voir — c’est de voir les bonnes affaires, à temps, pis de savoir quoi faire.

La suite, je la garde concrète: des alertes rares mais sérieuses, des mesures qui reflètent l’expérience réelle du client, pis assez de détail pour diagnostiquer quand ça accroche. La « visibilité » va continuer de se faire revendre dans un nouvel emballage chaque année. Mais le vrai test reste le même: le jour où ça va mal, est-ce qu’on le sait avant le client, pis est-ce qu’on comprend pourquoi assez vite pour régler ça? Tout le reste, c’est de la décoration.