Sauver la sauvegarde, à l’usage des DSI

Bref, comme le disait l’un de mes formateurs à qui je brandissais une disquette quand il me demandait si j’avais bien fait les sauvegardes : non, ça, c’est un bout de plastique, ce n’est pas une sauvegarde ; si tu arrives à la restaurer, alors c’est une sauvegarde. J’ai toujours été étonné de la légèreté avec laquelle est traité le sujet de la sauvegarde, d’autant que c’est certainement l’un des motifs qui ont dû valoir à pas mal de DSI malchanceux de passer au bureau du personnel pour aller chercher leur solde de tout compte. Mais en même temps le sujet est sacrément plus compliqué qu’il n’y paraît.

Le problème de fond provient de la déconnexion entre la vision du technicien ou de l’ingénieur informatique et celle de l’utilisateur : le premier copie des 0 et des 1 sur un support (bande magnétique, support optique, flash, disque dur, etc.) et rendra ces 0 et ces 1 quand on le lui demandera, alors que le second a besoin de revenir « un peu en arrière dans le temps » en cas d’effacement accidentel de données et s’attend à retrouver un environnement de travail opérationnel, au delta près de la perte de données de quelques heures ou quelques jours. Aussi ballot qu’il en paraisse – outre la question de la fiabilité du support physique, ceux qui en ont bavé avec les bandes magnétiques coincées dans un lecteur savent de quoi je parle –, la plupart des « incidents » de sauvegarde proviennent du fait que l’on n’a tout simplement pas sauvegardé ce qu’il fallait. Il manque un fichier, un répertoire, un tablespace ou que sais-je, et lorsque l’on s’en aperçoit, c’est justement le jour où l’on a besoin de restaurer, et on vit alors un grand moment de solitude – j’ai testé pour vous.

Pour sortir de cette situation kafkaïenne, il faut – selon votre humble serviteur – raisonner en classe de services. La sauvegarde est un service que la DSI rend à ses utilisateurs (ou, dans les grosses DSI, que le secteur Infrastructure rend au secteur Applicatif/MOA), et pour tout service il existe des conditions d’entrée et une limite d’usage. Une approche possible est la suivante :

Premier point : les progiciels se divisent en deux catégories, ceux qui sont critiques et ceux qui ne le sont pas.Deuxième point : il est nécessaire de définir des niveaux de prestation, qui sont cumulatifs. Par exemple :
Niveau 1 : la DSI sauvegarde des 0 et des 1, et assure qu’elle est capable de les restaurer.
Niveau 2 : en plus, la DSI garantit que les 0 et les 1 sauvegardés permettent de remonter un service applicatif (un processus DB, un batch, etc.). À ce stade, la DSI ne garantit pas que l’application refonctionne.
Niveau 3 : en plus, la DSI est capable de garantir que l’application refonctionne, au sens où l’on est capable d’ouvrir un écran, de naviguer dans les données, etc. Mais, à ce stade, l’application en question fonctionne en mode « standalone », c’est-à-dire sans aucune interopérabilité avec le reste du SI.
Niveau 4 : en plus, la DSI garantit que l’interopérabilité est fonctionnelle, au sens où l’application en question est en phase avec l’état des autres applications connexes au sein du SI.
Troisième point : la DSI doit effectuer des tests de restauration, qui ne sont pas les mêmes selon que les applications sont critiques ou pas.
Dernier point : conformément à Itil, l’engagement de service n’est jamais atteint à 100 %, mais à 80 %.

Ce découpage peut donner l’engagement suivant (c’est un exemple) :
Pour les serveurs de fichiers, le service garanti par la DSI est de niveau 1 et aucun test n’est réalisé (on considère que les restaurations régulières demandées par les utilisateurs tiennent lieu de test).
Pour les applications non critiques, le service garanti par la DSI est de niveau 2 et le test de restauration n’est effectué qu’une seule fois, à la première mise en production de l’application.
Pour les applications critiques hors DPI, laboratoires et Imagerie, le service garanti par la DSI est de niveau 3 et les tests de restauration sont effectués à chaque changement majeur.
Pour le DPI, les laboratoires et l’imagerie, le service garanti est de niveau 4 et les tests sont les mêmes que pour les autres applications critiques.

Dernières remarques : d’une part, je n’ai jamais vu aucune DSI (tout au moins dans le monde de la santé) capable de garantir le niveau 4. D’autre part, ne pas formaliser le niveau de service, et surtout ne pas le communiquer ni l’afficher, est une excellente méthode pour un DSI de raccourcir le délai qui le sépare du jour où il ira chercher son solde de tout compte.

À vos marques…

[email protected]