Runbook Linux PME : le modèle qui évite les incidents récurrents

Bot Linux man

Pourquoi les mêmes incidents reviennent encore et encore

Chaque admin sys a vécu ça : le disque /var plein un vendredi soir, un service qui ne redémarre pas après un reboot, un backup silencieusement en échec depuis trois semaines. Le pire, ce n’est pas l’incident — c’est de réaliser qu’on l’a déjà résolu il y a six mois, mais que la procédure est restée dans la tête de celui qui était d’astreinte ce jour-là.

Runbook Linux PME pour standardiser la réponse aux incidents sur serveurs Linux
Documenter les bonnes procédures évite de résoudre deux fois le même incident.

En PME, on n’a pas une équipe NOC de 15 personnes avec un wiki de 800 pages. On est souvent deux ou trois à gérer l’infra, et la transmission du savoir passe par Slack, par des post-its mentaux, ou par « demande à Marc, c’est lui qui avait fixé ça ». Résultat : chaque incident récurrent coûte du temps, du stress, et parfois des clients.

C’est exactement pour ça que j’utilise des runbooks Linux depuis des années. Pas des documents théoriques qu’on écrit une fois et qu’on oublie — des fiches opérationnelles, testées, qu’on déroule quand un incident se présente. Dans cet article, je partage le modèle que j’utilise en production avec mes clients PME et SaaS, et qui a divisé par trois le temps moyen de résolution des incidents récurrents.

Ce qu’est un runbook Linux (et ce que ce n’est pas)

Un runbook Linux, c’est un document opérationnel qui décrit exactement quoi faire quand un incident précis se produit. Pas une documentation d’architecture, pas un README de projet, pas un tutoriel — un runbook est une procédure de réponse à incident, étape par étape, avec les commandes à exécuter, les vérifications à faire, et les escalades à déclencher si ça ne suffit pas.

Voici ce qui distingue un runbook d’autres types de documentation :

Un bon runbook a une qualité fondamentale : n’importe qui dans l’équipe peut le dérouler, même à 3h du matin, même sans connaître l’historique du serveur. C’est ça qui change la donne en PME.

Structure d’un runbook Linux efficace

Après avoir créé et maintenu des dizaines de runbooks pour différentes infrastructures, j’ai convergé vers une structure en 7 sections qui fonctionne systématiquement. Voici le squelette que j’utilise :

1. Métadonnées

Chaque runbook commence par un en-tête qui permet de le retrouver et de savoir s’il est encore à jour :

---
title: "Disque /var plein - Serveur production"
severity: P2
last_tested: 2025-01-15
owner: ops
services_impacted:
  - nginx
  - postgresql
  - docker
alert_trigger: "disk_usage_var > 90%"
---

Le champ last_tested est crucial : un runbook non testé depuis 6 mois est un runbook suspect. Je planifie un test trimestriel de chaque runbook critique.

2. Symptômes et détection

Comment sait-on qu’on est dans ce cas ? Quel est le message d’alerte exact, quel dashboard regarder, quel log consulter :

# Alerte Prometheus/Alertmanager :
# "DiskSpaceCritical - /var usage > 90% on srv-prod-01"

# Vérification manuelle :
df -h /var
du -sh /var/* | sort -rh | head -20

3. Diagnostic rapide

Les 3-4 commandes à exécuter pour comprendre la situation en moins de 2 minutes. Pas d’analyse profonde — juste assez pour orienter l’action.

4. Actions de remédiation

Les commandes exactes, dans l’ordre, avec les résultats attendus. C’est le cœur du runbook.

5. Vérification post-action

Comment confirmer que le problème est résolu. Pas juste « ça a l’air de marcher » — des vérifications concrètes.

6. Escalade

Si les étapes précédentes n’ont pas suffi : qui contacter, quelles infos fournir, quel est le plan B.

7. Post-mortem rapide

Un template de 3 lignes à remplir après chaque exécution du runbook : cause racine, action corrective prise, action préventive à planifier.

4 cas concrets de runbooks Linux

La théorie c’est bien, mais un runbook infrastructure ne vaut que par son contenu opérationnel. Voici quatre cas que je rencontre régulièrement chez mes clients, avec les extraits de runbook que j’utilise en production.

Cas 1 : SSH bloqué — impossible de se connecter au serveur

C’est l’incident qui fait transpirer : tu ne peux même plus accéder au serveur pour diagnostiquer. Voici mon runbook pour ce cas :

# 1. Vérifier si le serveur répond au réseau
ping -c 3 srv-prod-01.example.com
traceroute srv-prod-01.example.com

# 2. Tester SSH en mode verbose
ssh -vvv user@srv-prod-01.example.com

# 3. Si inaccessible : utiliser la console VNC/IPMI du provider (OVH, IONOS...)

# 4. Une fois connecté via console, vérifier :
systemctl status sshd
journalctl -u sshd -n 50 --no-pager

# 5. Causes fréquentes :
# - fail2ban a banni ton IP
fail2ban-client status sshd
fail2ban-client set sshd unbanip TON_IP

# - Firewall bloquant
iptables -L -n | grep 22
nft list ruleset | grep 22

# - Disque plein empêchant l'écriture du fichier authorized_keys
df -h /

Ce runbook a sauvé la mise à plusieurs de mes clients qui avaient oublié de whitelister leur nouvelle IP après un changement de FAI.

Cas 2 : Disque plein — /var à 100%

L’incident le plus fréquent en PME. Voici la checklist incident serveur Linux que je déroule systématiquement :

# Diagnostic : qu'est-ce qui prend de la place ?
du -sh /var/* | sort -rh | head -10
du -sh /var/log/* | sort -rh | head -10

# Les journaux systemd sont souvent coupables :
journalctl --disk-usage
# Si > 2G, nettoyer :
journalctl --vacuum-size=500M

# Vieux logs compressés :
find /var/log -name "*.gz" -mtime +30 -delete

# Docker est un gros consommateur silencieux :
docker system df
# Si nécessaire (supprime les données non utilisées) :
docker system prune -f

# Fichiers supprimés mais encore ouverts (piège classique) :
lsof +L1 | grep deleted

# Vérification post-action :
df -h /var
# Objectif : usage < 80%

J'automatise la surveillance de l'espace disque avec Prometheus et des alertes à 80% et 90%. Mais quand l'alerte arrive, c'est ce runbook qu'on déroule.

Cas 3 : Service applicatif qui ne redémarre pas

# Identifier le service en échec
systemctl --failed

# Examiner les logs du service (exemple : nginx)
systemctl status nginx
journalctl -u nginx -n 100 --no-pager

# Causes fréquentes :
# - Erreur de configuration
nginx -t

# - Port déjà utilisé
ss -tlnp | grep :80
# Si un autre process occupe le port :
kill $(lsof -ti:80)

# - Permissions fichier modifiées
ls -la /etc/nginx/nginx.conf
namei -l /var/www/html

# - Certificat expiré ou DB down
openssl x509 -in /etc/ssl/certs/mon-cert.pem -noout -dates
systemctl status postgresql

# Redémarrer proprement
systemctl restart nginx
systemctl status nginx

Cas 4 : Backup en échec silencieux

Celui-là est vicieux : tout a l'air de fonctionner, mais le jour où tu as besoin de restaurer, tu découvres que les backups ont échoué depuis des semaines.

# Vérifier la date du dernier backup réussi
ls -lah /backup/latest/

# Si backup via restic :
restic -r /backup/repo snapshots --latest 5
restic -r /backup/repo check

# Si backup via borgbackup :
borg list /backup/repo --last 5
borg check /backup/repo

# Vérifier les logs du cron de backup
grep -i backup /var/log/syslog | tail -20
journalctl -u backup-daily.timer -n 20

# Tester une restauration partielle (TOUJOURS tester !)
mkdir /tmp/restore-test
restic -r /backup/repo restore latest --target /tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /tmp/restore-test/etc/nginx

# Nettoyer le test
rm -rf /tmp/restore-test

Je recommande de planifier un test de restauration mensuel. Un backup qu'on n'a jamais testé n'est pas un backup — c'est un espoir.

Intégrer le runbook dans les ops quotidiennes

Avoir un runbook dans un coin de wiki ne sert à rien s'il n'est pas intégré dans les opérations quotidiennes. Voici comment je les rends vivants et utiles :

Stocker les runbooks dans Git

Je stocke tous mes runbooks en Markdown dans un dépôt Git dédié. Chaque modification est tracée, revue, et versionnée. La structure du repo ressemble à ça :

runbooks/
├── infra/
│   ├── disk-full-var.md
│   ├── ssh-locked-out.md
│   └── ssl-cert-expired.md
├── app/
│   ├── nginx-crash.md
│   └── postgres-replication-lag.md
├── backup/
│   ├── backup-failure.md
│   └── restore-procedure.md
└── templates/
    └── runbook-template.md

Lier les alertes aux runbooks

Chaque alerte Prometheus/Alertmanager inclut un lien direct vers le runbook correspondant dans ses annotations :

- alert: DiskSpaceCritical
  expr: (node_filesystem_avail_bytes{mountpoint="/var"} / node_filesystem_size_bytes{mountpoint="/var"}) * 100 < 10
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Disque /var critique sur {{ $labels.instance }}"
    runbook_url: "https://git.internal/runbooks/infra/disk-full-var.md"

Quand l'alerte arrive dans Slack ou par email, le lien vers le runbook est là. Pas besoin de chercher — on clique et on déroule.

Maintenir et améliorer continuellement

Un plan d'exploitation Linux en entreprise n'est complet que si les runbooks sont vivants. Voici mes règles :

Cette discipline transforme les runbooks d'un document statique en un outil d'amélioration continue. C'est aussi une composante essentielle d'un vrai audit de gouvernance d'infrastructure : vérifier que les procédures existent, sont à jour, et sont réellement utilisées.

Automatiser ce qui peut l'être

Certains runbooks peuvent être partiellement ou totalement automatisés. Le nettoyage de logs, la rotation des journaux systemd, la vérification des backups — tout ça peut devenir un playbook Ansible ou un script cron. Mais j'insiste : garder le runbook même quand l'action est automatisée. L'automatisation peut échouer, et il faut pouvoir reprendre en manuel.

Si vous gérez une infrastructure PME et que la mise en place de ces processus vous semble chronophage, c'est exactement le type de mission que je prends en charge en infogérance serveur Linux : je mets en place les runbooks, les alertes, et les automatisations adaptées à votre contexte.

Passez à l'action

Un runbook Linux bien structuré, c'est la différence entre « on gère l'incident en 10 minutes » et « on a passé la nuit dessus ». En PME, où chaque heure d'indisponibilité compte, c'est un investissement qui se rentabilise dès le premier incident évité.

Si vous voulez mettre en place des runbooks adaptés à votre infrastructure, ou si vous cherchez un regard externe sur vos procédures d'exploitation, contactez-moi. J'accompagne des PME et éditeurs SaaS dans la fiabilisation de leur infrastructure Linux — des runbooks à la supervision, en passant par l'automatisation des réponses à incident.

Quitter la version mobile