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’une structure à une autre au sein d’un même système) s’apparente à une transformation. Lecture à partir de la source, transformation, écriture dans 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 perçoit 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, ce qui n’est pas le cas du nouveau.

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’une base de données contenant déjà des données. 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 ? ». La majeure partie du travail consiste en un rapprochement des données, l’élaboration d’une stratégie de basculement et la restauration. Le code de transformation est la partie que vous écrivez le plus rapidement et que vous terminez 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 erronée ? »

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

Chapeau : « Qui se charge de corriger les lignes qui ne se migrent pas correctement ? »

Premier ministre : « À quelle date allons-nous mettre fin à l’ancien système ? »

C’est la question posée par le Premier ministre qui doit déterminer l’estimation. Si l’ancien système disparaît dans un mois, vous avez besoin d’une stratégie garantissant une exactitude à 100 % ; s’il continue de fonctionner parallèlement au 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 parallèle, 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 restauration si le nouveau système recevait des données erronées après la migration ?
• Existe-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 qu’il y avait 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 tout le trimestre.

Consultez la section consacrée à l’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’estimation concrets. Lancez une session gratuite de « planning poker » une fois que la stratégie de basculement aura été esquissée.