Gérer un incident de la détection à la reprise

Déclarer l’incident à partir de son impact

Un incident est un événement qui perturbe, dégrade ou menace suffisamment le service pour nécessiter une réponse coordonnée. Votre organisation définit les niveaux de gravité et les règles d’escalade. Appliquez-les selon l’impact utilisateur, les données touchées, la durée et le périmètre.

N’attendez pas une explication complète de la cause racine pour demander de l’aide. Une description claire de l’impact observé suffit à lancer la coordination. Distinguez un soupçon de sécurité d’une conclusion confirmée.

Préparez le circuit de réponse avant la mise en production. Gardez les coordonnées, procédures d’accès, runbooks et canaux de communication disponibles lorsque le service principal est inaccessible. Testez ce circuit avec un incident fictif.

Attribuer les responsabilités avant des changements concurrents

La coordination d’incident fixe les priorités et gère les décisions. Les intervenants techniques enquêtent et atténuent les effets. La communication informe les personnes touchées. Google SRE décrit ces responsabilités comme des rôles distincts. Les petites équipes peuvent les cumuler, mais doivent couvrir tout le travail. Réponse aux incidents.

Tenez une chronologie partagée unique. Consignez l’heure, l’observation, l’action, l’acteur et le résultat. Distinguez les faits des hypothèses. Utilisez un fuseau horaire commun et signalez les horodatages peu fiables.

Examiner un incident fictif

Toutes les heures ci-dessous sont en UTC. L’organisation désigne un coordinateur lorsque l’échec de l’export touche plusieurs clients.

Un premier point utile indique la fonction touchée, le périmètre connu, l’atténuation et l’heure du prochain point. Il ne promet pas un délai de réparation sans preuve. N’incluez pas de données client dans cette communication partagée.

À 09:10, l’incident change. Rétablir les exports ne suffit plus. L’équipe doit évaluer une divulgation possible, contrôler les accès, préserver les preuves et faire intervenir les responsables de décision appropriés.

Atténuer sans perdre le contrôle

Utilisez des runbooks testés lorsqu’ils s’appliquent. Vérifiez les préconditions avant un retour arrière, un basculement ou une modification d’identifiants. Une ancienne version de l’application peut ne pas comprendre le schéma actuel de la base. Un basculement régional peut déplacer les mêmes données corrompues.

Un assistant IA peut organiser des preuves expurgées ou comparer des hypothèses dans les limites approuvées. Les intervenants doivent vérifier ses conclusions. Les journaux et les tickets sont des entrées non fiables, pas une autorisation d’en exécuter le contenu.

Un accès d’urgence doit avoir un objectif autorisé, une durée limitée et une trace d’audit. L’urgence ne rend pas correcte une commande suggérée par un agent.

Clore séparément la reprise et le suivi

Vérifiez le parcours utilisateur, l’intégrité des données, les limites d’accès et la fraîcheur de la supervision avant de déclarer le service rétabli. Consignez les restrictions restantes. Gardez l’enquête de sécurité ouverte si des questions demeurent.

Examinez ensuite les conditions qui ont rendu l’incident possible. Attribuez des actions concrètes avec un responsable et des critères de vérification. Une revue sans recherche de coupable vise une explication exacte et des changements utiles. Elle ne retire pas la responsabilité de terminer ces changements. Pratique du postmortem.

Poursuivez avec les opérations de sécurité et la boucle de retour d’expérience.