Choisir la bonne stratégie de récupération de base de données pour votre équipe

Vous venez de déployer une migration de base de données en production. Cinq minutes plus tard, le tableau de bord de monitoring montre un pic de requêtes en échec. Votre équipe se retrouve dans une situation familière : il faut réparer, et vite. Mais la façon de réparer dépend de bien plus que des compétences techniques. Cela dépend de qui vous êtes, de la fréquence de vos déploiements et du type d'application que vous exécutez.

Il n'existe pas de réponse universelle pour la récupération de base de données. La stratégie qui fonctionne pour une petite équipe qui livre une fois par semaine échouera pour une équipe qui déploie dix fois par jour. L'astuce n'est pas de trouver la stratégie parfaite, mais d'en trouver une que vous pouvez exécuter de manière cohérente sous pression.

La taille de l'équipe et la fréquence de déploiement comptent

Une équipe de trois personnes qui déploie une fois par semaine a un problème de récupération très différent d'une équipe de vingt personnes qui déploie plusieurs fois par jour.

Lorsque vous déployez rarement, vous savez exactement ce qui a changé. Il n'y a eu que quelques migrations la semaine dernière, et tout le monde dans l'équipe s'en souvient. Si quelque chose ne va pas, vous pouvez envisager d'exécuter une down migration pour annuler le changement de schéma. Le risque de collision avec le travail d'un autre membre de l'équipe est faible, car personne d'autre ne déployait au même moment.

Imaginez maintenant une équipe qui déploie toutes les quelques heures. Au moment où vous remarquez un problème avec votre migration, trois autres développeurs ont peut-être déjà poussé de nouvelles migrations par-dessus la vôtre. Exécuter une down migration dans cet environnement est dangereux. Vous pourriez annuler votre changement, mais aussi effacer la migration de quelqu'un d'autre qui était parfaitement valide. Le risque de collision est élevé et les conséquences sont désastreuses.

Pour les équipes à haute fréquence, les down migrations deviennent un handicap. Elles fonctionnent en théorie mais causent le chaos en pratique. Ces équipes ont besoin d'une stratégie de récupération qui ne suppose pas qu'elles sont les seules à faire des modifications.

La tolérance aux temps d'arrêt façonne vos options

Toutes les applications ne peuvent pas se permettre d'être indisponibles pendant que vous corrigez un problème de base de données. Votre tolérance aux temps d'arrêt détermine directement les stratégies de récupération qui s'offrent à vous.

Si vous gérez une application interne utilisée par cinquante personnes pendant les heures de bureau, vous pouvez peut-être vous permettre d'arrêter le système pendant cinq minutes. Cela vous donne la marge nécessaire pour restaurer à partir d'une sauvegarde ou exécuter une down migration qui prend du temps. Les utilisateurs seront contrariés, mais l'impact sur l'activité est limité.

Considérez maintenant une application publique gérant des milliers de requêtes par seconde. Chaque minute d'indisponibilité coûte du chiffre d'affaires et érode la confiance des utilisateurs. Restaurer à partir d'une sauvegarde peut prendre vingt minutes ou plus. Ce n'est pas acceptable. Dans ce scénario, le roll-forward est presque obligatoire. Vous écrivez une nouvelle migration qui corrige le problème, vous la déployez, et vous passez à autre chose. La correction prend quelques secondes à appliquer, pas des minutes.

La même logique s'applique aux scripts de compensation. Si vous savez que vous travaillez sur un changement à haut risque, préparez le script de compensation avant de déployer la migration d'origine. N'attendez pas que quelque chose casse. Quand la pression monte, votre capacité à écrire du SQL correct sous une contrainte de temps chute considérablement. Un script pré-écrit supprime cette charge cognitive.

Le type de changement détermine le niveau de risque

Tous les changements de base de données ne comportent pas le même risque. Ajouter une colonne nullable ou créer une nouvelle table est un faible risque. Ces changements sont faciles à corriger en roll-forward car ils ne cassent pas les requêtes existantes. Vous pouvez ajouter la colonne, déployer le code applicatif qui l'utilise, et tout fonctionne.

Mais supprimer une colonne, changer un type de données ou migrer des données entre tables est un risque élevé. Ces changements peuvent casser des requêtes encore en cours d'exécution en production. Ils peuvent verrouiller des tables pendant des minutes ou des heures. Ils peuvent corrompre les données si la logique de migration contient un bug.

Pour les changements à haut risque, ne comptez jamais sur une récupération réactive. Vous devez planifier le chemin de récupération avant d'exécuter la migration. Cela signifie écrire le script de compensation à l'avance. Cela signifie tester le chemin de roll-forward dans un environnement de préproduction. Cela signifie savoir exactement ce que vous ferez si la migration prend plus de temps que prévu ou si elle réussit mais produit des données erronées.

La stratégie par défaut : le roll-forward d'abord

Après avoir travaillé avec de nombreuses équipes, un schéma clair se dégage. Les équipes matures privilégient le roll-forward par défaut. Les down migrations sont réservées aux environnements de préproduction ou aux premiers stades de développement. Les sauvegardes sont traitées comme un filet de sécurité pour les pannes catastrophiques, et non comme un mécanisme de retour arrière quotidien. Les scripts de compensation sont utilisés lorsque les données doivent être réparées sans modifier le schéma.

La raison pour laquelle ce schéma fonctionne est la cohérence. Lorsque vous utilisez toujours le roll-forward, vous développez des habitudes qui facilitent la récupération. Vous écrivez des migrations plus petites et plus fréquentes. Vous testez votre chemin de roll-forward à chaque fois. Vous vous habituez à l'idée que résoudre un problème signifie déployer un autre changement, pas annuler le dernier.

Les équipes qui mélangent les stratégies ont souvent du mal. Une semaine elles utilisent une down migration, la semaine suivante elles restaurent à partir d'une sauvegarde, la semaine d'après elles écrivent un script de compensation à la volée. Chaque incident nécessite une nouvelle décision sous pression. C'est là que les erreurs se produisent.

Liste de contrôle pratique pour choisir une stratégie de récupération

• À quelle fréquence votre équipe déploie-t-elle ? Si c'est plus d'une fois par jour, évitez les down migrations en production.

La liste de contrôle ci-dessus est un bon début, mais un arbre de décision visuel peut rendre le choix encore plus clair sous pression. Voici un organigramme simple pour guider la sélection de la stratégie de récupération de votre équipe :

• Votre application peut-elle tolérer cinq minutes d'indisponibilité ? Si non, le roll-forward devrait être votre valeur par défaut.
• Votre migration ajoute-t-elle une colonne ou en supprime-t-elle une ? Les changements à haut risque nécessitent un script de compensation pré-écrit.
• Disposez-vous d'un environnement de préproduction qui reflète la production ? Testez-y d'abord votre chemin de récupération.
• Votre équipe s'est-elle mise d'accord sur une stratégie par défaut ? La cohérence est plus importante que la perfection.

L'essentiel à retenir

Votre stratégie de récupération de base de données n'est pas une décision technique. C'est une décision d'équipe façonnée par la façon dont vous travaillez, la fréquence à laquelle vous livrez et ce que vos utilisateurs peuvent tolérer. La meilleure stratégie est celle que votre équipe peut exécuter sans hésitation quand quelque chose tourne mal. Choisissez-en une, entraînez-vous, et faites-en votre valeur par défaut. Cette cohérence vous fera gagner plus de temps que n'importe quel outil ou script.