Pourquoi vous avez besoin d’un plan écrit
Pendant un incident, votre cerveau ne fonctionne pas à pleine capacité. Le stress rétrécit votre concentration. Vous oubliez des étapes. Vous sautez la communication. Vous corrigez le symptôme mais pas la cause.
Un plan de réponse aux incidents écrit élimine la réflexion des 10 premières minutes. Vous suivez une liste de contrôle. Vous savez quoi faire et dans quel ordre. Le plan gère le processus pour que votre cerveau puisse gérer le débogage.
Ce modèle est conçu pour les petites équipes (2 à 10 personnes). Il suppose que vous n’avez pas d’équipe SRE dédiée ni d’astreinte avec 15 personnes. Il suppose que la personne qui est alertée est aussi celle qui corrige le problème.
Le plan de réponse aux incidents
Étape 1 : Détecter
Votre outil de surveillance vous alerte. Vous recevez une notification : « Le moniteur [nom] est hors service. 3 échecs consécutifs. HTTP 500. »
Ne paniquez pas. Prenez 30 secondes pour vérifier. Consultez le site vous-même. Vérifiez votre tableau de bord de surveillance pour d’autres alertes. Un seul moniteur hors service peut être une fausse alerte. Plusieurs moniteurs hors service signifient un vrai incident.
Si vous utilisez PingWatchdog, les incidents sont créés automatiquement lorsque les moniteurs tombent en panne. Vous obtenez une chronologie de ce qui s’est passé et quand. C’est votre point de départ pour le débogage.
Étape 2 : Déclarer
S’il s’agit d’un véritable incident (pas une fausse alerte ni un événement planifié), déclarez-le. Informez votre équipe. Informez vos utilisateurs.
Pour votre équipe : Publiez dans votre canal d’incident désigné (Slack, Discord, Teams). Incluez ce que vous savez : quels moniteurs sont hors service, quand ils sont tombés, quelles erreurs vous voyez. Mentionnez toute personne qui pourrait devoir être impliquée.
Pour vos utilisateurs : Mettez à jour votre page de statut. Publiez une mise à jour « En cours d’investigation ». Vous n’avez pas besoin de connaître la cause racine. Vous devez simplement reconnaître le problème. « Nous enquêtons sur des signalements d’erreurs API accrues. Prochaine mise à jour dans 15 minutes. »
Votre page de statut doit se mettre à jour automatiquement à partir de vos données de surveillance. Si un moniteur est hors service, la page de statut doit le montrer. La mise à jour manuelle indique aux utilisateurs que vous êtes dessus.
Étape 3 : Enquêter
Commencez par l’explication la plus simple. Avez-vous déployé récemment ? Une dépendance a-t-elle changé ? Un service tiers a-t-il eu un incident ?
Vérifiez vos données de surveillance. Quelles erreurs les sondes signalent-elles ? Connexion refusée ? Échec DNS ? Délai d’attente ? HTTP 500 avec un message d’erreur spécifique ? Les données des sondes montrent ce que le monde extérieur voit.
Vérifiez vos logs. Logs d’application, logs de base de données, logs de serveur web. Cherchez des erreurs qui ont commencé à peu près au même moment où le moniteur est tombé.
Vérifiez votre infrastructure. Le serveur est-il en ligne ? La base de données accepte-t-elle les connexions ? L’utilisation de la mémoire ou du disque grimpe-t-elle ? L’utilisation du CPU est-elle anormale ?
Étape 4 : Atténuer
Une fois que vous savez ce qui ne va pas, arrêtez l’hémorragie. Ce n’est peut-être pas la solution permanente. C’est bien. L’objectif est de rétablir le service d’abord, puis de corriger la cause racine.
Atténuations courantes :
- Déployer un rollback : Si un déploiement récent a causé le problème, revenez à la version précédente. Déployez le correctif après la résolution de l’incident.
- Redémarrer un service : Les pools de connexions de base de données, les serveurs de cache et les files d’attente de messages ont parfois besoin d’un redémarrage. Redémarrez le service et surveillez la récupération.
- Augmenter les ressources : Si le problème est l’épuisement des ressources (CPU, mémoire, connexions), augmentez la capacité. Vous pourrez réduire après l’incident.
- Basculer : Si un seul serveur ou une seule région est affecté, redirigez le trafic ailleurs.
Étape 5 : Communiquer
Pendant l’atténuation, publiez une autre mise à jour de statut. « Problème identifié comme épuisement du pool de connexions de base de données. Nous déployons un correctif. »
Après le déploiement du correctif, publiez à nouveau. « Correctif déployé. Surveillance de la récupération. »
Après avoir confirmé la récupération, publiez la mise à jour finale. « Service rétabli. Durée de l’incident : 23 minutes. »
Ne laissez pas plus de 30 minutes s’écouler sans mise à jour, même si la mise à jour est « Toujours en cours d’investigation. Nous avons circonscrit le problème à la couche base de données. » Le silence crée l’incertitude. Les mises à jour créent la confiance.
Étape 6 : Résoudre
Attendez que vos moniteurs confirment la récupération. Ne déclarez pas l’incident résolu sur la base d’une vérification manuelle rapide. Laissez les vérifications automatisées vérifier que le service est stable.
PingWatchdog résout automatiquement les incidents lorsque les moniteurs reviennent à l’état « en ligne » pendant une période soutenue. Cela garantit que vous ne clôturez pas un incident prématurément.
Étape 7 : Post-mortem
Dans les 24 heures suivant l’incident, rédigez un bref post-mortem. Il n’a pas besoin d’être un document formel. Un message Slack ou un court document suffit. Répondez à ces questions :
- Que s’est-il passé ? Décrivez l’incident en langage clair.
- Quel a été l’impact ? Combien de temps les services ont-ils été affectés ? Quels services ? Combien d’utilisateurs ?
- Quelle était la cause racine ? Qu’est-ce qui a spécifiquement déclenché la panne ?
- Comment a-t-elle été détectée ? La surveillance l’a-t-elle détectée ? Un utilisateur l’a-t-il signalée ?
- Comment a-t-elle été résolue ? Quelles mesures ont été prises pour la corriger ?
- Qu’est-ce qui empêchera la récurrence ? Quels éléments d’action découlent de cela ?
L’objectif du post-mortem n’est pas d’attribuer des reproches. C’est d’apprendre et de s’améliorer. Chaque incident est une opportunité de rendre votre système plus fiable.
Mettre en place votre boîte à outils d’incident
Pour exécuter ce plan, vous avez besoin de quelques éléments en place avant qu’un incident ne survienne :
Surveillance : Surveillance de disponibilité, surveillance SSL et surveillance heartbeat. Vous devez être informé des problèmes avant que les utilisateurs ne les signalent. Configurez la surveillance PingWatchdog.
Alertes : Alertes acheminées vers les bons canaux. Les moniteurs critiques vont vers PagerDuty ou les notifications téléphoniques. Les non-critiques vont vers Slack. Configurez les canaux d’alerte.
Page de statut : Une page de statut publique où les utilisateurs peuvent vérifier la santé du service. Les mises à jour pendant les incidents doivent être rapides et honnêtes. Configurez une page de statut.
Gestion des incidents : Incidents créés automatiquement avec des chronologies. Lorsqu’un incident commence, vous ne devriez pas avoir à créer un ticket manuellement. L’outil de surveillance doit le faire pour vous. En savoir plus sur la gestion des incidents.
Canaux de communication : Un canal Slack, un salon Discord ou un canal Teams désigné pour les incidents. Tout le monde sait où aller pendant un incident.
Pratiquez le plan
Faites un exercice d’incendie. Choisissez un service non critique. Mettez-le hors ligne intentionnellement. Suivez le plan. Chronométrez la durée de chaque étape.
La plupart des équipes constatent que la partie la plus difficile n’est pas la correction technique. C’est la communication. « J’ai corrigé le problème en 5 minutes mais j’ai passé 15 minutes à comprendre quoi dire sur la page de statut. » La pratique rend la communication plus rapide.
Commencez à élaborer votre plan
Le modèle ci-dessus fonctionne tel quel. Personnalisez les noms de canaux, les chemins d’escalade et les références d’outils pour votre équipe. Restez concis. Si le plan fait plus d’une page, votre équipe ne le lira pas pendant un incident.
Commencez la surveillance gratuitement avec PingWatchdog. Chaque plan inclut la gestion des incidents avec création et résolution automatiques des incidents.