Runbook de bascule et de retour arrière
Rédiger un runbook de bascule exécutable, avec critères de déclenchement, séquence d'actions et retour arrière sûr.
À retenir
- Un runbook exécutable contient des critères de déclenchement chiffrés, pas des appréciations qualitatives.
- Toujours vérifier l'état de synchronisation des données avant de basculer.
- Le retour arrière doit être documenté au même niveau de détail que la bascule.
- Tester le runbook à la lettre révèle les étapes obsolètes qu'une relecture ne détecte pas.
Un runbook, pas une note d'intention
Un runbook de bascule doit pouvoir être exécuté par un opérateur d'astreinte à 3h du matin, sous pression, sans interprétation. Chaque étape est une action vérifiable, avec un résultat attendu explicite et un point de décision go/no-go.
Structure type d'un runbook de bascule
| Section | Contenu |
|---|---|
| Critères de déclenchement | Seuils mesurables (indisponibilité > X min, alerte de supervision, décision de la cellule de crise) |
| Prérequis | Vérifications avant bascule (état de la réplication, dernière sauvegarde valide) |
| Séquence d'actions | Étapes numérotées, commandes exactes, responsable de chaque étape |
| Points de contrôle | Tests de validation après chaque étape critique |
| Communication | Qui prévenir, à quel moment, avec quel modèle de message |
| Retour arrière | Conditions et procédure de rollback si la bascule échoue |
Point clé
un runbook sans critère de déclenchement chiffré devient un document d'opinion — chacun l'interprète différemment sous stress, ce qui retarde la décision de bascule.
Critères de bascule concrets
- Indisponibilité confirmée par au moins deux sources de supervision indépendantes.
- Durée d'indisponibilité dépassant un seuil défini (ex. 10 minutes pour un service critique).
- Validation par un décideur nommé (astreinte N2, responsable exploitation) ou automatique si le seuil est atteint sans réponse humaine sous 5 minutes.
- Réplication des données confirmée à jour (écart RPO mesuré < seuil contractuel).
Attention
basculer sur un site secondaire dont la réplication est en retard peut transformer un incident de disponibilité en incident de perte de données irréversible — toujours vérifier l'état de synchronisation avant de déclencher.
Le retour arrière, souvent oublié
Le retour arrière (rollback ou "fail-back") est aussi risqué que la bascule initiale, car il faut réconcilier les données produites sur le site secondaire pendant l'incident. Un runbook complet documente la stratégie de réconciliation (réplication inverse, fenêtre de gel des écritures, vérification d'intégrité) avant tout retour à la normale.
Sur le terrain
lors d'un exercice réel chez un opérateur télécom, le retour arrière après bascule avait été omis du runbook ; l'équipe a improvisé une réconciliation manuelle de 6 heures faute de procédure écrite — un délai supérieur à l'incident initial.
Exercice tabletop : bascule à blanc
Scénario : le site primaire de facturation devient inaccessible. Chronologie imposée : détection T0, alerte cellule T+5, décision de bascule T+15, bascule effective T+30, validation fonctionnelle T+45, communication client T+50. Chaque participant joue son rôle réel et documente les écarts entre le runbook et l'exécution.
Astuce
testez le runbook littéralement, en suivant chaque commande écrite sans improviser — c'est le seul moyen de détecter les étapes obsolètes ou les accès expirés avant l'incident réel.