Il peut expliquer comment préserver des preuves volatiles, isoler un appareil, révoquer des sessions actives, renouveler un secret compromis ou bloquer un indicateur. Un runbook utile indique à un opérateur autorisé ce qui est requis, quoi faire, comment vérifier le résultat et comment s'arrêter ou revenir en arrière si une action échoue.
Les runbooks peuvent servir des personnes, de l'automatisation ou les deux. Ils doivent préciser les entrées, les accès requis, les contrôles de sûreté, les étapes ordonnées, les sorties attendues, la journalisation et les conditions de retour arrière ou d'escalade. Comme les interfaces, les commandes, les dépendances et les privilèges changent, un runbook techniquement précis peut devenir dangereux plus vite qu'un document de politique de plus haut niveau.
Points clés
Conditions d'entréeDéfinir le déclencheur approuvé, les preuves requises, l'autorité de l'opérateur, les dépendances et les hypothèses avant le début de l'exécution.
Détail d'exécutionEmployer des étapes non ambiguës, des résultats attendus, des portes de décision et des vérifications de validation ; identifier les actions destructrices ou difficiles à inverser.
MaintenanceAttribuer une propriété, contrôler les versions, tester dans un environnement représentatif et revoir après tout changement de plateforme ou incident pertinent.
Limite importanteUn runbook ne peut remplacer sûrement le jugement lorsque les faits sont incertains. L'automatisation aveugle ou l'exécution littérale peut détruire des preuves, perturber des services critiques ou diffuser une réponse incorrecte à la vitesse des machines.