La réponse édifiante de l’équipe IT
- L’histoire de « Bruce », qui travaillait dans l’équipe d’infrastructure Internet d’une banque australienne.
- Aux débuts de la banque en ligne, l’équipe s’est développée rapidement et la charge de travail a augmenté.
- L’équipe a compris qu’il fallait acheter des liens ISDN supplémentaires avant que l’utilisation ne dépasse la moitié de la capacité, et a soumis une proposition au CIO.
Le refus de la direction et la réaction de l’équipe IT
- Le CIO a transmis à la direction une demande d’achat de liens ISDN supplémentaires, mais celle-ci a été refusée au motif que l’utilisation des liens actuels n’avait même pas atteint la moitié.
- Lorsque l’utilisation des liens a dépassé 50 %, l’équipe IT a renouvelé sa demande, mais on lui a dit d’attendre d’être proche de 100 %.
La mesure stratégique de l’équipe IT
- L’équipe IT a décidé d’ajuster la connectivité réseau de la direction afin de lui faire prendre conscience du problème.
- Elle a réduit la capacité de 10 % la première semaine, puis de 10 % supplémentaires chaque semaine.
- Un mois plus tard, l’installation de liens ISDN supplémentaires a été approuvée, et la direction s’est félicitée d’avoir résolu le « problème Internet ».
L’avis de GN⁺
Le point le plus important dans cet article est la façon dont l’équipe IT a contesté la décision de la direction et a adopté une réponse stratégique pour convaincre de la nécessité d’investir dans l’infrastructure à travers l’expérience réelle des utilisateurs. Cela montre une approche créative et efficace pour réduire l’écart entre les problèmes techniques et les décisions business. Cette histoire est non seulement intéressante pour les professionnels de l’IT, mais elle contient aussi une leçon qui peut aider les décideurs non techniques à comprendre l’importance de l’infrastructure technique.
1 commentaires
Avis sur Hacker News
J’ai déjà eu affaire à un logiciel tiers médiocre qui causait de gros problèmes à un client.
Nous étions en train de développer une solution de remplacement en interne, mais certains voulaient renouveler le contrat et continuer à utiliser le même logiciel truffé de bugs.
Nous avons fait en sorte que tous les tickets ouverts par le client soient envoyés aux partisans du maintien de l’ancienne solution, et au final, après la migration vers notre système, les problèmes ont presque disparu.
Les opérationnels empêchent souvent héroïquement cette douleur de remonter, et l’organisation finit par affecter des personnes comme des antalgiques au lieu de résoudre le problème, jusqu’à devenir accro à cet état.
L’ancien système ne pouvait rien faire d’autre que ce qu’il faisait déjà sans un recâblage massif, et l’équipe qui en avait la charge croyait qu’en ne partageant pas ses connaissances, elle s’assurait un emploi à vie.
La nouvelle équipe, elle, pensait qu’il suffisait d’ajouter des CPU plutôt que de corriger les requêtes, ce qui entraînait de fortes latences côté base de données.
Les deux équipes étaient assises juste à côté l’une de l’autre, mais ne se parlaient pas, et l’équipe de l’ancien système est même allée jusqu’à signaler comme une bombe un colis sous le bureau du directeur IT.
L’équipe du nouveau système a fini par appeler Oracle, qui a réécrit les requêtes.
La capacité à expliquer clairement les risques et à dire en quoi les conséquences techniques affectent le business est une compétence clé pour les professionnels de l’IT.
Les dirigeants de cette banque étaient peut-être vraiment d’une inertie grave, mais il est aussi possible que l’équipe technique n’ait pas su expliquer correctement la situation.
Au contraire, peut-être parce que je suis dans l’IT, j’ai l’impression que nous communiquons plutôt bien, et avec précision.
Le vrai problème, c’est que la politique du management intermédiaire brouille tout.
On peut dire à une équipe : « j’ai fait une erreur, il faut la corriger », mais plus haut, il y a des gens qui inventent toutes sortes de raisons pour ne pas revenir sur une décision, même peu importante.
Peut-être que quelqu’un a déjà vendu à son supérieur l’idée que cet équipement pourrait encore servir pendant dix ans.
Quand je travaille avec mes collègues, je les vois faire beaucoup d’efforts pour expliquer à plusieurs niveaux de profondeur, selon le niveau de leur interlocuteur.
Ce qui arrive bien plus souvent, c’est que la direction générale et les managers en dessous s’en fichent tout simplement.
Ils ont déjà un « grand plan » en tête, et les développeurs ont beau leur dire que ce fantasme ne peut pas devenir réalité, cela ne change rien.
La plupart comprennent parfaitement ce qu’on leur dit.
Ce n’est pas qu’on leur balance du jargon ésotérique réservé aux nerds de caste supérieure ; c’est simplement qu’ils s’en moquent.
J’aimerais voir moins d’entreprises dirigées par des gens façon MBA, sans tête ni cœur, et davantage d’organisations où les ingénieurs assument plus de responsabilités, mais c’est la vie.
L’IT d’entreprise est née comme une fonction de support aux employés de bureau, et il n’y avait pas besoin de planification stratégique pour faire fonctionner un fax ou un PC ; au départ, elle a donc été traitée comme un service peu important.
Il est facile de penser que les gens en costume sont radins ou stupides, ou qu’ils ne comprennent rien à la technologie, mais en réalité, il s’agit souvent d’un manque de capacité de communication.
Dans mon premier emploi, le CFO refusait sans cesse les demandes pour un vrai système de sauvegarde de l’AS/400.
Cet AS/400 contenait tout le fonctionnement de l’entreprise — ERP, CRM, comptabilité, etc. — et sauvegarder le travail de 300 personnes sur des disquettes 8 pouces était impossible dès le départ.
Un jour, une grosse panne de disque est survenue et toute l’entreprise s’est arrêtée pendant des semaines : traitement des commandes, demandes de support, propositions commerciales, consultation des numéros et adresses clients, tout était bloqué.
Je crois me souvenir que certains disques avaient été envoyés à Kroll Ontrack.
Ce n’est qu’après cette catastrophe qu’ils ont acheté du vrai matériel de sauvegarde.
Quelques mois plus tard, un étudiant développeur a exécuté en production une requête de suppression dont la clause
whereétait commentée, et une table entière a disparu.Il y avait bien une sauvegarde, mais un job en arrière-plan l’a détecté et a régénéré quatre ans de factures, envoyant à tous les anciens clients un e-mail leur demandant de payer à nouveau.
L’environnement de test est arrivé peu après.
Il y a quelque temps, je travaillais dans un community college isolé, et toutes les données étaient sur un vieil AS/400 qui tombait en panne un ou deux jours toutes les quelques semaines.
Il n’y avait pas de sauvegarde, le lecteur de bandes était hors service, et même à l’époque, il n’existait plus de pièces de rechange pour des composants déjà obsolètes comme une carte réseau 10 Mbps.
Je demandais sans arrêt qu’on le remplace ou qu’on le migre vers un serveur cloud, mais les seules réponses étaient « ce n’est pas au budget » et « c’est trop cher ».
D’après l’usage réel, cela aurait coûté quelques centaines de dollars par mois, ce qui n’avait aucun sens comparé au risque de voir toute l’université s’effondrer et peut-être fermer définitivement si le système tombait.
La panne a fini par arriver : pendant plusieurs jours, l’accès fonctionnait depuis le terminal principal, mais il ne communiquait plus du tout avec le réseau.
Les gens ont commencé à paniquer, et il a même été question de faire venir un spécialiste de réparation AS/400 à plus de 100 dollars de l’heure.
En dernier recours, j’ai réussi à réparer la carte réseau et, tout en annonçant qu’il était de nouveau en ligne, j’ai bien insisté sur le fait que ce pouvait être son dernier démarrage et qu’il fallait le sauvegarder quelque part avant cela.
Six semaines plus tard, nous avions un AS/400 flambant neuf basé dans le cloud, et nous avons célébré les funérailles du vieux et lourd bestiau en l’éteignant une dernière fois.
Son temps de fonctionnement final était de près de 25 ans.
On pourrait dire que cette histoire est improbable, voire complètement inventée, mais ce n’est pas mon avis
Dans une grande organisation, pour faire avancer quelque chose, il faut faire ressentir ma douleur à la direction
Ce n’est pas du cynisme, c’est comme ça que le monde fonctionne
Ceux qui s’attendent à ce que l’autre fasse de lui-même toutes les étapes mentales nécessaires pour comprendre la situation risquent d’avoir une sacrée surprise
Même au début des années 90, l’ISDN n’aurait pas été courant ailleurs que dans des bureaux d’agence
Et quand on commence à parler de traffic shaping/QoS, ça devient encore moins crédible
À ma connaissance, les routeurs Cisco 2500/2600 que presque tout le monde utilisait à l’époque n’ont pris en charge ce genre de fonctions que bien plus tard
Peut-être qu’il voulait parler d’un T1, mais ça sent fortement le r/thathappened
Par définition, un manager fait un travail différent de celui des opérationnels
Par exemple, comment faire ressentir à un manager la douleur d’une codebase en vrac ?
Au travail, on avait essayé de réduire les coûts en configurant un routeur Cisco 1604 ISDN pour qu’il ne reste pas connecté en permanence, mais compose automatiquement
On a alors découvert qu’un IBM AIX sur lequel le paquet du navigateur web était installé appelait périodiquement Big Blue toutes les heures pour envoyer de la télémétrie, empêchant le réseau du labo de repasser à l’état inactif
On a ajouté une règle de firewall sur le routeur pour bloquer cette manœuvre discrète
Même à la fin des années 90, Microsoft, Sun et Novell n’étaient pas aussi effrontés qu’IBM avec la télémétrie
Le vrai problème révélé ici, c’est que l’IT a besoin d’une certaine autonomie pour exécuter, indépendamment dans une certaine mesure du métier, ce qu’il sait être juste
Au bout du compte, le niveau de surveillance qu’une organisation accepte dépend de la confiance
Là où je travaille, tant que cela n’a pas d’impact sur les clients, il n’est pas nécessaire de demander l’autorisation
Si une machine semble à la peine ou si un forfait SaaS approche de sa limite, on l’upgrade tout simplement
Il arrive que quelqu’un pose des questions sur une nouvelle facture ou une hausse de coût, mais on n’a pas besoin de subir plusieurs interrogatoires pour avancer
Les gens en costume devraient réfléchir aux inconvénients d’un environnement où il faut mendier l’autorisation pour la moindre petite opération technique
Combien d’innovations finissent directement dans une benne en feu à cause de politiques de changement complexes conçues dans une tour d’ivoire il y a plus de dix ans ?
Ne pourrait-on pas repenser l’organisation en modélisant le métier comme le client de l’équipe IT ?
Si l’entreprise échoue, l’organisation IT n’a plus de raison d’être non plus ; cela semble donc une façon de penser bien plus simple
Cela modifie donc le rapport coût/bénéfice, et il faut communiquer
Quand je vois des réactions du type « ton travail est de respecter les décisions de la hiérarchie », cela me rappelle à quel point les organisations d’entreprise restent encore dans une logique militaire
Dans l’ancienne armée prussienne, les missions étaient transmises en fonction des objectifs
Du genre : « j’essaie d’atteindre X, tu t’occupes de Y, et une autre unité fait Z », tandis que l’exécution était confiée aux officiers locaux, qui voyaient réellement le terrain et avaient les connaissances nécessaires
De plus, si un officier ou un sous-officier contestait l’ordre de son supérieur direct, il pouvait faire appel au niveau au-dessus
Avec en plus un système d’état-major où les officiers d’état-major devaient aussi acquérir une expérience de commandement pendant leur formation et pouvaient contrebalancer les ordres des commandants, cela donnait un système solide et flexible, capable de s’adapter aux situations changeantes
Les officiers n’hésitaient pas à débattre avec leurs supérieurs, à remonter la chaîne, voire à refuser un ordre s’ils estimaient que c’était vraiment nécessaire
C’est ce qui permet d’obtenir l’adhésion et la participation des grades subalternes
Le principe était de prendre les décisions au niveau hiérarchique le plus bas possible
Cela s’est un peu démodé à l’époque moderne, mais à ma connaissance aucune armée ne fonctionne purement sur le mode « ton travail est de suivre les décisions hiérarchiques »
Par exemple, des livres comme Extreme Ownership
Je suis peut-être trop malveillant, mais avec un tel leadership, je pense que j’aurais simplement cherché un nouveau poste et laissé tout le navire couler
Pour simplifier du point de vue de la direction, imaginons que 100 propositions similaires remontent chaque année et coûtent chacune 1 million de dollars
Même sans parler d’amortissement ou de bidouilles fiscales, cela fait 100 millions de dollars de coût net chaque année
Même pour une banque, c’est beaucoup d’argent, et il faut le dépenser stratégiquement, pas le gaspiller
Dans ce cadre, faire ressentir la douleur à la direction et lui faire comprendre instinctivement pourquoi ce million de dollars est cette fois bien dépensé est une stratégie assez saine, pour la direction, pour l’IT et pour l’activité
Il faut aussi rappeler que les dirigeants gèrent le temps, les employés, les coûts et autres ressources limitées de l’entreprise
Bien sûr, en général, ils ne le font pas particulièrement bien, et le choix purement rationnel du point de vue de l’entreprise serait de les rémunérer de façon moins luxueuse, à peu près comme des employés ordinaires
Mais ce n’est pas « l’entreprise » qui décide, ce sont des personnes, avec des jeux politiques, des incitations et des intérêts personnels
Les dirigeants contrôlent les flux d’information, de décision, de ressources et d’argent, et se comportent donc comme des parasites qui aspirent une part excessive de leur entreprise hôte
La résolution de ce problème est laissée en exercice au lecteur
Si on leur a seulement dit : « nous prévoyons que la ligne sera saturée à 50 % vers telle date », alors l’IT a vraiment mal expliqué
Nous savons que, avec cette technologie, une saturation à 50 % signifie des délais pour les clients ou des erreurs de connexion
Il faut donc dire : « nous nous attendons à ce que les clients rencontrent des problèmes de connexion vers telle date »
Si l’on sait que la limite de 100 % n’est qu’une valeur théorique atteignable uniquement dans des conditions idéales, il faut parler en fonction de la limite réellement utilisable
Pour que les gens prennent des décisions informées, il faut leur donner les bonnes informations ; et si l’IT est payé pour comprendre la technologie, c’est aussi son travail d’en transmettre les caractéristiques d’une façon compréhensible pour les gens en costume
Bien sûr, ils ont peut-être fait de leur mieux, mais à lire le texte, on a l’impression qu’ils ont simplement envoyé une note sans ce type d’information
Je ne comprends pas très bien l’usage de l’expression « 50 % d’utilisation », comme si on ouvrait un robinet à moitié
Si la charge se concentre en pics sur un seul tuyau, il y aura de toute façon des baisses de performance intermittentes, non ?
La proportion du temps où l’on vit une « mauvaise expérience » grimpe fortement selon la distribution, au point que même 60 % semblerait difficilement supportable
Par comparaison, c’est comme si un bar décidait de n’avoir qu’un seul serveur en se basant sur la demande moyenne, alors que le vendredi soir arrive
C’est précisément ce que dit la formule de Kingman
« Quand l’utilisation a dépassé 50 %, l’équipe IT a de nouveau proposé de commander de l’ISDN. Et cela a de nouveau été refusé, avec pour consigne de ne pas reposer la question avant que l’utilisation n’approche les 100 %. »
Cela ressemble beaucoup à la perception du Covid par les autorités
Les responsables semblent incapables de faire la moindre prévision à partir des tendances existantes, et ne réagir qu’une fois la catastrophe sous leurs yeux