Support N3 chez IBM Dublin

Contexte :

Lorsque j’ai intégré IBM en 2010, j’ai suivi le parcours de formations et de certifications de la branche Content Management afin de me perfectionner sur le sujet avant de prendre mes fonctions au sein de l’équipe Content Management.

En tant qu’agent du support Niveau 3 chez IBM je recevais notamment les incidents que les supports N1 & N2 n’avaient pu résoudre. Appartenant à l’équipe EMEA, (Europe, Middle East & Africa) je prenais en charge la plupart des clients banques et assurances prioritairement pour les pays francophones & anglophones.

Mon activité comportait trois parties :

– Résoudre les incidents escaladés par d’autres équipes, de jour comme de nuit

– Préparer les travaux de mises à jour des plateformes clientes

– Me rendre en clientèle pour certaines opérations techniques ou incidents.

Le quotidien :

Nous fonctionnions en trois plages horaires de 6h30 à 20h00, d’une part afin de pouvoir apporter une aide complète aux clients et, d’autre part pour assurer le ‘follow the sun‘ : c’est-à-dire récupérer, à 06h30 les incidents majeurs provenant de la plateforme Ouest (Los Angeles) et potentiellement les transférer vers la plateforme Est le soir (Pekin).

Le support de niveau 3 recevait peu d’incidents. Chaque agent en possédait cinq au maximum mais leurs résolutions pouvaient parfois prendre plusieurs semaines voire plusieurs mois. Les autres dossiers de support étaient généralement solutionnés par les supports niveaux 1 & 2. Le niveau 3 était composé de collaborateurs plus expérimentés que les supports de niveaux inférieurs. Les ingénieurs suivaient le plan de formation des produits sur lesquels ils s’apprêtaient à travailler mais aussi sur des sujets spécifiques (codage en plusieurs langages, plateforme Unix etc…).

En outre, les ingénieurs du support niveau 3 disposaient d’un accès complet aux sources de logiciels et pouvaient, le cas échéant, tester des modifications à apporter aux produits (bug tracking). Dans le cas où ces modifications étaient nécessaires, nous soumettions la requête de changement de code à l’équipe « Quality » qui ensuite allait produire un ‘fix‘ à fournir aux clients.

L’équipe  ‘IBM Content Engine’ à laquelle j’appartenais était composée de 12 membres et nous parlions neuf langues afin de pouvoir communiquer avec la majorité de nos collègues européens.

Cas concret :

J’ai reçu un incident au niveau 3 pour une société britannique dont le serveur de production GED ne fonctionnait plus : il était  impossible d’insérer et/ou de rapatrier des documents. En consultant l’analyse des supports niveaux 1 et 2 je me suis aperçu que bon nombre d’opérations avaient déjà été effectuées :

– La machine avait été restaurée complètement depuis une sauvegarde

– Les derniers niveaux de correctifs avaient été installés sur la machine

– Le serveur avaient été entièrement reconfiguré.

Malheureusement aucune de ces actions n’a résolu l’incident. La machine était un serveur Unix AIX sur lequel seul le logiciel de dématérialisation était installé. Aucune mise à jour ou changement n’avait été appliqué avant l’incident.

Les symptômes étaient les suivants :

– Dès que le logiciel démarrait, celui-ci produisait des messages d’erreurs au bout de quelques secondes et ceux-ci ne s’arrêtaient pas. Ces messages étaient peu équivoques : ils déclaraient une erreur ‘majeure’ de connexion entre le serveur et la baie de disques où se trouvaient les documents.

Toutes les pistes concernant le serveur ayant été analysées sans succès, je me suis penché sur la baie de disques. Les membres de l’équipe stockage de cette entreprise m’avaient précisé qu’aucun changement n’avait été effectué et que les données étaient bien présentes.

J’ai cherché pendant plusieurs jours des pistes sur la baie de disques, en vain. Mon opinion était que le serveur GED était hors de cause dans l’incident. Après plusieurs jours, j’ai trouvé un log sur la baie de disques qui faisait référence aux actions de re-configurations automatiques de la baie. A la lecture de ce log j’ai constaté qu’une action automatique avait été faite la veille de l’incident un : ‘swap network adapter’.

Il s’avère que cette baie était capable de remplacer un disque dur cassé ‘à chaud’ en utilisant un disque neuf prévu à cet effet et, de la même manière, cette baie était aussi capable de remplacer un adaptateur réseau dans le cas où un de ceux-ci était défectueux. J’ai suivi cette piste en comparant la configuration de tous les adaptateurs réseaux ainsi que de celui qui venait d’être fraîchement remplacé.

J’ai eu la surprise de constater que le mode ‘Duplex‘ de toutes les cartes réseaux était différent : le mode ‘Duplex’ sert à gérer la vitesse de transmission des données à travers ces dites ‘cartes réseaux’.

Après avoir modifié la configuration des adaptateurs réseaux de manière à ce qu’elle soit identique sur chaque adaptateur, l’incident disparut. Le problème était que, lorsque le logiciel de GED démarrait, il testait la vitesse d’accès aux données à travers chaque adaptateur réseau, et comme cette vitesse était différente, l’application considérait que l’accès à la baie n’était pas fiable et refusait donc de démarrer.

Conclusion :

L’entreprise a commis l’erreur de ne pas configurer l’alerte email pour obtenir des informations sur les actions que la baie pouvait effectuer par elle-même.

De notre côté, nous avons développé un patch afin de changer les comportements suivants :

– Lorsque le logiciel démarre en testant la vitesse de l’accès aux données, dans le cas où celle-ci n’est pas uniforme, le message d’erreur devient plus explicite.

– D’autre part, nous avons effectué une modification quant au comportement du logiciel : ainsi même si la vitesse d’accès aux données n’est pas satisfaisante, le logiciel y accèdera tout de même mais en émettant des messages d’erreurs clairs.