Runbooks¶

Écrire des runbooks clairs et actionables pour les équipes d'astreinte, même dans les moments de stress.

Qu'est-ce qu'un runbook¶

Un runbook est un document opérationnel qui guide une personne — pas necessairement experte — à travers une action spécifique sur un système. Il ne s'agit pas d'expliquer le fonctionnement interne du système, mais de répondre à la question : "que faire dans cette situation précisé ?".

Un bon runbook est :

• Actionable : chaque étape se traduit en une action concrète
• Lineaire : l'ordre des étapes est important et respecte
• Autonomisant : lisible sans expertise préalable du système concerne
• Teste : valide par quelqu'un qui ne connait pas le système

Structure d'un runbook¶

graph TD
    A["Declencheur / Alerte"] --> B["Contexte et diagnostic"]
    B --> C["Actions correctives"]
    C --> D["Verification du retour a la normale"]
    D --> E["Escalade si non resolu"]

Chaque runbook doit contenir ces sections :

Exemple : Disk full sur serveur de logs¶

Déclencheur : Alerte disk_usage > 90% sur /var/log du serveur logs-prod-01

Diagnostic

Vérifier l'espace disque disponible et identifier les fichiers ou répertoires qui consomment le plus d'espace.

Actions

1. Se connecter au serveur via le bastion (voir runbook accès SSH)
2. Identifier les partitions concernees avec la commande de vérification d'espace disque
3. Lister les 10 fichiers les plus volumineux dans /var/log
4. Vérifier si les logs de rotation sont actifs : rechercher la configuration logrotate dans /etc/logrotate.d/
5. Si des logs de plus de 30 jours sont presents, les archiver manuellement vers le stockage froid (voir procédure archivage)
6. Si des logs actifs sont anormalement volumineux, identifier l'application source et ouvrir un ticket
7. Forcer une rotation manuelle via logrotate en mode force
8. Vérifier que l'espace est revenu sous 80%

Vérification

Confirmer que le seuil d'alerte n'est plus actif. L'alerte doit se clore automatiquement sous 5 minutes.

Escalade

Si l'espace ne revient pas sous contrôle après les actions ci-dessus, ou si la partition est pleine a 100%, escalader immédiatement à l'équipe L2 (voir contacts d'astreinte).

Niveaux de détail : L1 vs L2¶

Les runbooks ne sont pas tous écrits pour le même public. Un runbook L1 guide un opérateur en première ligne ; un runbook L2 s'adresse a un expert qui intervient sur des cas complexes.

Runbooks d'astreinte¶

Les runbooks utilisés en astreinte ont des contraintes spécifiques que ceux utilisés en journée n'ont pas :

• Contexte minimal : la personne vient d'être reveille, n'a pas le contexte frais
• Stress élevé : un service est dégradé ou indisponible, la pression est forte
• Temps limite : les SLA courent, chaque minute compte
• Environnement dégradé : VPN depuis chez soi, laptop personnel, connexion instable

Pour les runbooks d'astreinte, appliquer ces règles supplémentaires :

• Commencer par un résumé de 3 lignes (quoi, impact, action principale)
• Mettre les numéros de contact en tete du document
• Éviter les étapes conditionnelles complexes — si nécessaire, créer deux runbooks distincts
• Inclure les commandes exactes avec les valeurs types attendues en retour
• Specifier clairement le moment où escalader sans honte

Outils et formats¶