Scott Matteson est administrateur système et réseau depuis 25 ans, principalement auprès de PME. « Cela m’a fourni une multitude de possibilités de commettre des erreurs et d’en tirer des leçons ! Vous pourriez dire que j'ai tout vu », écrit-il dans TechRepublic.
Certes, les erreurs sont humiliantes, poursuit-il, mais elles peuvent également vous aider à devenir un meilleur professionnel, à tout le moins si vous en analyser la source après coup. « Il est très gratifiant de mettre en œuvre de nouveaux processus plus performants et efficaces et de les voir ensuite utiliser par votre organisation (et par vous-même). »
Ceci dit, Scott Matteson partage ici les leçons apprises après ce qu’il considère comme « l'une de mes plus grandes erreurs ». Elle s'est produite il y a plusieurs années, avant la mise en place de contrôles plus stricts et de mécanismes d'approbation des changements.
Malheureusement, cette erreur a eu des conséquences dans son entreprise. «Et j'ai perdu une ami .»
Sur le même sujet :
5 erreurs qu’une entreprise doit éviter sur les médias sociaux
Trois moyens sûrs de se relever après un échec
2 mauvaises habitudes qui nuisent à votre crédibilité
Une opération de routine
Scott Matteson travaillait alors pour une PME qui comptait quelque 200 employés. Le département informatique gérait tout : installation et maintenance de serveurs, des applications, mise en réseau, modifications du pare-feu, sauvegardes et, bien sûr, courriers électroniques.
C’est lors d’une opération relative aux courriels que le drame est survenu. Exchange 2010 était réparti sur deux sites: le principal (où Matteson travaillait) et le site de récupération d'urgence (un site de reprise après sinistre), qui était situé dans un autre État américain. « En tant qu'administrateur Exchange, il était de ma responsabilité de tester le basculement des opérations de messagerie de notre site principal vers notre site de reprise en cas de sinistre. Il s’agissait de nous assurer que, même en cas de panne de notre site principal, nous pourrions mener à bien les opérations de messagerie sur notre site de reprise. »
Cela impliquait d'exécuter une série de scripts. Le processus avait été testé avec succès dans le passé. L'opération en était une de routine, une trentaine de minutes tout au plus. Les courriels seraient inaccessibles de cinq à quinze minutes, selon le délai d'exécution des processus.
« Il est toujours délicat d'essayer de trouver le bon moment pour faire ce type d'opérations. Je l'ai planifié de midi à 12 h 30, en pensant que la plupart des gens seraient en train de dîner. »
Il a envoyé un avis de maintenance par courriel deux jours à l'avance et juste avant l'opération.
Problème...
Il s'est avéré que l’opération a pris plusieurs heures de plus que prévu à l'origine. « En un mot, je ne pouvais pas activer les bases de données de messagerie sur les serveurs de récupération après sinistre, en raison d’une série d'erreurs de cryptage. Chaque site semblait penser que l'autre était le site principal et ne coopérerait pas.»
Il n’y avait plus aucun courriel qui sortait ou rentrait dans l’entreprise.
La fenêtre de maintenance de 12 h 30 était largement dépassée. Les utilisateurs voulaient, bien entendu, retrouver leur messagerie, essentielle à leur boulot.
« Je n'avais aucun moyen de les informer que leur courriel était toujours en panne, car bien sûr, je ne pouvais pas utiliser le courriel ! »
Matteson pensait pouvoir résoudre le problème lui-même. Ça n’a pas été le cas. Mais alors qu’il était au téléphone avec le support technique de Microsoft, un responsable du service à la clientèle de son entreprise a aussi contacté le même département. Il était furieux. « Est-ce que Matteson comprend l'importance du courriel?», beuglait ce directeur.
« Je pouvais entendre le personnel du centre d’assistance de Microsoft qui tentait de le calmer. J’ai toujours eu de bons rapports avec lui, mais nos liens n’étaient pas assez forts pour surmonter cette épreuve. »
Le problème a été résolu après beaucoup de travail. Le courrier électronique a été de retour vers 16 heures… « Oh !, et il a fallu environ six mois à ce responsable du service à la clientèle pour s'en remettre. »
Leçons apprises
Scott Mattison a beaucoup appris de cette manœuvre qui a mal tourné.
Voici ses recommandations :
- Planifiez toujours un entretien, même simple, après les heures normales de bureau.
- Ne présumez jamais que quelque chose fonctionnera simplement parce que cela a déjà été fait auparavant.
- Testez la structure globale pour vous assurer que les systèmes, les applications et les composants sont sains avant de les modifier.
- Ayez un plan de sauvegarde valide.
- Prévoyez une autre façon d’envoyer des notifications aux utilisateurs (message instantané, textes, site web interne de l'entreprise pour signaler les problèmes, etc) si vous faites quelque chose qui pourrait avoir une incidence sur les communications normales.
- Si l’impensable se produit, placez un panneau « physique » dans votre département où l’on pourra lire: "Nous connaissons le problème [type de]. Le délai de résolution est de [X date et heure] .
- Obtenez l’aide des meilleures ressources disponibles dès que possible, et notamment celle du fournisseur.
- Ne vous formalisez pas trop avec l'hostilité ou l’exaspération de vos collègues. En fin de compte, personne ne se blesse ni ne meurt en cas de panne informatique (espérons-le).
- Documentez ce qui n'a pas fonctionné et voyez comment l'éviter à l'avenir. Dans notre cas, nous avons fait tout ce qui précède et le problème n’est pas revenu.
