Un runbook de production utilisable par une petite équipe

Un runbook aide à passer d’un symptôme précis à une décision sûre.

Deux tours de serveurs reliées par un chemin interrompu et une voie de reprise continue.

Un runbook aide à passer d’un symptôme précis à une décision sûre. Ce n’est pas une liste de toutes les commandes disponibles. Écrivez pour une personne disposant des compétences attendues mais potentiellement fatiguée ou peu familière du composant.

Commencer par le signal et l’impact

Nommez l’alerte, le parcours touché et les conditions d’application. Liez le tableau de bord et expliquez ce qui distingue cette cause des symptômes voisins. Ajoutez propriétaire, date de revue et escalade. Le document doit rester accessible lorsque l’application principale est indisponible.

Décrire prérequis et arrêts

Précisez droits, sélection de l’environnement et approbations nécessaires aux actions conséquentes. Indiquez quand des données inexpliquées, une sauvegarde absente ou un résultat contradictoire imposent l’escalade. N’inscrivez pas de secrets. Chaque étape doit expliquer son but, le résultat attendu et la prochaine branche, y compris ses effets sur le travail en cours.

Inclure validation et entretien

Pour redémarrage, rejeu ou bascule, expliquez duplication possible et retour arrière. Vérifiez le parcours client et le travail en attente, puis consignez actions et suites. Faites essayer la procédure par une autre personne dans un environnement sûr. Mettez-la à jour après changements et incidents pertinents ; un guide court testé est plus fiable qu’un long document abandonné.

Un exemple à vérifier

Pour une file qui grossit, distinguez absence de workers, dépendance lente et tâche isolée qui échoue en boucle. Un redémarrage générique peut masquer la cause ou produire davantage de répétitions. Indiquez l’observation qui confirme chaque branche et l’action bornée suivante. L’exercice est réussi lorsqu’une autre personne choisit le bon chemin et vérifie ensuite la file ainsi que le résultat métier. Toute sortie incomprise devient une amélioration documentaire.

Questions fréquentes

Faut-il inclure des commandes ?

Oui si elles sont revues et accompagnées de prérequis, périmètre et résultats attendus.

Quelle longueur viser ?

Celle du chemin de décision nécessaire, sans détails sans rapport.

Qui doit tester la procédure ?

Une personne autre que l’auteur avec les droits et compétences attendus.

Que faire si la réalité diffère ?

S’arrêter à la limite prévue, préserver les preuves et escalader.

Quand mettre à jour ?

Après changements, exercices ou incidents modifiant les hypothèses.

Transformons votre besoin en périmètre réalisable

Partagez le parcours utilisateur, les intégrations et les contraintes de lancement. Nous pouvons préparer une estimation avec hypothèses et exclusions.

Découvrir le périmètre de prestation →