Estimation de la migration d'une base de données

« Ajouter une colonne » correspond à une migration d’une seule ligne. L’estimation ne concerne pas la colonne.

Les migrations de schéma s’effectuent selon deux cadences. L’une est celle du SQL : généralement rapide, généralement mécanique. L’autre est le « temps opérationnel » : combien de temps la table reste-t-elle verrouillée, comment le processus se comporte-t-il en cas d’écritures simultanées, comment annuler l’opération en cas d’échec, et quel est le plan d’urgence si l’exécution dépasse la fenêtre de déploiement ? L’équipe se prononce sur le code SQL, car c’est ce qui figure sur le ticket. Le travail s’effectue quant à lui selon le « temps opérationnel ».

Sur une petite table, les deux horloges sont identiques et l’histoire est vraiment insignifiante. Sur toute table qui compte, ce n’est pas le cas. L’estimation doit tenir compte du remblayage, de la stratégie de déploiement et de la procédure de retour en arrière, que quelqu’un doit avoir répétées avant que le déploiement ne s’approche ne serait-ce qu’un peu de l’environnement de production.

Ce qui se dit dans la salle

Backend : « Ce n’est qu’une instruction ALTER, la migration s’exécute en une seconde. »

SRE : « Dans le tableau des commandes ? Avec les verrous activés ? À 15 h ? »

DBA : « Comment procédons-nous pour compléter les lignes existantes ? »

SRE : « Quelle est la procédure de restauration si le déploiement échoue à mi-parcours ? »

Point clé : « Le parcours de lecture tolère-t-il que la colonne soit nulle pendant une heure ? »

Questions qu’il convient de se poser avant de voter

• Quelle est la taille de la table : des milliers, des millions, des centaines de millions de lignes ?
• Outil de migration en ligne ou commande ALTER sur place ?
• Stratégie de remplissage : synchrone, par lots, double écriture ?
• Quel est le rôle du chemin de lecture pendant la fenêtre de déploiement ?
• Rétroaction : uniquement vers l’avant, ou peut-on revenir en arrière dans le schéma ?
• Quelqu’un a-t-il suivi le plan d’intervention prévu pour cette migration ?

Si la moitié de l’assemblée vote pour « le SQL » et l’autre moitié pour « le déploiement », vous n’avez pas un problème de chiffrage ; vous avez deux cas de figure présentés comme un seul. Séparez-les : la modification du schéma constitue un dossier, le plan de mise à jour rétrospective et de déploiement en est un autre.

Évaluez le déploiement et la restauration, et non l’opération ALTER. C’est lors de la deuxième étape que réside le risque.

Consultez la rubrique « Estimation d’une migration de données » pour la variante inter-systèmes, ainsi que les autres exemples d’estimations concrets. Lancez une session gratuite de Planning Poker une fois que le déploiement a été esquissé.