Comment je vérifie qu’une migration de données est arrivée intacte

Un traitement de migration qui se termine sans erreur prouve une seule chose : il s’est exécuté. Il ne prouve pas que toutes les lignes sont arrivées, que les totaux concordent toujours ni que les rapports lus le lendemain matin disent la même chose que la veille. Depuis 2009, une grande partie de mon travail consiste à déplacer des données bancaires et d’assurance d’un endroit à un autre, et c’est à la preuve que je consacre le plus de soin.

Comparer le nouveau chargement avec l’ancien

Quand j’ai dirigé la migration de plus de 100 traitements de l’entrepôt de données de Pentaho vers Azure Data Factory dans une grande banque des Caraïbes, les anciens traitements ont continué de tourner pendant la construction des nouveaux. Nous avions donc mieux qu’une spécification pour tester : le résultat réel du système que nous remplacions.

Chaque chargement migré a été comparé à l’ancien avec des scripts de validation et de profilage. La même source, le même jour, deux résultats et un script qui dit s’ils concordent. Écrire ces scripts une fois et les exécuter sur chaque lot a aussi réduit les tests manuels de 40 %.

Vérifier par lots, pas à la fin

Les plus de 100 traitements n’ont pas été mis en production d’un coup. Avec le scrum master et les product owners, nous les avons découpés en épopées et en tâches de sprint, et chaque lot était mis en production et vérifié avant le suivant.

Un problème trouvé dans un lot de cinq traitements a cinq endroits où se cacher. Le même problème trouvé après la mise en production de cent traitements en a cent, et à ce moment-là les rapports du matin en dépendent déjà.

Rendre les écarts visibles

Certains enregistrements ne concorderont pas, et c’est normal : les données sources contiennent des erreurs, des cas particuliers et des règles dont seule une personne du métier se souvient. L’erreur, c’est de les forcer pour que les totaux paraissent propres.

Dans un traitement mensuel de facturation et de rapprochement que j’ai construit pour un organisme de santé à Porto Rico, le résultat comporte trois éléments : la facturation, le rapport de rapprochement et une liste des enregistrements qui ne concordent pas. Cette liste est revue par une personne. Une courte liste d’exceptions que quelqu’un lit vaut mieux qu’un total parfait que personne ne peut expliquer.

Garder une personne là où se prend la décision

Ce même traitement est lancé depuis un écran de l’application, parce qu’un utilisateur revoit et confirme les résultats en cours de route. L’automatisation fait le gros du travail; la personne qui répond des chiffres décide de ce qui est facturé.

Ce que je vérifie

• Le nouveau résultat concorde avec l’ancien, vérifié par un script, pas à l’œil.
• Chaque lot est prouvé avant le début du suivant.
• Les enregistrements qui ne concordent pas finissent sur une liste, pas dans le total.
• La personne responsable des chiffres voit les exceptions avant que rien ne soit définitif.

Rien de tout cela n’est compliqué. Il faut seulement le prévoir dès le premier jour, parce qu’une migration qu’on ne peut pas prouver est une migration qu’on vous demandera de refaire.