Un bon runbook fait la différence entre une astreinte fluide et un désastre à 3 h du matin. Avec Trupeer, vous pouvez gagner des heures sur la rédaction de runbooks IT en commençant par un modèle de runbook gratuit, en le personnalisant avec vos directives de marque, puis en transformant de longs runbooks en vidéos de démonstration que les ingénieurs d’astreinte peuvent parcourir en quelques secondes.

Qu’est-ce qu’un modèle de runbook gratuit ?

Un modèle de runbook gratuit est une structure réutilisable pour la séquence d’étapes qui permet d’accomplir une tâche opérationnelle donnée : un déploiement, un basculement, une migration, une reprise, une fenêtre de maintenance planifiée.

Le mot runbook mérite d’être pris au pied de la lettre. C’est un document qui se « exécute », pas qu’on lit. Il est ouvert à l’écran pendant que le travail se fait, il est suivi dans l’ordre, et sa valeur réside entièrement dans ce qu’il permet pendant l’exécution plutôt que dans ce qu’il dit une fois classé.

Ce fait, à lui seul, distingue un bon runbook d’un bon document de procédure, et c’est ce que la plupart des modèles ratent. Ils produisent une description bien organisée de ce qu’il faut faire, ce qui est nécessaire et correspond à environ la moitié de ce qu’un runbook doit contenir.

L’autre moitié, c’est qu’un runbook est une forme. Il se remplit au fur et à mesure de son exécution, car le registre de ce qui s’est réellement passé fait toute la différence entre une opération qu’une personne peut reprendre à mi-parcours et une opération qui doit être redémarrée ou devinée.

La mise en forme suit cette logique. Un fichier Excel de modèle de runbook gratuit convient au tableau d’étapes avec ses colonnes « résultat » et « horodatage », et c’est ce que la plupart des équipes finissent par utiliser. Une version Word de modèle de runbook gratuit convient aux runbooks avec beaucoup de contexte et de prose autour des étapes, et un fichier Microsoft Word de modèle de runbook gratuit est la même chose sous son nom plus long. Un modèle de runbook gratuit au format PDF est un enregistrement archivé d’un run terminé plutôt qu’un document de travail.

Runbook de déploiement ou runbook d’incident ?

Deux documents portent le même nom et sont utilisés de façons opposées : choisissez donc celui que vous rédigez.

Un modèle de runbook de déploiement couvre le travail planifié. Une release, une migration, un cutover, une fenêtre de maintenance planifiée. Il s’exécute de l’étape un jusqu’à la fin, dans l’ordre, à un moment connu de tous, généralement par plus d’une personne et souvent pendant un changement d’équipe. Le défi de conception, c’est la séquence, l’état et la passation.

Un runbook d’incident ou d’astreinte couvre le travail non planifié. Quelque chose ne va pas et quelqu’un diagnostique. Il est saisi à un moment imprévisible, par la personne disponible, sous pression, et il n’est pas lu dans l’ordre. Le défi de conception, c’est de trouver rapidement la section pertinente, ce qui le rapproche davantage d’un document de recherche que d’un script.

La plupart des modèles publiés mélangent les deux et ne servent bien ni l’un ni l’autre. Un runbook de diagnostic forcé dans une séquence numérotée ne peut pas être saisi au milieu, et un runbook de déploiement organisé comme une liste de symptômes perd l’ordre qui le rend sûr.

Cette page traite principalement du premier cas. Un travail planifié, exécuté dans l’ordre, où les échecs coûteux concernent l’état et la passation plutôt que le diagnostic.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Templates

Accédez à la section Templates depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Edit pour commencer à modifier le modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Après avoir effectué toutes les modifications nécessaires, cliquez sur Save pour enregistrer le modèle mis à jour comme le vôtre.

Étape 6 : Prévisualiser et affiner le modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez la prévisualisation.

À partir de l’écran de prévisualisation, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.

Avec un modèle de runbook, vous pouvez :

• Gagner des heures sur la rédaction : évitez la page blanche grâce à une structure conçue pour les procédures ops.

• Réduire le MTTR : des runbooks clairs aident les ingénieurs d’astreinte à résoudre les incidents plus rapidement.

• Rester conforme à votre marque : appliquez votre logo, vos polices et vos couleurs à l’aide du brand kit de Trupeer.

• Former de nouveaux ingénieurs : associez les runbooks à des vidéos de démonstration pour intégrer plus vite les équipes ops.

• Standardiser entre les équipes : utilisez le même format de runbook pour chaque type d’incident.

• Atteindre des équipes internationales : traduisez vos runbooks en 65+ langues en un clic.

Rédiger le runbook pour une passation à mi-parcours

Voici la contrainte de conception à prendre comme point de départ. À un moment donné pendant l’exécution, la personne qui exécute le runbook ne sera plus celle qui l’a commencé.

Un changement de poste se termine. Quelqu’un est appelé ailleurs. Une fenêtre d’exécution dure plus longtemps que prévu. Pour toute opération qui dure plus de quelques heures, c’est normal plutôt qu’exceptionnel, et c’est précisément le moment où les runbooks échouent de façon coûteuse.

La question à laquelle il faut répondre est très précise. Une deuxième personne peut-elle reprendre à l’étape trente-sept, sans briefing verbal, et continuer en toute sécurité ?

Répondre « oui » exige quatre éléments que la plupart des modèles n’ont pas.

Un résultat réel enregistré à chaque étape, pas seulement un résultat attendu. Un coche signifie que quelqu’un a cliqué quelque chose. Cela n’indique pas à la personne suivante ce qui s’est réellement passé.

Un horodatage pour chaque étape, car depuis combien de temps une étape a été exécutée est souvent le fait le plus diagnostique disponible.

Un marquage explicite des étapes qu’il est sûr de rejouer. La première question de toute personne qui prend le relais est de savoir si l’étape précédente s’est réellement terminée. Si l’étape peut être répétée sans risque, alors cette question cesse d’être importante, ce qui vaut bien plus que le coût d’enregistrer l’information.

Un point de non-retour clairement indiqué. À partir duquel le rollback n’est plus disponible. Une personne qui arrive en cours d’exécution doit savoir de quel côté de cette ligne elle se trouve avant de toucher à quoi que ce soit.

Ajoutez ces quatre éléments et la passation verbale ne sera plus le mécanisme. Le document devient la passation, c’est la seule version qui survit quand quelqu’un est fatigué, pressé ou indisponible.

Ce qu’un modèle de runbook doit contenir

Neuf composants. Les quatre du milieu sont ceux qui distinguent un runbook d’une procédure.

Le dernier mérite une attention particulière. Des étapes de vérification écrites comme « confirmer que le site est en ligne » passent quand le site est en ligne et cassé, ce qui correspond à l’échec décrit ci-dessous.

Modèle de runbook gratuit : la structure à copier

Rempli avec un exemple réel plutôt que des placeholders. Il s’agit d’un extrait d’une migration d’un système de gestion des commandes.

Copiez à partir d’ici.

En-tête et fenêtre. Nom du run, date, fenêtre planifiée, date limite d’abandon, et version de ce runbook.

Migration de la gestion des commandes. Samedi 14 juin. Fenêtre 06:00 à 20:00. Date limite d’abandon 16:00, après laquelle nous revenons en arrière quel que soit l’avancement. Runbook v9.

Rôles pour ce run. Avec des numéros dans le document.

Exécution : K Ferreira 06:00 à 14:00, puis D Attwood 14:00 à 20:00. Point de non-retour approuvé par : Head of Engineering, 07700 900xxx. Escalade : responsable de l’astreinte, 07700 900xxx. Contact métier pour la décision go : Trading Director.

Préconditions. Toutes confirmées avant l’étape un.

Sauvegarde complète de la base de données effectuée et restauration testée sur l’instance de secours. Gel du code en vigueur depuis jeudi. Les deux exécutants ont aujourd’hui un accès à la production vérifié, pas supposé. Rollback répété sur staging le 7 juin.

Ligne d’état. Mise à jour au fur et à mesure, conservée en haut.

Actuellement à l’étape 37. Exécution depuis 13:48. Exécutant : K Ferreira. Point de non-retour pas encore dépassé.

Tableau d’étapes.

Rollback. Disponible jusqu’à et y compris l’étape 37. Restauration à partir de la sauvegarde avant le run, redirection DNS, redémarrage des workers d’alimentation. Répété sur staging le 7 juin par D Attwood.

Section de passation. À remplir avant que quiconque ne parte.

Terminé jusqu’à l’étape 35. L’étape 34 a échoué silencieusement lors de la première tentative avec une incohérence de nombre et a été rejouée avec succès ; les nombres correspondent désormais à 84,120. Surveiller à nouveau le nombre d’index après l’étape 36, car il a déjà échoué une fois. Rien en cours. Point de non-retour non dépassé, rollback encore disponible.

Vérification. Suffisamment précise pour échouer.

Le site se charge. Le nombre de produits sur les pages de catégories additionne 84,120. Dix commandes d’exemple passées de bout en bout. Historique des commandes visible pour cinq comptes connus. Le rapport de rapprochement des paiements est exécuté et correspond.

Copiez à partir d’ici.

Exemple de runbook : soixante et une étapes et une passation de dix minutes

Tamworth Retail Group, un e-commerçant, a migré son système de gestion des commandes pendant une fenêtre planifiée de quatorze heures, un samedi.

Le runbook comptait soixante et une étapes. Il avait été relu, répété sur staging, et c’était un document réellement soigneux. Son tableau d’étapes comportait trois colonnes : numéro d’étape, action, et case à cocher.

Le premier ingénieur a exécuté les étapes une à trente-sept, a fait une passation verbale en environ dix minutes lors du changement d’équipe, puis est rentré chez lui après une longue journée.

L’étape trente-quatre consistait à réindexer le catalogue produit, une tâche qui prenait environ quarante minutes. Il l’avait lancée, n’avait vu aucune erreur, et l’avait cochée. En réalité, elle a échoué à environ quatre-vingts pour cent et n’a rien signalé.

Le deuxième ingénieur est arrivé avec une liste de soixante et une étapes, avec des coches sur les trente-sept premières. Il n’y avait aucune trace de ce que chaque étape avait produit, aucun horodatage, et aucune indication des étapes qu’il était sûr de répéter. Tout ce qui se trouvait avant l’étape trente-huit était, du point de vue du document, simplement terminé.

Elle a continué. Le catalogue était partiellement indexé, ce qui signifiait qu’environ douze pour cent des produits étaient invisibles sur le site lorsqu’il a rouvert.

Le test de fumée à la fin a confirmé que le site se chargeait. Il ne comparait pas le nombre de produits au nombre du catalogue, donc il a validé.

Personne n’a remarqué le problème avant le lundi matin, trente et une heures plus tard, pendant le week-end de trading le plus chargé du trimestre. Les commandes perdues estimées par rapport au même week-end de l’année précédente s’élevaient à environ deux cent quarante mille livres sterling.

Ils ne pouvaient pas revenir en arrière. Le point de non-retour avait été dépassé à l’étape quarante et un, et même si tout le monde impliqué le savait en principe, cela avait été consigné dans un paragraphe à la page un plutôt que dans l’étape où cela s’est produit.

La réécriture n’a pas ajouté d’étapes. Elle a ajouté des colonnes. Résultat réel, horodatage, et marquage « sûr à rejouer » pour chaque étape. Une ligne d’état en haut. Le point de non-retour est passé de l’introduction à l’étape elle-même, en gras. Et une section de passation à compléter avant que quiconque ne parte, ce qui a transformé une conversation de dix minutes en quatre lignes écrites.

Lors de la migration suivante, le changement d’équipe a eu lieu à la neuvième heure. La passation a pris quatre minutes. L’ingénieur qui a pris le relais a rejoué trois étapes dont elle n’était pas sûre, précisément parce qu’elles étaient marquées « sûres à rejouer », et le run s’est terminé dans la fenêtre.

Rejouer trois étapes par prudence coûte quelques minutes. Ne pas pouvoir le faire, c’est ce qui coûte un week-end.

Comment rédiger un runbook en six étapes

1. Rédigez les étapes en exécutant la tâche, pas en vous fiant à la mémoire. Un runbook rédigé sur un bureau contient les étapes dont l’auteur se souvient et omet celles que ses mains font automatiquement.

2. Donnez à chaque étape un résultat attendu. Ce que vous verrez et qui prouve que cela a fonctionné. Une étape sans résultat attendu ne peut être vérifiée que par son auteur.

3. Marquez chaque étape comme sûre à rejouer ou non. Voir ci-dessous. C’est la colonne la moins chère à ajouter et la plus précieuse pendant une passation.

4. Placez le point de non-retour à l’étape, en gras. Pas dans l’introduction, où il sera lu une seule fois par quelqu’un qui n’est pas la personne qui en a besoin.

5. Ajoutez les colonnes que vous remplirez pendant le run. Résultat réel et horodatage. S’ils ne figurent pas dans le document, ils ne seront enregistrés nulle part.

6. Répétez l’ensemble, y compris le rollback. Un rollback qui n’a été que rédigé est une hypothèse. Répétez sur staging avec la personne qui l’exécutera, pas avec celle qui l’a rédigé.

L’étape une est celle qui sépare les runbooks utiles des runbooks plausibles. Rédiger pendant qu’on fait permet de capturer le clic non documenté, les identifiants déjà dans le presse-papiers, et l’onglet qui devait être ouvert.

Marquer les étapes comme sûres à rejouer, et le point de non-retour

Ces deux marquages font l’essentiel du travail pendant une passation, et aucun des deux n’apparaît dans un modèle typique.

Sûr à rejouer. Pour chaque étape, peut-elle être exécutée deux fois sans causer de dommage ? Redémarrer un service arrêté, rejouer un index, réappliquer une configuration déjà appliquée : généralement oui. Envoyer un e-mail client, incrémenter un compteur, migrer des lignes dans une table qui ne déduplique pas : généralement non.

La valeur, c’est que cela supprime la question à laquelle la personne qui prend le relais ne peut pas répondre. L’étape précédente s’est-elle terminée ? Si la réponse n’a pas d’importance, parce que la répéter ne cause aucun dommage, alors personne n’a besoin de l’établir sous pression avec des informations incomplètes.

Quand une étape n’est pas sûre à rejouer, indiquez ce qu’il faut vérifier en premier. « Non, vérifiez le nombre de lignes avant de répéter » est bien plus utile que « Non », car la personne qui lit le document a déjà décidé qu’elle devait faire quelque chose.

Le point de non-retour. Chaque run qui modifie l’état en a un. C’est l’étape après laquelle le rollback n’est plus disponible, ou n’est plus moins coûteux que de continuer.

Marquez-le à l’étape, de façon visuelle, pour que quelqu’un qui fait défiler puisse voir de quel côté il se trouve. Indiquez qui autorise le fait de le franchir, et enregistrez l’heure de franchissement dans la colonne « résultat réel ». De nombreux runs en ont plus d’un : dans ce cas, marquez chacun et précisez ce que chacun clôt.

La raison d’enregistrer le franchissement plutôt que de ne marquer que l’étape, c’est qu’après un incident, on se demande à quel moment la décision est devenue irréversible, et personne ne s’en souvient.

Variantes de modèles de runbook

La structure reste la même et l’accent se déplace.

Modèle de runbook de déploiement. L’exemple ci-dessus. Séquentiel, planifié, souvent sur un changement d’équipe, et la variante pour laquelle la conception de la passation compte le plus.

Runbook de reprise après sinistre (disaster recovery). Exécuté rarement et dans les pires conditions, il se dégrade de façon invisible entre les utilisations. L’exigence distinctive, c’est la répétition planifiée : un runbook DR qui n’a pas été exécuté depuis un an doit être considéré comme incorrect.

Runbook d’astreinte et d’incident. Saisi à un moment imprévisible plutôt que exécuté dans l’ordre. Organisez par symptômes plutôt que par séquence, gardez chaque entrée courte, et renvoyez vers le contenu plus approfondi plutôt que de le contenir.

Runbook de maintenance planifiée. Répété régulièrement, ce qui en fait la seule variante qui s’améliore réellement avec l’usage, à condition que quelqu’un le mette à jour pendant le run plutôt que de prévoir de le faire après.

Runbook d’onboarding et d’offboarding. Souvent le premier runbook qu’une équipe rédige, car la séquence est stable et le coût d’oublier une étape, en particulier lors de l’offboarding, est un problème de sécurité plutôt qu’une simple gêne.

Pour tout ce qui couvre des systèmes réglementés, le traitement financier ou des contrôles liés à la sécurité, un runbook se trouve généralement dans un processus de gestion du changement avec ses propres exigences d’approbation et de conservation des enregistrements, et ce sont ces exigences qui priment sur tout ce qui figure sur cette page.

Runbook, instruction de travail ou SOP ?

Trois documents qui se recoupent et qu’il vaut mieux distinguer, car choisir le mauvais produit le bon contenu sous une forme inutilisable.

Une procédure opératoire standard (standard operating procedure) couvre un processus au niveau de qui fait quoi et dans quel ordre, généralement en couvrant des rôles et souvent en couvrant des jours. Elle se lit pour comprendre.

Une instruction de travail couvre une tâche en détail pour la personne qui l’exécute, et elle est rédigée pour être suivie par quelqu’un qui pourrait ne pas la connaître. Le modèle d’instructions de travail couvre ce document.

Un runbook est une instruction de travail qui est aussi un enregistrement d’exécution. Il est suivi et rempli simultanément ; il couvre généralement plusieurs tâches dans un ordre défini, et ses colonnes existent pour laisser une trace.

Si votre document est lu avant le travail et classé après, c’est une procédure. S’il est ouvert pendant le travail et différent à la fin qu’au début, c’est un runbook.

Garder les runbooks à jour

Les runbooks se dégradent plus vite que la plupart des documentations, car ils décrivent des systèmes qui changent, et cette dégradation est invisible jusqu’au run qui échoue.

Le mécanisme qui fonctionne réellement, c’est la mise à jour pendant l’exécution plutôt qu’après. La personne qui exécute le runbook a le document ouvert, vient de découvrir que l’étape douze nécessite désormais une confirmation supplémentaire, et c’est la seule personne qui le saura à moindre coût. Dix secondes plus tard, ou une heure de confusion lors du prochain run.

Rendez cela légitime en le disant explicitement en haut du document, et en considérant qu’un runbook inchangé après une exécution réelle est légèrement suspect plutôt que comme un signe de qualité.

L’automatisation est l’autre voie, et il vaut mieux en avoir une vision claire. Automatiser une étape de runbook supprime à la fois l’erreur humaine et le problème de documentation, ce qui est réellement mieux là où cela s’applique. Ce que cela ne supprime pas, c’est la nécessité du document environnant : quelqu’un doit toujours savoir quoi faire quand l’automatisation échoue, et cette personne est désormais moins entraînée qu’avant. Automatisez les étapes, conservez le runbook, et assurez-vous que le runbook couvre la partie automatisée qui échoue.

Ce qu’un modèle de runbook gratuit ne peut pas corriger

Un runbook rédigé de mémoire. Aucun modèle ne fait apparaître les étapes que l’auteur fait sans y penser. Seule la rédaction pendant l’exécution le permet.

Un rollback non répété. Un plan de rollback qui n’a jamais été exécuté est une hypothèse, et le milieu d’une migration échouée est un mauvais endroit pour le tester.

Une checklist qui porte le nom. La plupart de ce qui circule comme un modèle de runbook gratuit en téléchargement gratuit est une procédure numérotée avec des cases à cocher, ce qui est un document différent et plus faible.

Une vérification qui ne peut pas échouer. « Confirmer que le site est en ligne » passe quand le site est en ligne et faux. Chaque étape de vérification doit être suffisamment précise pour que vous puissiez imaginer qu’elle échoue.

Une fenêtre sans date limite d’abandon. Sans elle, un run qui se passe mal continue, car s’arrêter semble toujours plus coûteux que l’étape suivante. Fixez la date limite avant de commencer, quand personne n’est encore investi.

Montrer le run plutôt que le décrire

Les runbooks sont exécutés par des personnes qui les exécutent rarement. Une migration a lieu deux fois par an. Un test DR a lieu une fois par an. La personne qui l’exécute l’a déjà fait une fois auparavant, parfois jamais.

C’est exactement le cas où une procédure écrite sert le pire, car le lecteur doit reconstituer une séquence d’écrans et d’états de console à partir d’un texte, et l’écart entre ce que l’auteur voulait dire et ce que le lecteur imagine, c’est là que l’étape non documentée se cache.

Trupeer AI le résout. Quelqu’un exécute le run une fois, sur staging, tout en enregistrant, et la sortie devient une démonstration écrite étape par étape avec des captures d’écran déjà capturées et placées, avec une vidéo, dans votre propre branding. La version écrite devient le runbook. La vidéo, c’est ce que la personne qui exécute regarde la veille, c’est la préparation que personne n’a actuellement le temps de produire.

Enregistrez-le. Marquez-le. Traduisez-le. Trupeerisez-le.

Deux choses suivent et comptent spécifiquement pour les runbooks. La répétition produit la documentation comme un sous-produit plutôt que comme une tâche supplémentaire, ce qui est la seule version de documentation qui se produit de manière fiable. Et lorsque l’infrastructure change, réenregistrer la répétition est plus rapide que modifier des captures d’écran : le runbook a donc plus de chances d’être à jour au moment où cela compte.

Le contenu se trouve dans votre base de connaissances et sert aussi de formation pour la personne qui sera de garde ensuite. Les preuves de vérification et les contrôles de qualité autour du run doivent figurer dans le plan QA. La cohérence avec vos autres documents se fait en définissant une fois le brand kit, et la configuration est couverte dans le guide de configuration du modèle de document.

Questions fréquentes

Existe-t-il une version Excel gratuite du modèle de runbook ?

Excel est ce que la plupart des équipes finissent par utiliser et cela convient bien au document, car le cœur d’un runbook est un tableau que vous remplissez pendant que vous travaillez. Un fichier Excel de modèle de runbook gratuit gère naturellement les colonnes « étape », « résultat attendu », « résultat réel », « horodatage » et « sûr à rejouer », et permet à plusieurs personnes de voir la même feuille pendant un run.

Deux réglages pratiques. Verrouillez la ligne d’en-tête et placez la ligne d’état dans les deux premières lignes au-dessus, afin qu’elle reste visible pendant le défilement. Un fichier Excel de modèle de runbook gratuit où l’étape en cours sort de l’écran perd la majeure partie de sa valeur pour la passation.

Existe-t-il une version Word gratuite du modèle de runbook ?

Word convient aux runbooks avec un contexte substantiel autour des étapes : notes d’architecture, historique des décisions, détails d’escalade. Construisez le fichier Word du modèle de runbook gratuit d’abord avec les sections narratives, puis avec le tableau d’étapes.

La limite, c’est le remplissage pendant un run. Un tableau Word se met à jour plus lentement qu’une cellule de feuille de calcul, et pendant une migration en direct, cette friction suffit à empêcher les gens d’enregistrer les résultats réels. De nombreuses équipes conservent le contexte dans un document Word de modèle de runbook et le tableau d’étapes dans une feuille de calcul liée à partir de celui-ci.

Existe-t-il une version Microsoft Word gratuite du modèle de runbook ?

Oui, et le même compromis s’applique. Un fichier Microsoft Word de modèle de runbook gratuit est le bon choix lorsque le runbook est relu et approuvé dans le cadre d’un processus de changement, car les documents s’intègrent mieux aux workflows d’approbation que les feuilles de calcul.

Si vous suivez cette voie, ajoutez quand même les colonnes « résultat réel » et « horodatage ». Un runbook approuvé sans elles sera exécuté sans elles, et l’enregistrement dont vous aviez besoin n’existera pas.

Existe-t-il un modèle de runbook de déploiement ?

Un modèle de runbook de déploiement est la variante séquentielle couverte tout au long de cette page : travail planifié, exécuté dans l’ordre, généralement sur un changement d’équipe.

Quatre éléments distinguent un bon modèle d’un modèle générique. Un point de non-retour marqué à l’étape plutôt que dans l’introduction. Un marquage « sûr à rejouer » pour chaque étape. Des colonnes « résultat réel » et « horodatage ». Et une section de passation complétée avant que quiconque ne parte. Presque aucun modèle publié ne contient les quatre.

Existe-t-il un modèle de runbook gratuit au format PDF ?

Le PDF est l’archive plutôt que le document de travail. Une fois un run terminé, exportez le runbook rempli en tant que modèle de runbook gratuit au format PDF et joignez-le à l’enregistrement du changement, car un runbook terminé avec des horodatages et des résultats réels est la meilleure preuve de ce qui s’est passé.

N’exécutez pas à partir d’un PDF. Le document doit être rédigé pendant le run, et tout ce que vous ne pouvez pas saisir ne sera pas enregistré.

Existe-t-il un téléchargement gratuit de modèle de runbook qui vaut le coup d’être utilisé ?

Le tableau lui-même prend dix minutes à construire, donc un téléchargement gratuit de modèle de runbook vous fait gagner peu, et la plupart des modèles publiés sont des documents de procédure avec une étiquette « runbook ».

Vérifiez une chose avant d’adopter l’un d’entre eux. Voyez si le tableau d’étapes comporte une colonne pour ce qui s’est réellement passé. S’il n’a qu’une case à cocher, vous avez une checklist, et l’argument complet de cette page est que la différence entre les deux dépend de la passation.

Quelle doit être la longueur d’un runbook ?

Aussi longue que le run, ce qui pour une migration substantielle correspond réellement à des dizaines d’étapes. La longueur n’est pas le problème avec les runbooks.

Ce qu’il faut contrôler, c’est la taille des étapes. Une étape doit correspondre à une action avec un résultat observable. Les étapes qui regroupent plusieurs actions ne peuvent pas être passées à mi-parcours, car la personne suivante ne peut pas dire quelle partie du lot s’est produite, et c’est exactement la situation que le document existe pour éviter.

Qui doit rédiger le runbook ?

La personne qui va l’exécuter, en rédigeant pendant qu’elle l’exécute sur un environnement non de production. Un runbook rédigé par un architecte et exécuté par un ingénieur manquera précisément les étapes que l’architecte ne réalise pas personnellement.

Ensuite, faites exécuter le brouillon par une deuxième personne sur staging, sans aide de l’auteur. Chaque question qu’elle doit poser est un défaut, et la correction consiste à l’écrire plutôt qu’à y répondre.