Écrire un runbook de bascule de migration avec un chrono sur chaque étape

La différence entre une migration qui prend cinq minutes d'arrêt visible et une qui dévore un week-end tient rarement au matériel. Elle tient à savoir si la bascule a été écrite comme une séquence d'étapes chronométrées, vérifiables et réversibles avant la nuit, et répétée jusqu'à ce que les temps soient connus. Voici comment nous écrivons ce document.

Le problème : la nuit est le pire moment pour réfléchir

Chaque décision prise pendant la fenêtre (quelle synchronisation passe en premier, combien de temps attendre un réplica, quand renoncer et revenir en arrière) est prise par des gens fatigués, sous pression, généralement avec le propriétaire du site au téléphone. Le but d'un runbook est que personne n'ait à décider pendant la fenêtre quoi que ce soit qui aurait pu être décidé la semaine précédente.

Une liste de tâches n'est pas un runbook. Un runbook a cinq colonnes.

Les cinq colonnes

Étape	Budget	Responsable	Vérification	Retour
Geler les écritures sur la source	2 min	app	connexion admin refusée, file de commandes vide	lever le gel
Synchronisation finale des fichiers	3 min	ops	rsync ne détaille plus aucun changement	aucun besoin, source intacte
Rattrapage final de la base et promotion	3 min	db	GTID égal des deux côtés, cible en lecture-écriture	rétrograder la cible, dégeler la source
Basculer le DNS et le load balancer	2 min	net	nouvelle origine répond via le nom public	rétablir l'enregistrement
Tests de fumée	5 min	app	liste de pages, connexion, paiement, recherche	rétablir le DNS

Le budget est le temps que l'étape a pris en répétition, plus une marge. Le responsable est une personne, pas une équipe. La vérification est un fait observable, pas « ça a l'air bon ». Le retour est l'action exacte qui annule l'étape, et si une étape n'a pas de retour, c'est le point de non-retour et il doit être marqué comme tel.

Avant la fenêtre : déplacez presque tout en avance

La bascule ne doit déplacer que ce qui a changé depuis la dernière synchronisation. Tout le reste se fait des jours avant, pendant que la source continue de servir :

• Construisez la destination à neuf selon des spécifications mesurées, plutôt que de restaurer des images des anciens serveurs.
• Amorcez la base de données depuis une sauvegarde physique et maintenez-la à jour par réplication. La nuit venue, le rattrapage est une affaire de quelques secondes de delta.
• Pré-synchronisez les fichiers à plusieurs reprises, pour que la dernière passe soit petite. Faites un essai à blanc la veille pour voir ce que la passe finale déplacera :

rsync -aHAX --numeric-ids --delete --itemize-changes --dry-run \
      source:/var/www/ /var/www/ | wc -l

• Copiez les index de recherche avec la réindexation distante du moteur lui-même plutôt qu'en recrawlant le contenu à travers l'application.
• Abaissez les TTL DNS à quelques minutes au moins deux anciens TTL avant la fenêtre, pour que les résolveurs aient oublié la longue valeur au moment où vous basculez. Vérifiez ce que le monde voit réellement :

dig +noall +answer www.example.com @<public-resolver-1>
dig +noall +answer www.example.com @<public-resolver-2>

Répétez sur une copie, chronomètre en main

Exécutez toute la bascule contre une copie de la destination au moins une fois, avec les mêmes commandes, dans l'ordre, en chronométrant chaque étape. La répétition produit la colonne budget. Elle produit aussi les surprises : la synchronisation de fichiers qui parcourt lentement des millions de fichiers inchangés à cause d'un drapeau manquant, l'utilisateur de réplication auquel il manque un privilège, le health check qui pointe vers le mauvais chemin.

Ajoutez chaque leçon au modèle de runbook, pas seulement à la copie de cette migration. C'est ainsi que la dixième migration devient plus facile que la première.

Écrivez les critères go ou no go à l'avance

Convenez, avant la fenêtre et avec le propriétaire du site, de ce qui doit être vrai pour commencer, et de ce qui déclenchera un retour arrière :

• Go : retard de réplication sur la destination sous un chiffre convenu, dernière synchronisation à blanc dans le budget, supervision de la destination au vert, les personnes nommées dans la colonne responsable présentes.
• Déclencheur de retour arrière : toute étape dépassant deux fois son budget, ou les tests de fumée non concluants à une heure fixe après la bascule.

Écrire le déclencheur supprime l'instinct le plus dangereux de toute nuit de bascule : « donnons-lui dix minutes de plus ». Si le chrono dit de revenir en arrière, vous revenez en arrière, et vous réessayez une autre nuit avec un meilleur runbook.

Rendez le retour peu coûteux

Un retour arrière qui exige une restauration depuis la sauvegarde est un retour arrière que personne ne choisira d'utiliser. Concevez chaque étape pour que l'annuler soit rapide :

• La source reste intacte et en service jusqu'à ce que la destination ait fait ses preuves. Ses données ne sont jamais supprimées pendant la fenêtre.
• Sur la destination, tout ce qui est remplacé est renommé, jamais supprimé. Revenir en arrière est un renommage et un changement DNS.
• La promotion de la base de données n'a lieu qu'après que les deux côtés rapportent le même GTID, pour qu'une rétrogradation vous ramène à une position connue.
• Les changements de configuration sont appliqués comme des fichiers que l'on peut permuter, pas comme des modifications dont il faut se souvenir.

mv /var/www/site /var/www/site.pre-cutover-$(date +%F)
mv /var/www/site.new /var/www/site

Exécutez la fenêtre, puis auditez

Pendant la fenêtre, une personne lit le runbook à voix haute et note le temps réel face à chaque budget. Personne n'improvise. Quand le dernier test de fumée passe, gardez la source en service et observez les deux côtés : le trafic doit se vider de l'ancienne origine à mesure que les caches expirent. Tout ce qui arrive encore sur la source après l'expiration de l'ancien TTL est une dépendance que personne n'a listée, telle qu'une tâche cron, un client d'API ou une adresse codée en dur, et il faut la trouver avant d'éteindre la source.

Ensuite, comparez la nouvelle plateforme à l'ancienne référence : exposition externe, temps de réponse, taux de hit du cache, taux d'erreurs. Ce n'est qu'alors que vous retirez la source, et vous conservez ses données jusqu'à ce que le propriétaire ait donné son accord.

Votre liste de contrôle

• Chaque étape a un budget, un responsable, une vérification et un retour.
• Données amorcées et fichiers pré-synchronisés des jours avant ; la fenêtre ne déplace que le delta.
• TTL abaissés tôt et vérifiés depuis l'extérieur.
• Une répétition chronométrée sur une copie, avec les leçons reversées dans le modèle.
• Critères de go et de retour arrière convenus par écrit avant la nuit.
• La source conservée intacte jusqu'à la fin de l'audit et l'accord du propriétaire.

Si un déménagement se profile, nous serons heureux de vous aider à écrire le runbook.

Parler à un ingénieur

Related (rows[1])

Voir aussi : Migrations de datacenter infogérées, répétées · Réplication de bases de données et réplicas hors site · Migration à chaud et sorties d'hyperviseur