Datawarehouse : la gestion des incidents se heurte au mur des coûts

Des bonnes pratiques… 

Pour Stephen Brobst, il est pragmatiquement irréaliste et impertinent de vouloir déployer un système de datawarehouse complètement redondant, « avec réplication complète des données au niveau des disques » : « il faut identifier 30 à 50 % de données que l’on va considérer comme critiques. Et choisir en conséquence le matériel nécessaire. » Au-delà, il n’est pas non plus question de laisser dormir le système de secours pendant que le système principal est en production : « vous allez payer pour ce second système en espérant ne jamais l’utiliser… C’est une stratégie d’assurance très onéreuse. » Du coup, le directeur technique de Teradata recommande une approche en « double actif » : « nous fournissons les logiciels qui permettent de répartir la charge sur les deux systèmes en activité. Notre gestionnaire de requêtes va comprendre quelles applications vont pouvoir fonctionner sur quel système – ou sur les deux. En plus de retirer plus de valeur de vos investissements, vous aurez l’assurance, en cas de panne, que le second système fonctionne, puisqu’il fonctionne déjà au quotidien. » D’ailleurs, pour Stephen Brobst, souvent, « lorsque, un fois par an, on teste le système de secours, on s’aperçoit que cela ne fonctionne pas ». Et pour toutes sortes de bonnes raisons comme, par exemple, un changement de configuration qui n’aurait pas été rapporté : « et personne ne veut découvrir que le système de secours ne fonctionne pas au moment d’un véritable désastre… » 

En fait, Teradata a développé cette approche de « double actif » dès le début des années 2000 ; le directeur technique de l’époque, Todd Walter, l’avait présentée, notamment, en 2003, lors de la conférence annuelle Teradata Partners. Le constructeur se plaît d’ailleurs à mettre en avant l’exemple d’Airlines Reporting Corporation (ARC), une chambre de compensation dédiée à l’industrie du transport aérien civil, qui a mis en œuvre cette architecture en 2005. ARC vient d’être récompensée par nos confrères de Computerworld pour, notamment, l’architecture de son SI décisionnel. 

… à un certain artisanat 

Sans dévoiler l’architecture retenue pour le plan de reprise d’activité de son système de datawarehousing, l’utilisateur évoqué plus haut met en avant les procédures de tests d’acceptation : « la clé, c’est de savoir quelle quantité de données vous êtes prêts à perdre en cas de panne majeure », explique-t-il donc. Une réflexion qui renvoie ainsi aux remarques de Stephen Brobst. 

Le DSI d’un spécialiste américain de l’intelligence économique, évoque quelques pistes supplémentaires : « par exemple, on peut définir des tables avec copie de secours ; deux copies d’un enregistrement sont disponibles en cas de panne. Ce n’est pas pleinement satisfaisant, mais c’est un début. » Pour lui, l’un des plus gros défis est « d’arbitrer entre la fréquence des sauvegardes, la taille des tables, etc. pour gérer le temps de remise en production de l’environnement en cas de panne. Typiquement, il m’est arrivé de voir des gens catégoriser des tables pour simplement faciliter l’identification des données critiques. » Une classification dédiée au PRA qui n’est pas forcément une mauvaise idée : « il est essentiel de classifier les données par criticité. » 

Et puis, il suffit de peu de chose pour que la reprise d’activité tourne court : « l’un de mes collaborateurs, alors qu’il travaillait pour un commerce de détail, a assisté une panne majeure lors d’une mise à jour – un paramètre de configuration avait été changé par erreur ; toutes les données ont été perdues. La reprise de l’activité a demandé 5 jours. » 

Au final, pour lui aussi, le coût et la complexité de ce type de projets ne sont pas négligeables. Ce n’est donc probablement pas innocemment que Teradata a lancé, fin juin dernier, une offre de service dédiée précisément à la continuité de l’activité, s’appuyant sur ses propres centres de calcul. Mais est-ce bien suffisant ? Notre DSI relève notamment quelques mauvaises pratiques susceptibles de remettre en cause de nombreux efforts : une autre forte adhérence du système de datawarehouse aux métiers, « comme source de données de classe opérationnelle », ou, à contrario, son cantonnement au rôle de zone d’enregistrement des données financières… « Le système de datawarehouse est là pour collecter et intégrer. C’est tout. »