Alertes et astreinte solo

Prérequis : cours 7.2 (signaux).

Pourquoi

En solo, pas d'équipe de garde : soit ça t'alerte au bon moment, soit tu découvres la panne par hasard trois jours plus tard. Le système doit être simple au point de survivre à ta propre fatigue.

Concepts

• Les 3 alertes : prod down (health KO 2 checks de suite — pas 1, pour éviter les faux positifs de restart), backup en échec (dump absent ou vide le matin), disque > 80 %. Le reste (latence, 4xx, charge) = graphiques du matin avec le café. Canal : push ou mail qui arrive vraiment (tester !), pas un salon de chat que personne ne lit.
• Runbook : 5 lignes écrites à froid pour une panne déjà vécue (constater → soulager → cause → vérifier → post-mortem). Suivi en panique, béni ensuite.
• Post-mortem sans blâme : timeline factuelle → cause racine (méthode des « 5 pourquoi » : demander « pourquoi ? » 5 fois de suite pour creuser jusqu'à la vraie cause) → une action anti-récidive avec responsable (= toi) et date.

Exemple : runbook disque plein

1. df -h → confirmer, du -sh /var/* → localiser
2. Soulager : journalctl --vacuum-size, docker image prune
3. Cause : rotation ? volume ? fuite de logs ?
4. Vérifier : health + métier, monitorer 30 min
5. Post-mortem : action anti-récidive datée

Cas réel

Alerte « disque > 80 % » reçue un mardi midi, purge en 5 minutes, post-mortem : rotation des logs Caddy absente → ajoutée. Sans l'alerte : down le jeudi. Coût total : 10 minutes contre une soirée.

Pièges

• « Faire attention la prochaine fois » : ce n'est pas une action. « Timer qui vérifie le dump + alerte » en est une.
• Runbook jamais relu : obsolète en 6 mois (chemins, noms). Relire à chaque incident.
• Multiplier les canaux d'alerte : un seul qui marche vaut dix qui spamment.

À retenir

3 alertes actionnables, runbook par panne vécue, post-mortem = 1 action datée.