Estimation d'une migration de données

La migration en elle-même est la partie la plus simple. C’est lors de l’étape de rapprochement que vous avez oubliée que se cachent les difficultés.

Une migration de données — le transfert de données d’un système à un autre, ou d’un format à un autre au sein d’un même système — s’apparente à une transformation. Lecture depuis la source, transformation, écriture vers la destination, basculement du trafic. L’équipe se prononce sur la transformation. Celle-ci constitue généralement la tâche la plus simple de l’itération. Les difficultés résident dans ce que la transformation ne voit pas : des enregistrements qui semblent corrects mais qui font référence à des données qui n’ont pas été transférées, des enregistrements qui semblent erronés mais qui sont en réalité corrects d’une manière que le cahier des charges n’a pas prise en compte, des cas limites qui n’ont survécu que parce que l’ancien système les tolérait et que le nouveau ne le fait pas.

Il s’agit d’un problème différent de celui de la migration d’une base de données. Une migration de schéma modifie la structure d’un magasin de données dont le contenu est déjà en place. Une migration de données transfère des données d’un système à un autre, et la question n’est pas « l’instruction ALTER sera-t-elle terminée à temps ? » », mais « que faire des lignes qui ne correspondent à aucune des deux bases ? ». L’essentiel du travail consiste en la réconciliation, la stratégie de basculement et la restauration. Le code de transformation est la partie que l’on écrit le plus rapidement et que l’on termine en dernier.

Ce qui se dit dans la salle

Backend : « C’est un script. Lecture, mise en correspondance, écriture. Deux jours maximum. »

Ingénieur de données : « Avez-vous vérifié à quel point la source est « sale » ? »

SRE : « Quelle sera la méthode de basculement : « big bang » ou « dual-write » ? »

Chapeau : « Qui se charge de résoudre les problèmes liés aux lignes qui ne migrent pas correctement ? »

PM : « Quand allons-nous mettre fin à l’ancien système ? »

C’est la question posée par le Premier ministre qui doit guider l’estimation. Si l’ancien système est supprimé dans un mois, vous avez besoin d’une stratégie garantissant une exactitude de 100 % ; s’il continue de coexister avec le nouveau pendant deux trimestres, vous pouvez vous permettre de reporter le traitement de la « longue traîne » à plus tard. L’estimation ne porte pas sur la transformation, mais sur la stratégie.

Questions qu’il convient de se poser avant de voter

Quelle est la qualité des données sources : propres, erronées ou inconnue ?
Stratégie de migration : « big bang », double écriture, lecture en mode « shadow », progressive ?
Pendant combien de temps ces deux systèmes coexisteront-ils ? Y a-t-il une date butoir ?
Qui se charge de résoudre les problèmes liés aux lignes qui ne sont pas correctement transférées, et à partir de quel seuil ?
Quelle serait la procédure de retour en arrière si le nouveau système recevait des données erronées après la migration ?
Y a-t-il des consommateurs en aval (rapports, intégrations) qui doivent être migrés de manière synchronisée ?

Si l’équipe attribue une note de 5 et que quelqu’un s’exclame « Attendez, qu’en est-il des enregistrements du journal d’audit ? », ce n’est pas que vous ayez eu un problème d’estimation ; c’est que vous aviez deux stories présentées comme une seule. Séparez-les : la transformation constitue un ticket, tandis que le plan de rapprochement et de basculement en constitue un autre.

Votez sur la stratégie, pas sur la transformation. La transformation dure deux jours. La stratégie, c’est le trimestre.

Consultez la page « Estimation d’une migration de base de données » pour la variante de modification de schéma sur un seul système, ainsi que les autres exemples d’estimations concrets. Lancez une session gratuite de Planning Poker une fois que la stratégie de basculement a été esquissée.