Escalade des incidents

1) Objectif et principes

L'escalade des incidents est un processus géré pour attirer rapidement les bons rôles et ressources afin de minimiser l'impact sur les utilisateurs et les métriques d'entreprise.

• La vitesse est plus importante que l'idéalité. Mieux vaut déclarer l'incident plus tôt et désescaler que d'être en retard.
• Un commandement unifié. L'un des responsables de la solution est le commandant d'incident (IC).
• Transparence. Des statuts et des canaux de communication clairs pour les steakholders internes et externes.
• Documentabilité. Toutes les étapes, solutions et temporisations sont enregistrées pour l'audit et les améliorations.

2) Gradation de gravité (niveaux SEV/P)

• SEV-0/P0 (critique) - indisponibilité totale de la fonction clé (login/paiement), fuite de données, risque juridique. Page immédiate de tout le noyau on-call, freeze versions.
• SEV-1/P1 (élevé) - dégradation p95/p99, augmentation du taux d'erreur/échec dans le processus clé, indisponibilité de la région/fournisseur.
• SEV-2/P2 (moyenne) est une dégradation partielle pour une cohorte limitée (région, fournisseur), il y a une solution de contournement.
• SEV-3/P3 (faible) - n'est pas critique pour l'utilisateur, mais nécessite une attention (retard de fond ETL, rapport en retard).

• Rayon d'impact (nombre d'utilisateurs/chiffre d'affaires) × durée × sensibilité (régulateur/PR) → niveau SEV.

3) Processus KPI

MTTD (temps de détection) - du début de l'incident au premier signal.
MTTA (temps de réception) - du signal à la confirmation IC.
MTTR (temps de récupération) - avant la restauration SLO/fonction.
Escalation Latency : De la confirmation à la connexion du rôle/de la commande désiré.
Reopen Rate est la proportion d'incidents rouverts après « résolu ».
Bou SLA - respect des intervalles d'updates externes/internes.

4) Rôles et responsabilités (RACI)

Commandant d'incident (IC) : le propriétaire de la solution, définit le niveau, le plan, freeze, escalade, désescalade. Je n'écris pas de fictions.
Tech Lead (TL) : diagnostic technique, hypothèses, coordination des ingénieurs.
Comms Lead (CL) : pages de statut, communication client et interne, alignement avec Legal/PR.
Scribe : fixation exacte des faits, du temps, des décisions prises.
Liens : représentants de fournisseurs/équipes externes (paiements, KYC, hébergement).
Ingénieurs en ligne : exécution du plan, lancement du pleybuck/reculs.

Attribuez des graphiques de service et des backups pour chaque rôle.

5) Canaux et artefacts

Canal War-room (ChatOps) : un point de coordination unique (Slack/Teams) avec un modèle d'annotation automatique (versions, drapeaux, canaries).
Carte vidéo pour SEV-1 +.
Tiquet d'incident (one-pager) : ID, SEV, IC, participants, hypothèse/diagnostic, étapes, ETA, statut, impact, liens graphiques.
Page de statut : public/interne ; l'horaire des mises à jour régulières (par exemple, toutes les 15 à 30 minutes pour SEV-1 +).

6) Time Boxes et intervalles standard

T0 (min 0-5) : IC attribué, SEV attribué, versions libres (si nécessaire), war-room ouvert.
T + 15 min : premier message public/interne (ce qui est touché, workaround, prochaine fenêtre d'update).
T + 30/60 min : escalade du niveau suivant (plate-forme/OBD/sécurité/fournisseurs) s'il n'y a pas de dynamique durable.
Apdées régulières : SEV-0 : toutes les 15 min ; SEV-1 : toutes les 30 min ; SEV-2 + : toutes les heures.

7) Règles d'auto-escalade (politiques de déclenchement)

• Burn-rate budget d'erreur est au-dessus du seuil dans les fenêtres courtes et longues.
• Quorum d'échantillons externes : les ≥2 régions enregistrent la dégradation HTTP/TLS/DNS.
• Le SLI d'entreprise (succès des paiements/inscriptions) tombe en dessous du SLO.
• Signatures de sécurité : suspicion de fuite/compromission.
• Signal du fournisseur : Webhook du statut « grand outage ».

8) Processus de la détection à la solution

1. Déclaration d'incident (IC) : SEV, couverture, freeze, lancement de playbooks.
2. Diagnostic (TL) : hypothèses, isolation de rayon (région, fournisseur, ficha), contrôles (DNS/TLS/CDN/OBD/cache/bus).
3. Actions de mitigation (victoires rapides) : retour/canari de ↓, drapeau de dégradation de ficha, failover du fournisseur, rate-limit, kesh-overley.
4. Communication (CL) : statu quo, clients/partenaires, Legal/PR, mises à jour selon les horaires.
5. Confirmation de la récupération : synthétique externe + métriques réelles (SLI), retrait freeze.
6. Désescalade : diminution du SEV, passage à l'observation N minutes/heures.
7. Fermeture et RCA : préparation du post-mortem, des éléments d'action, des propriétaires et des échéances.

9) Travailler avec des fournisseurs externes

Échantillons propres aux fournisseurs de plusieurs régions + exemples miroirs de requêtes/erreurs.
Accords d'escalade (contacts, réponse SLA, priorité, statut Web).
Failover automatique/redistribution du trafic sur le fournisseur SLO.
Base de données probantes : timline, sample demandes/réponses, graphiques de latence/erreurs, ID ticket du fournisseur.

10) Réglementation, sécurité et relations publiques

Security/P0 : isolement, collecte d'artefacts, minimisation de la divulgation, avis obligatoires (interne/externe/régulateur).
Juridique : harmonisation du libellé des mises à jour externes, prise en compte des SLA/pénalités contractuelles.
PR/Service à la clientèle : modèles de réponses prêtes à l'emploi, Q&A, rémunération/crédits (le cas échéant).

11) Modèles de messages

• "Nous enquêtons sur un incident de SEV-1 affectant [la fonction/la région]. Symptômes : [bref]. Nous avons activé la solution de contournement [description]. La prochaine mise à jour est à [heure]"

• "Diagnostic : [hypothèse/confirmation]. Actions : [changer de fournisseur/faire tomber la version/activer la dégradation]. L'impact est réduit à [pourcentage/cohorte]. L'apdate suivant est [le temps]"

• "L'incident SEV-1 résolu. Cause : [racine]. Temps de récupération : [MTTR]. Prochaines étapes : [fix/check/observation N heures]. Post-mortem - [quand/où]"

12) Pleybooks (exemplaires)

Baisse du succès des paiements : réduire la part sur le fournisseur A, transférer X % sur B ; insérer « degrade-payments-UX » ; inclure les retraits dans les limites ; alerter l'équipe finlandaise.
Croissance de l'API p99 : réduire le canari de la nouvelle version ; éteindre les fiches lourdes ; Augmenter le cache-TTL ; vérifier les index OBD/connexions.
Problème DNS/TLS/CDN : vérifier les certificats/chaînes ; Mettre à jour l'enregistrement ; Commuter en un CDN de secours ; repasser le cache.
Sécurité-suspicion : isolation des nœuds, rotation clé, activation des stylos mTLS, collecte des artefacts, notification juridique.

13) Désescalade et critères « résolus »

• Le SLI/SLO est stable dans la zone verte ≥ N intervalles ;
• des actions de mitigation et d'observation - sans régression - ont été effectuées ;
• pour la classe security - la fermeture des vecteurs est confirmée, les clés/secrets sont rotés.

Fermeture - seulement après la fixation du délai, les propriétaires d'items d'action et les délais.

14) Post-mortem (non punitif)

1. Faits (le temps que les utilisateurs/métriques ont vu).

2. Cause racine (technique/processeur).

3. Ce qui a fonctionné/n'a pas fonctionné dans l'escalade.

4. Mesures préventives (tests, alertes, limites, architecture).

5. Plan d'action avec les deadlines et les propriétaires.

6. Communication avec error budget et révision du SLO/processus.

15) Métriques de la maturité du processus

Proportion d'incidents déclarés avant les plaintes des utilisateurs.
MTTA par niveau SEV ; le temps de connecter le bon rôle.
Respect des intervalles d'update (Bou SLA).
Pourcentage d'incidents résolus par des pleybuks sans « créativité » manuelle.
Exécution d'items d'après mortem à temps.

16) Anti-modèles

« Quelqu'un fait quelque chose » - pas d'IC/rôles.
Les multiples cheveux dans la salle de guerre sont un débat sur les versions au lieu d'actions.
Une déclaration tardive → une perte de temps pour rassembler les gens.
Pas de freeze et d'annotations de version - les modifications parallèles masquent la cause.
L'absence de communication externe est une escalade des plaintes/risque de RP.
Fermeture sans post-mortem et action - nous répétons les mêmes erreurs.

17) Chèque-feuille IC (carte de poche)

• Attribuer un SEV et ouvrir une salle de guerre.
• Attribuer TL, CL, Scribe, vérifier on-call sont présents.
• Inclure release-freeze (sous SEV-1 +).
• Confirmer les sources de vérité : dashboards SLI, synthétiques, logs, tracing.
• Prendre des mesures de mitigation rapide (retour/drapeau/échec).
• Fournir des mises à jour régulières comme prévu.
• Enregistrer la Critique pour la Résolution et la Surveillance Après Récupération.
• Initier un post-mortem et désigner les propriétaires d'actions items.

18) Incorporation dans les opérations quotidiennes

Entraînement (jeux-jours) : simulations par scénarios clés.
Catalogue de playbooks : versioné, testé, avec des paramètres.
Outils : ChatOps commandes « /declare », « /page », « /status », « /rollback ».
Intégrations : tiketing, status page, post-mortem, CMDB/service-annuaire.
Alignement avec le budget SLO/Error : déclencheurs d'escalade automatique et règles freeze.

19) Résultat

L'escalade est une discipline opérationnelle, pas juste un appel de service. Des niveaux de SEV clairs attribués à IC, des playbooks prêts à l'emploi, des boîtes de temps de mise à jour et l'intégration avec les métriques SLO et les politiques de budget transforment un incendie chaotique en un processus gérable avec un résultat prévisible - une restauration rapide du service, un risque minimum de RP/réglementation et des améliorations systémiques après chaque incident.