Plans de reprise pour les modifications d'infrastructure à haut risque

Vous vous apprêtez à effectuer un changement qui pourrait casser la production. Peut-être s'agit-il d'une refonte de l'architecture réseau, d'une migration de base de données ou d'une reconfiguration de groupe de sécurité qui touche des services critiques. L'équipe a examiné le plan, évalué le rayon d'impact, et tout le monde s'accorde à dire que le changement comporte un risque réel.

Et maintenant ?

Avant que quiconque exécute terraform apply ou clique sur le bouton de déploiement, vous avez besoin d'un plan de reprise. Pas d'un document épais qui prend la poussière sur une étagère. Un plan pratique, spécifique et exécutable, qui décrit quoi faire si les choses tournent mal.

Commencez par une question

L'ensemble du plan de reprise repose sur une seule question : si ce changement échoue, que devons-nous faire pour ramener le système à un état sûr ?

La réponse dépend de ce que vous modifiez et de l'étendue du rayon d'impact. Une simple modification de configuration sur un groupe de sécurité peut avoir une réponse courte : réappliquer l'ancienne configuration. Un changement d'architecture réseau ou une migration de base de données nécessite une réponse bien plus détaillée.

Ne compliquez pas les choses inutilement. Le plan de reprise doit être proportionnel au risque. Un plan de cinq lignes suffit pour un changement à faible risque. Un runbook en plusieurs étapes est approprié pour quelque chose qui pourrait mettre hors service un service critique.

Trois éléments essentiels pour tout plan de reprise

Un plan de reprise utile comporte trois composants, et ils doivent tous être explicites.

Des étapes de reprise concrètes. « Revenir à la version précédente » n'est pas une étape. Notez les commandes exactes, les serveurs sur lesquelles elles s'exécutent, les paramètres à utiliser et comment vérifier que la reprise a effectivement fonctionné. Si quelqu'un doit se connecter en SSH à un bastion et exécuter une commande Terraform spécifique avec un fichier d'état spécifique, dites-le. Si quelqu'un doit restaurer une base de données à partir d'un snapshot, incluez le nom du snapshot et la procédure de restauration.

Voici un exemple concret de ce à quoi ressemblent ces étapes de reprise pour une modification de groupe de sécurité sur AWS :

# Plan de reprise : Annulation d'une modification de groupe de sécurité
# Cible : sg-12345678 (niveau web de production)

# Étape 1 : Annuler les règles du groupe de sécurité
aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 10.0.0.0/16

# Étape 2 : Vérifier que les règles sont correctes
aws ec2 describe-security-groups \
  --group-ids sg-12345678 \
  --query 'SecurityGroups[0].IpPermissions'

# Étape 3 : Confirmer que le service est accessible
curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health

Qui décide d'activer la reprise. Quand les choses tournent mal, les gens paniquent. Ils commencent à prendre des décisions de leur côté. Certains voudront annuler immédiatement. D'autres voudront d'abord creuser le problème. Vous avez besoin d'une seule personne ou d'un seul rôle ayant l'autorité de dire « stop, on lance la reprise maintenant ». Ce n'est pas un processus démocratique pendant un incident. Nommez la personne ou le rôle explicitement dans le plan.

Quand activer le plan. Tous les échecs ne déclenchent pas une reprise immédiate. Parfois, il est préférable de laisser le changement s'appliquer pendant que l'équipe enquête. Mais vous avez besoin de limites claires. Deux approches courantes fonctionnent bien :

  • Basée sur le temps : si le système n'est pas stable dans les 15 minutes suivant l'application du changement, lancez la reprise.
  • Basée sur l'impact : si le taux d'erreur dépasse 5 %, ou si les utilisateurs signalent qu'ils ne peuvent pas accéder au service, lancez la reprise.

Notez ces seuils par écrit. Ne comptez pas sur les gens pour s'en souvenir pendant un incident.

La checklist pré-apply

Avant d'appliquer un changement à haut risque, certaines choses doivent déjà être faites. C'est votre checklist pré-apply, et elle fait partie du plan de reprise.

Les éléments courants incluent :

  • Dernier snapshot effectué
  • Fichier d'état de l'infrastructure sauvegardé
  • Accès aux systèmes de reprise confirmé
  • Les membres de l'équipe connaissent leur rôle pendant la reprise
  • Canal de communication établi pour la coordination des incidents

Cette checklist existe parce que vous ne pouvez pas vous préparer à la reprise pendant une urgence. Si vous n'avez pas pris de snapshot avant le changement, vous ne pourrez pas restaurer à partir de ce snapshot après coup. Si vous n'avez pas sauvegardé le fichier d'état, vous ne pouvez pas annuler en toute confiance.

Le diagramme suivant montre le flux complet, de la revue du changement aux vérifications pré-apply, en passant par l'application, la surveillance et l'exécution de la reprise si nécessaire.

flowchart TD A[Revue du changement] --> B[Vérifications pré-apply] B --> C[Appliquer le changement] C --> D[Surveiller le système] D --> E{Système stable ?} E -->|Oui| F[Changement terminé] E -->|Non| G[Évaluer l'impact] G --> H{Activer la reprise ?} H -->|Non| I[Continuer l'investigation] H -->|Oui| J[Exécuter les commandes de reprise] J --> K[Vérifier la reprise] K --> L[Système restauré]

La checklist pré-apply sert également de contrainte. Elle oblige l'équipe à s'arrêter et à confirmer que la reprise est réellement possible avant d'effectuer le changement. Si vous ne pouvez pas cocher chaque élément, n'appliquez pas encore le changement.

Qui approuve le plan de reprise

Pour les modifications d'infrastructure à haut risque, le plan de reprise doit être approuvé par une personne qui comprend l'impact et a l'autorité d'accepter le risque. Il peut s'agir d'un ingénieur principal, d'un responsable technique ou d'un représentant d'une équipe qui sera affectée par le changement.

Le titre importe peu. Ce qui compte, c'est que l'approbateur puisse évaluer si le plan de reprise est suffisant ou s'il y a des lacunes. Il doit être capable de poser des questions comme « Que se passe-t-il si l'annulation échoue aussi ? » ou « Comment vérifions-nous que le système est sain après la reprise ? »

Ce n'est pas une simple formalité. Si l'approbateur ne comprend pas assez bien le plan pour l'évaluer, il ne devrait pas l'approuver.

Stockez le plan là où on peut le trouver

Un plan de reprise est inutile si personne ne peut le trouver pendant un incident. Ne le stockez pas sur votre ordinateur portable. Ne le mettez pas dans un dossier qui nécessite un accès spécial. Ne l'enterrez pas dans une longue chaîne d'e-mails.

Placez le plan dans un emplacement partagé auquel toutes les personnes impliquées peuvent accéder rapidement. Wiki d'équipe, disque partagé, ou même en tant que fichier joint à la pull request qui contient la modification de l'infrastructure. L'objectif est de supprimer toute friction entre « quelque chose s'est mal passé » et « nous avons le plan sous les yeux ».

Une checklist pratique rapide

Avant d'appliquer un changement d'infrastructure à haut risque, passez en revue ceci :

  • Les étapes de reprise sont rédigées avec les commandes et paramètres exacts
  • Une personne spécifique est désignée pour décider quand activer la reprise
  • Les seuils de temps ou d'impact pour l'activation de la reprise sont définis
  • Le dernier snapshot ou la dernière sauvegarde est confirmé disponible
  • Le fichier d'état de l'infrastructure est sauvegardé
  • Tous les membres de l'équipe connaissent leur rôle pendant la reprise
  • Le plan est stocké dans un emplacement accessible à toutes les personnes impliquées
  • Une personne ayant l'autorité a examiné et approuvé le plan

Le vrai test a lieu pendant l'exécution

Un plan de reprise qui a été préparé et approuvé n'est pas la même chose qu'un plan de reprise qui fonctionne. La seule façon de savoir si votre plan est solide est de le tester. Cela signifie exécuter les étapes de reprise dans un environnement sûr, vérifier que les commandes produisent les résultats attendus et confirmer que l'équipe peut exécuter le plan sous pression.

Mais c'est un sujet pour une autre discussion. Pour l'instant, l'important est d'avoir le plan prêt avant d'appliquer le changement. Un bon plan de reprise ne garantit pas que tout se passera bien, mais il signifie que vous ne prendrez pas de décisions dans le noir quand quelque chose cassera.