Best Practices3 February 20258 min readFrançais

Le runbook on-call dont chaque petite équipe a besoin

Un incident à 3h du matin n'est pas le bon moment pour définir votre processus.

Best PracticesUptime MonitoringWebsite MonitoringApi MonitoringCron Job Monitoring
Best Practices

Vous n'avez pas besoin d'une équipe de 50 personnes pour avoir un processus de réponse aux incidents solide.

Ce qu'est un runbook (et ce qu'il n'est pas)

Un runbook n'est pas un guide de dépannage pour chaque panne possible. C'est une liste de contrôle pour les 30 premières minutes d'un incident.

Cadre de réponse aux incidents en 5 étapes

1. Reconnaître (0–2 min) — Revendiquer l'incident. 2. Évaluer (2–5 min) — Qu'est-ce qui est vraiment cassé ? 3. Communiquer (5 min) — Mettre à jour la page de statut. 4. Atténuer (5–30 min) — Revenir à un état fonctionnel. 5. Documenter (après incident) — Écrire un postmortem sans reproche.

Niveaux de gravité pour les petites équipes

SEV1 — Production en panne. Réveiller l'astreinte. SEV2 — Dégradé. Traiter pendant les heures ouvrables. SEV3 — Mineur. Créer un ticket.

Qui réveiller et quand

- Ingénieur d'astreinte : premier intervenant pour tous les SEV1/SEV2 - Responsable technique : escalader si non résolu en 30 minutes

Outils et commandes rapides

git log --oneline -10 origin/main
docker compose restart api
This article is available across the supported locale routes — use the language switcher above to change.

Guide produit

Uptime Monitoring

AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.

Lire le guide

Page alternative

Better Stack Alternative

Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.

Voir la comparaison
AD
AlertsDock Team
3 February 2025
Try AlertsDock free