Qu'est-ce qui empêche une gazelle de dormir la nuit ? C'est peut-être la pensée des crocodiles qui rôdent dans les rivières et les points d'eau, prêts à bondir sans prévenir. La gazelle sage évite de s'attarder au bord du troupeau et espère que les crocodiles sont peu nombreux.
Rester au milieu du troupeau est important pour la survie. Dans l'assistance informatique, nous reconnaissons l'effet de cet instinct de survie lorsqu'un nouveau logiciel est lancé. Les premiers utilisateurs le chargeront et joueront avec, mais peu d'entre eux l'utiliseront immédiatement comme outil de base de l'entreprise. Les gazelles intelligentes attendent que les eaux aient été testées. Les gazelles intelligentes savent aussi suivre le rythme et ne pas se laisser distancer. Les gazelles qui traînent sont en danger, car elles utilisent des applications critiques que le fournisseur a cessé de prendre en charge.
Sans vigilance, il est facile d'être vulnérable et séparé du troupeau. Aller de l'avant, sans gestion claire des risques, accroît la vulnérabilité : chargez du code nouvellement publié et non testé sur un équipement de production ou du matériel non testé dans un environnement de production et les crocodiles commencent à tourner en rond. Prendre du retard, c'est ne pas mettre à jour les systèmes et utiliser des solutions exotiques : les logiciels ou le matériel qui ne sont plus pris en charge sont peu rentables. En outre, l'intégration de matériel et de logiciels dans un système pour le rendre unique et la modification du code principal pour le rendre unique peuvent vous priver de la protection du "troupeau". La vulnérabilité est accrue par des charges ou des profils exotiques qui surchargent le système au-delà de ses capacités ou par un réglage extrême des paramètres du logiciel et du micrologiciel pour une application donnée.
Le diagramme 1 illustre comment ces actions risquées rendent les organisations informatiques vulnérables. Une fois au bord du troupeau, il est facile de se faire prendre par les crocodiles latents qui se cachent.
Diagramme 1 : Les actions risquées qui séparent les organisations du troupeau
Malheureusement, le fait d'être au milieu du troupeau - en utilisant des configurations et des logiciels standard, en restant à jour et en respectant les tolérances de performance - n'est toujours pas une garantie de survie. Réduire le nombre de crocodiles affamés est la véritable clé de la survie.
Les pires incidents informatiques que nous voyons de notre point de vue de consultants, résultent de problèmes non diagnostiqués et de changements mal réalisés. Réunir des problèmes non diagnostiqués de la bonne manière peut s'avérer miraculeux ; dans le cas contraire, cela peut provoquer un échec catastrophique.
Par exemple, une entreprise mondiale du Fortune 500, qui utilise des systèmes informatiques comme tout le monde pour recevoir des commandes, planifier la fabrication, programmer les livraisons et émettre des factures sur du matériel courant et des logiciels populaires, a perdu la capacité de savoir ce qu'il fallait fabriquer, expédier et facturer pendant environ trois semaines. L'incident n'a pas été médiatisé car il a été bien géré du point de vue des relations publiques et l'entreprise continue de prospérer. Cependant, pendant trois semaines, les crocodiles se sont retrouvés au milieu des gazelles et ont agi de manière désordonnée pour faire tomber les systèmes informatiques de base.
La lutte contre les nuisibles - en réduisant le nombre de crocodiles - réduit le nombre d'occasions pour eux de conspirer sans réfléchir pour vous faire du mal. Mais où se cachent-ils ? Ils attendent de bondir dans votre arriéré de problèmes informatiques non diagnostiqués.
Plus le nombre de problèmes informatiques non diagnostiqués est élevé, plus la possibilité est grande qu'un, deux ou plusieurs d'entre eux interagissent de manière intéressante, avec un changement innocent, pour faire tomber votre système. Les organisations qui trouvent les causes profondes des problèmes informatiques ont mathématiquement de meilleures chances de stabilité informatique que celles dont les problèmes ne sont pas diagnostiqués. Les problèmes qui sont à la fois en train de rôder (vous les connaissez - ils sont dans une file d'attente quelque part, dans une masse de changements incontrôlés ou cachés dans un mauvais entretien) et latent (qui n'affectent rien pour le moment) finissent par conspirer pour causer des dommages inattendus.
Étude de cas. Les problèmes peuvent se conjuguer au hasard et provoquer des pannes informatiques prolongées. Après le rachat d'un concurrent par l'entreprise A, les lignes de produits devaient être intégrées. En collaboration avec les fournisseurs, l'entreprise A a spécifié le matériel et les logiciels nécessaires et un plan de projet a été créé pour mettre en œuvre le changement. À l'époque, quatre défauts du système de production actuel, dont aucun ne causait de problèmes et qui n'étaient donc pas présents à l'esprit du personnel d'assistance, étaient inconnus et profondément enfouis dans un arriéré de problèmes non diagnostiqués. Il s'agit de
- Un travail lent de traitement des files d'attente de la base de données (existant depuis six mois)
- Lenteur des entrées/sorties logiques vers un périphérique de stockage de données partagé sur d'autres systèmes qui ne sont manifestement pas liés à celui-ci (constatée avec une autre partie de l'infrastructure il y a plusieurs semaines)
- Une mise à jour du micrologiciel de l'interconnexion de stockage des données qui ne s'est pas appliquée correctement (effectuée il y a quelques semaines).
- Outils de surveillance des bases de données qui cessaient occasionnellement d'enregistrer (en cours depuis un an)
Ces problèmes avaient été enregistrés et attendaient une action de la part du fournisseur ou du personnel.
Lorsque la mise à niveau du logiciel et le matériel requis ont été achevés, tout s'est parfaitement déroulé. Le système a repris la production, mais personne n'a vérifié la surcharge de performance prévue. C'était un très gros crocodile.
Diagramme 3
L'augmentation de la charge du système s'est faite en douceur, une usine à la fois, afin de s'assurer que chaque étape était contrôlée. Mais deux semaines après avoir commencé ce processus, un point de basculement a été atteint et le système est passé d'un flux libre à des turbulences - de 20 heures à 60 heures par jour pour traiter une journée de travail. Les conséquences ont été rapides et graves. Les directeurs d'entreprise ont commencé à crier que l'entreprise était en train de mourir. Ils ont coupé les usines des travaux par lots et ont reprogrammé les cycles de production de tous les jours à une fois par semaine. Certains dépôts ont dû inventer par expérience ce que les clients étaient susceptibles de commander et seules les actions héroïques d'un très grand nombre d'employés ont permis à l'entreprise de fonctionner sans ses systèmes informatiques.
Le retour à la configuration précédente n'était possible que si l'on sacrifiait deux semaines de factures. La décision a été prise d'aller de l'avant en utilisant la nouvelle configuration. Au cours de ce processus, le crocodiles latents qui rôdentont été découverts. Tous les crocodiles n'étaient pas immédiatement malveillants - l'outil de surveillance de la base de données s'était tout simplement arrêté deux semaines auparavant, et l'effort de résolution du problème a donc été prolongé par l'absence de cette information. Les crocodiles latents qui se cachaient attendaient, sans être observés, de se réunir en un seul événement calamiteux.
Comment survivre
Il est clair qu'il y a des leçons à tirer des erreurs. Rester au milieu de la foule informatique est une décision informatique stratégique à prendre. Mais réduire la probabilité que des défauts non diagnostiqués conspirent contre vous est rarement abordé avec assez de vigueur. Combien de cas non diagnostiqués se trouvent dans votre arriéré de support informatique ? Si vous les éliminez rapidement et efficacement et si vous avez des plans pour gérer les corrections provisoires et les actions correctives pour ceux qui sont vraiment difficiles à résoudre, tout va bien.
La plupart des organisations d'assistance accumulent un grand nombre de problèmes ou clôturent systématiquement des dossiers sans en trouver la cause profonde - ce qui compromet leur avenir avec des crocodiles.
Dans le cadre de nos engagements avec les clients qui ont initialement un arriéré important, nous travaillons avec eux pour effectuer une analyse de l'état actuel, calculer les économies anticipées en termes de temps et d'argent, identifier les points de levier et réaliser une mise en œuvre structurée et bien gérée de processus de traitement des problèmes de bonne qualité. Cela permet de construire une meilleure organisation de support avec des processus de travail plus efficaces et des ingénieurs plus motivés. En outre, il y a moins de crocodiles latents qui attendent, observent et sont prêts à bondir.
