Un jour, je parlais à un client qui n'avait aucune idée de la reprise après sinistre. Sa société avait une foi aveugle en son AS/400.
Il avait toujours fonctionné sans incident, et l'équipe IT faisait une sauvegarde complète tous les soirs. Nous avons tous eu foi en notre AS/400, notre iSeries, notre System i, etc. parce que ce sont tous des systèmes superbes. Mais comme on le dit souvent : « La confiance n'exclut pas le contrôle ». Dans l'entreprise de mon client, la confiance était là, mais le contrôle... beaucoup moins.
Un beau matin (si l’on peut dire), l’AS/400 ne faisait pas son travail habituel : exécuter des jobs, générer des impressions, stocker et extraire des données, etc…Il était immobile avec un nombre affiché, une lumière de couleur ambre. L’alerte fut aussitôt donnée. Le technicien arriva sur les lieux et dit : « Oh ! Je n’aime pas ça du tout » (nous non plus n’aimons pas du tout entendre ça.)
L’homme de l’art procéda à l’examen habituel et découvrit que le mal venait simplement d’un lecteur défectueux : rien de dramatique à l’ère de la protection RAID. Bon, entendons-nous bien : le client avait une protection RAID. Il approfondit sa recherche avec des outils de service du genre PAL (Problem Activity Log), SAL (Service Action Log), et autres, dont l’administrateur système moyen hésite à se servir, et découvrit la triste vérité : ce n’était pas le premier lecteur défaillant dans cet ensemble RAID. Une minute de silence pour les chères données disparues…
Aussitôt, l’administrateur prononça quelques mots de réconfort : « nous (gens intelligents) effectuons tous les soirs une sauvegarde complète du système. Donc, pas de souci, vous devez simplement remplacer les lecteurs. » Et c’est ainsi que les lecteurs défaillants furent remplacés, la protection rétablie, et que le système retrouva sa belle lumière jaune. Peine perdue, il lui manquait les données, les programmes, les utilisateurs, tout ce qui est la raison de vivre d’un AS/400. Aussitôt, la bande fut montée, les options de rechargement déclenchées, et la bande se mit à tourner. Elle tourna, elle tourna, puis s’arrêta. Et des messages très déplaisants s’affichèrent : les fichiers nécessaires n’existaient pas sur la bande.
Et le technicien, d’un ton prudent : « Je suppose que la bande n’était pas encore complètement écrite quand le lecteur est tombé en panne. Et si on essayait la bande précédente ? » Long et douloureux silence. Comme Joshua dans le film War Games quand il voit son « jeu » Global Thermonuclear Warfare aux infos du soir, l’administrateur a le souffle coupé et s’enfonce dans sa chaise. « Euh, c’est-à-dire que c’est la bande de la nuit précédente, et la nuit d’avant, et d’avant cela, et… en fait, nous ne changeons pas la bande. » Le principe de Murphy dans toute sa splendeur, ou si vous préférez, la loi de l’emm….. maximum : ce qui pouvait mal se passer c’est, en fait, mal passé.
La suite de votre dossier RAS :
RAS, Leçons à retenir
https://www.itpro.fr/lecons-retenir/
Le questionnaire RAS
https://www.itpro.fr/questionnaire-ras/
Téléchargez cette ressource
État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
