Écrivez le retour arrière d'abord : un modèle pour les mises à niveau de routine

Les plateformes prennent du retard pour une raison simple : chaque mise à niveau paraît risquée, donc elle est reportée, et chaque report rend la suivante plus grosse et plus risquée encore. La sortie est de rendre les mises à niveau ennuyeuses. Cela veut dire un modèle que vous suivez à chaque fois, et la ligne la plus importante de ce modèle est celle que la plupart des équipes écrivent en dernier : comment revenir en arrière.

Sachez qu'une version existe avant d'en avoir besoin

Nous publions chaque nouvelle build, avec son changelog, dans notre chat d'exploitation le jour de sa sortie.

Un raffinement vaut la peine d'être copié. Beaucoup de projets publient des correctifs pour les anciennes branches à côté de la branche courante. Un observateur qui annonce aveuglément « nouvelle version » peut tenter quelqu'un d'installer un rétroportage plus ancien que ce qui tourne déjà. Nous les étiquetons automatiquement « ne pas déployer », pour que personne ne recule par accident.

Préparez le changement

Lisez le changelog comme un contrat

Dans les notes de version, les migrations comptent le plus : tout ce qui s'exécute une fois et ne peut pas être facilement annulé, comme un changement de schéma, décide de ce que votre retour arrière doit inclure.

Vérifiez chaque serveur avant de commencer

Puis vérifiez chaque serveur que vous allez toucher, pas la flotte en général, et listez ses plugins, extensions et intégrations face à la nouvelle version.

Un plugin dont personne ne se souvenait est la raison la plus courante de l'échec d'une mise à niveau par ailleurs propre. Les lister par serveur prend quelques minutes et supprime la surprise.

Prenez une sauvegarde que vous avez réellement regardée

« Le job de sauvegarde a tourné » n'est pas la même chose que « nous avons une sauvegarde ». Avant le changement, prenez un dump cohérent et testez-le :

mysqldump --single-transaction --routines --triggers --events <db> \
  | gzip > <db>-pre-upgrade-$(date +%F-%H%M).sql.gz
gzip -t <db>-pre-upgrade-*.sql.gz && ls -lh <db>-pre-upgrade-*.sql.gz

Écrivez le retour arrière avant le changement

C'est l'étape qui transforme une mise à niveau risquée en mise à niveau de routine. Avant de commencer, écrivez, dans l'ordre, les étapes exactes qui ramèneraient le système là où il est maintenant. Sur les systèmes à base de RPM, le côté paquets est généralement court :

dnf history list | head
dnf history undo <transaction-id>

Et pour empêcher un paquet connu comme bon de bouger pendant que vous testez, le plugin versionlock l'épingle :

dnf versionlock add <package>

Mais les paquets sont rarement toute l'histoire. Si la version exécute une migration de schéma, revenir en arrière sur les seuls paquets vous laisse avec de l'ancien code sur un nouveau schéma. Votre retour arrière doit alors inclure la restauration du dump que vous venez de prendre, et vous devez savoir combien de temps cette restauration prend. Écrivez tout, et partout où vous le pouvez, répétez-le d'abord sur une copie. Un retour arrière qui n'existe que dans votre tête au moment où les choses tournent mal n'est pas un retour arrière.

Changez une machine à la fois

Sur les plateformes redondantes, un nœud à la fois. Les versions majeures vont d'abord sur nos propres instances et y tournent avant qu'une instance client ne les reçoive.

Mesurez et vérifiez

Mesurez l'arrêt au lieu de l'estimer

« Environ une minute » est une supposition. Une sonde qui tourne pendant tout le changement vous donne le vrai chiffre. Lancez-la avant de commencer et arrêtez-la quand vous avez terminé :

while true; do
  printf '%s %s\n' "$(date +%T.%3N)" \
    "$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://<service>/health)"
  sleep 0.5
done | tee upgrade-probe-$(date +%F).log

Ensuite, la première et la dernière ligne non-200 du journal encadrent l'interruption à une demi-seconde près. C'est le chiffre que vous rapportez aux personnes qui dépendent du service, et c'est le chiffre que vous comparez la fois suivante. Sur un trimestre, ces mesures sont la meilleure preuve que vous ayez que les mises à niveau deviennent plus sûres plutôt que plus risquées.

Vérifiez depuis l'extérieur, puis emmenez l'OS avec vous

Quand la mise à niveau est terminée, déclenchez une alarme de test pour savoir que la supervision voit toujours le service. Puis profitez de la même fenêtre pour mettre à jour aussi les paquets du système d'exploitation. Application et fondation restent au même pas, et la prochaine mise à niveau ne commence pas par une pile de mises à jour sans rapport.

Le modèle

• Version repérée et annoncée, rétroportages étiquetés.
• Changelog lu pour les correctifs de sécurité, les ruptures et les migrations.
• Chaque serveur vérifié au préalable, y compris chaque plugin.
• Sauvegarde fraîche prise et inspectée.
• Retour arrière écrit, étape par étape, avant le changement.
• Un nœud à la fois, les majeures d'abord sur vos propres systèmes.
• Arrêt mesuré par une sonde, rapporté en secondes.
• Vérifié depuis l'extérieur, OS mis à jour dans la même fenêtre.

Si vos plateformes ont pris du retard et que la prochaine mise à niveau ressemble à un projet, nous pouvons vous aider à revenir à la routine. Parler à un ingénieur

Related (rows[1])

Voir aussi : Plateformes à jour et discipline de mise à niveau · Réponse d'urgence aux vulnérabilités le jour même · Supervision de la flotte et routage des alarmes