Un runbook décrit les actions à suivre lorsqu’un service ne répond plus ou que des données doivent être restaurées. Il réduit les hésitations pendant une panne, à condition de rester court, testé et lié à l’architecture réellement déployée.
Définir le périmètre
Commencez par le service concerné, ses utilisateurs et ses dépendances. Indiquez le domaine, l’environnement, le compte cloud et le niveau d’accès nécessaire. Un runbook qui mélange production, test et développement risque de lancer une action sur la mauvaise ressource.
Ajoutez un schéma simple des flux. Le lecteur doit voir la relation entre application, base de données, stockage, authentification et services externes. Notez les composants facultatifs qui peuvent être désactivés pour remettre le parcours principal en service.
Commencer par les contrôles sûrs
La première étape doit confirmer l’incident sans aggraver la situation. Vérifiez l’état du fournisseur, les métriques d’erreur, les derniers déploiements et les changements de configuration. Prenez une copie des journaux et des identifiants de version avant de modifier une ressource.
Utilisez des commandes en lecture seule autant que possible. Si une action modifie le trafic, redémarre un service ou restaure une sauvegarde, écrivez la condition qui l’autorise et la personne habilitée à la valider. Les commandes doivent préciser l’environnement et éviter les valeurs laissées par défaut.
Distinguer les scénarios
Une panne d’application ne se traite pas comme une perte de données. Pour une erreur apparue après un déploiement, examinez la version précédente et la procédure de retour. Pour une base indisponible, vérifiez le service géré, les connexions et les quotas. Pour une suppression de données, arrêtez les écritures concernées avant de choisir une restauration.
Prévoyez un chemin pour une dépendance externe indisponible. Une réponse dégradée, une file d’attente ou une désactivation temporaire peut préserver le reste du service. Documentez les effets visibles pour le support et le délai prévu avant nouvelle vérification.
Restaurer avec une sauvegarde vérifiée
Une sauvegarde présente dans une console ne prouve pas qu’elle peut être utilisée. Testez régulièrement une restauration dans un environnement isolé. Vérifiez les tables, les fichiers, les permissions et les connexions applicatives. Mesurez le temps d’accès à la sauvegarde et celui nécessaire pour reconstruire les ressources.
Le runbook doit préciser le point de restauration choisi, la perte de données attendue et la manière de traiter les écritures intervenues depuis ce point. Si plusieurs services partagent un identifiant ou un événement, recherchez les incohérences avant de rouvrir le trafic.
Organiser la communication
Indiquez la personne qui ouvre l’incident, celle qui prend les décisions techniques et celle qui informe les utilisateurs. Les rôles peuvent être tenus par une seule personne dans une petite équipe, mais la responsabilité doit rester explicite. Notez l’heure des changements et les vérifications terminées.
Le message interne doit contenir l’impact connu, l’action en cours et l’heure de la prochaine mise à jour. Évitez les estimations trop précises quand la cause n’est pas confirmée. Après le rétablissement, communiquez les contrôles effectués et les limitations qui restent.
Tester le runbook
Organisez une répétition sans supprimer de données de production. Suivez le document avec une personne qui ne l’a pas écrit et notez les termes ambigus, les accès manquants et les commandes impossibles à reproduire. Mesurez les étapes et comparez-les aux objectifs de reprise.
Mettez à jour le runbook après chaque changement d’architecture, de fournisseur ou de procédure de sauvegarde. Conservez une version dans un espace accessible pendant une panne, avec une copie de secours. Les secrets doivent rester dans le gestionnaire prévu, et le runbook doit référencer leur emplacement sans les recopier.
Le guide de test de restauration des sauvegardes complète ce travail. Sky Vaults peut aussi vous aider à structurer une exploitation cloud au Maroc.
Sources : AWS Well-Architected, reliability pillar, Google Cloud, disaster recovery planning.