Gestion des Incidents

Une classification claire de la gravité permet des réponses proportionnées sans sur-mobiliser les ressources pour des problèmes mineurs. Cadre standard: SEV-1 (Critique) — indisponibilité complète du service affectant tous ou la plupart des clients; nécessite une escalade immédiate à la direction de l'ingénierie, une notification exécutive et une mise à jour de la page de statut public dans les 15 minutes. SEV-2 (Majeur) — dégradation significative d'une fonctionnalité ou un sous-ensemble de clients incapable d'utiliser une fonctionnalité essentielle; nécessite une réponse de l'ingénierie d'astreinte et une mise à jour de la page de statut dans les 30 minutes. SEV-3 (Mineur) — dégradation limitée des fonctionnalités affectant un petit sous-ensemble de clients ou une fonctionnalité non critique; géré pendant les heures ouvrables avec un délai de résolution cible. SEV-4 (Informationnel) — problèmes cosmétiques ou dégradation mineure de l'UX avec une solution de contournement claire disponible; suivi comme un bug, résolu dans le cycle de développement normal. Le Support Ops forme les agents à classer correctement les incidents et à escalader immédiatement les SEV-1 et SEV-2 à l'équipe d'ingénierie d'astreinte.

La communication d'incident orientée client exige rapidité, honnêteté et une profondeur technique appropriée pour chaque public. Chronologie: dans les 15 minutes suivant la détection de l'incident, publier une mise à jour sur la page de statut public reconnaissant le problème (même si l'enquête ne fait que commencer — "Nous sommes conscients d'un problème affectant [Fonctionnalité X] et enquêtons"). Toutes les 30 minutes pendant les incidents actifs, mettre à jour la page de statut avec l'avancement de l'enquête. Une fois résolu, publier une mise à jour de clôture incluant: ce qui s'est passé (bref), quand cela a commencé et s'est terminé, et ce qui a été fait pour le résoudre. Dans les 72 heures, publier un résumé de l'examen post-incident pour les incidents SEV-1 et SEV-2, couvrant la cause première, la chronologie et les mesures de prévention futures. Les équipes de support gérant le volume de tickets entrants pendant les incidents doivent utiliser des réponses macro renvoyant à la page de statut, empêchant les agents de dupliquer les efforts d'enquête sur des tickets individuels.

Un postmortem sans blâme se concentre sur les défaillances du système et des processus, et non sur la faute individuelle — l'objectif est l'apprentissage et la prévention, pas l'attribution de responsabilités. Les postmortems efficaces incluent: une chronologie détaillée de l'incident, de la première détection à la résolution, reconstituée à partir des logs, des alertes de surveillance et des messages Slack; une analyse des causes profondes utilisant la technique des "5 Pourquoi" (demander "pourquoi?" à plusieurs reprises pour atteindre la véritable cause systémique plutôt que la cause immédiate); l'identification des facteurs contributifs au-delà de la cause première; et des actions concrètes pour prévenir la récurrence, chacune avec un propriétaire et une date d'échéance. Le Product Ops facilite la réunion postmortem (généralement 60 à 90 minutes, tenue dans les 5 jours ouvrables suivant la résolution), maintient la base de données des postmortems et suit l'achèvement des actions jusqu'à leur clôture, en rendant compte trimestriellement des taux d'achèvement des postmortems à la remédiation.