En 2008, j’ai décroché mon second emploi, dans l’équipe réseau d’Orange Portails, la division derrière les sites web et le moteur de recherche de l’opérateur télécom français Orange. Tout y fonctionnait comme sur des roulettes : un environnement technique complet, une équipe dédiée pour chaque pan de l’activité et la liberté de me concentrer sur ce que je faisais de mieux. Quelques années plus tard, plus rien n’allait : minés par une obsession du chiffre, nous n’arrivions plus à livrer les nouveaux services dans les temps.

Les premières années#

À mes débuts, le département fonctionnait comme une startup. Son origine était l’entreprise française Echo. Elle avait bâti un moteur de recherche. France Télécom l’a racheté et rebaptisé Voila. C’était le moteur de recherche le plus consulté en France au début des années 2000. France Télécom a regroupé les activités de portail au sein de la division Wanadoo Portails, renommée plus tard Orange Portails.

L’environnement technique était excellent. Nous disposions de nombreux outils internes² : un système de tickets, un outil de graphes RRD, un IPAM, un outil de reporting et un outil d’alerte basé sur SNMP³. Nous déployions nos serveurs Linux avec CFEngine. Nous installions les systèmes et les applications depuis des dépôts Debian internes. Nous documentions tout dans une instance MediaWiki privée. La supervision était basée sur un ancêtre de XYmon. L’architecture réseau était propre et évolutive, avec peu de dette technique. Un nouvel arrivant était opérationnel en une journée.

C’était un environnement épanouissant pour moi. J’ai développé plusieurs outils : lldpd, une implémentation de 802.1AB, Snimpy, une interface pythonique pour Net-SNMP, Wiremaps, un outil de découverte de niveau 2 doté d’une machine à remonter le temps pour savoir quel équipement est connecté où, Kitérő, un outil pour simuler des conditions réseau, QCSS-3, un contrôleur pour répartiteurs de charge, et ipoo, un service accessible via un bot Jabber et un script Greasemonkey pour exposer des informations liées aux adresses IP. J’ai ajouté le support SNMP pour Keepalived et Quagga. J’ai aussi lancé ce blog, avec des articles comme « DNS anycast », des articles sur TLS comme « Déni de service TLS : quelles solutions ? », des articles sur SNMP comme « Intégration de Net-SNMP dans une boucle d’évènements », des articles sur Linux comme « Comprendre la mise en cache des routes IPv4 sous Linux », et un article sur VXLAN bien avant que ce soit à la mode.

La chute#

Quand nous avions besoin de nouveaux serveurs, l’équipe de proximité en prenait un lot dans l’inventaire, y installait notre distribution Linux, les déplaçait dans le datacenter et les câblait au réseau. Nous ouvrions un ticket décrivant les serveurs dont nous avions besoin et, une semaine plus tard, nos serveurs étaient disponibles. 💫

Orange voulait savoir si l’équipe de proximité était performante : elle a donc réclamé des KPI. Le choix s’est porté sur le nombre de tickets traités dans l’année. Orange a demandé à doubler ce nombre. Au lieu d’un seul ticket pour un nouveau service, nous en ouvrions six, un par serveur. À la fin de l’année, les KPI avaient plus que doublé.

Tout le monde y a vu une réussite du pilotage de la performance. Il a donc été demandé de récidiver l’année suivante. Cette fois, nous devions ouvrir un ticket par serveur et par étape. De nouveau, les KPI ont doublé. En coulisses, les tickets partaient à différentes personnes et n’étaient plus traités dans l’ordre. Aussi, pour l’année suivante, il a été décidé de créer des méta-tickets et de tenir des réunions pour suivre l’avancement de ces tickets. Bien sûr, toutes ces étapes supplémentaires faisaient encore grimper le KPI.

Cette méthode de pilotage de la performance s’est étendue aux autres équipes⁴. Tout est devenu plus lent. Au lieu de quelques semaines, il nous fallait six mois pour déployer un nouveau service. Nous avions bâti une usine à clous soviétique. Mais les KPI étaient bons et nous avons lâché l’affaire.

Prenons un autre exemple. Nous devions estimer l’impact de chaque opération de nuit. Nous n’étions pas mauvais : l’essentiel des opérations étaient déclarées « sans impact ». La plupart du temps, c’était le cas. Parfois, il y avait un impact de 5 secondes. On nous a demandé de faire plus d’efforts pour tenir l’impact annoncé. Qu’avons-nous fait ? Nous avons commencé à déclarer un impact attendu de 5 secondes. Un jour, nous avons eu un impact de 30 secondes et il nous a été reproché de ne pas avoir respecté l’impact annoncé. Au final, la plupart des opérations étaient déclarées avec un impact attendu de 10 minutes, et nous avons cessé de nous en préoccuper : au lieu de basculer le trafic avec soin, nous nous autorisions un impact de 5 minutes. Et nos KPI n’avaient jamais été aussi bons.

---

Les KPI ne sont pas inutiles, mais ils peuvent avoir des conséquences négatives. Utilisez-les avec précaution : laissez les personnes opérationnelles participer au choix des indicateurs et reliez ces indicateurs à la qualité du service rendu, par exemple avec des objectifs de niveau de service. Sinon, même les plus consciencieux finissent par lâcher prise et détourner le système avant de partir. 📊