Incidents et SRE-playbooks

1) Qu'est-ce qu'un incident et comment il est corrélé avec SLO

L'incident est un événement qui perturbe la fonction SLO/service ou crée un risque de violation (un budget erroné est inacceptable rapidement).
Métriques classiques : MTD, MTTA, MTR, MTBF.
L'erreur de budget et burn-rate définit la priorité et les fenêtres d'escalade.

2) Niveaux de gravité (SEV) et critères

Déclencheurs SEV : dépassement de 5xx %, p95> seuil, paiement décline spike, Kafka-lag> seuil, NodeNotReady> X min, TLS expire <7 jours, signaux DDoS/fuite.

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

Incident Commander (IC) - prise de décision unique, gestion du flux de tâches, changement de statut SEV.
Ops Lead (Tech Lead) - stratégie technique, hypothèses, coordination des fiches.
Communication Lead (Comms) - Status Update (interne/externe), StatusPage/Chat/Mail.
Scribe (Chroniqueur) - temps, solutions, artefacts, liens graphiques/logs.
On-call Engineers/SMEs - exécution des actions sur le pleybuck.
Security/Privacy - activé en cas d'incident de sécurité ou PII.
FinOps/Payments - avec un impact sur la facturation/PSP/coût.

4) Cycle de vie de l'incident

1. Detect (alert/report/synthétique) → auto-création de la carte d'incident.
2. Triage (IC attribué, SEV attribué, collection du contexte minimum).
3. Stabilisation (mitigation : éteindre fich/rollback/rate-limit/failover).
4. Enquête (hypothèses RCA, collecte de faits).
5. Restauration du service (validate SLO, observation).
6. Communication (intérieur/extérieur, rapport final).
7. Post mortem (sans charges, plan CAPA, propriétaires, délais).
8. Prevention (tests/alertes/playbooks/drapeaux, pré-formation de l'équipe).

5) Communications et « salle de guerre »

Un seul canal d'incident ('# inc-sev1-YYYYMMDD-hhmm'), seulement les faits et les actions.
Commandes dans le style du protocole radio : "IC : j'attribue un rollback à la version 1. 24 → ETA 10 min".
Statut Apdate : SEV-1 toutes les 15 min, SEV-2 toutes les 30 à 60 min.
Page d'état/communication externe - via Comms Lead par modèle.
Interdit : chambres parallèles « silencieuses », hypothèses non testées dans le canal commun.

6) Alerting et SLO-burn (exemple de règles)

Canal rapide (1-5 min) et canal lent (1-2 h) burn-rate.
Signaux multiples : erreur de budget, 5xx %, p95, Kafka-lag, paiement décline-rate, synthétique.
La recherche de la cause première n'est effectuée qu'après la stabilisation des symptômes.

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) Pleybooks vs ranbooks

Pleybuk est un scénario d'action par type d'incident (branches, conditions, risques).
Ranbook est une « carte » spécifique des étapes/commandes (vérifications, fiches, vérification).
Règle : Pleybuck fait référence à plusieurs classements (rollbacks, feature-flags, failover, zoom, blocage du trafic, etc.).

8) Modèle de carte d'incident

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) Modèle SRE-playbook (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) Playbooks types

10. 1 API 5xx Spike

Stabilisation : Désactiver la flagellation problématique ; augmenter les répliques de l'API ; activer la mise en cache ; Retour sur la sortie.
Diagnostic : diff release, erreurs dans les logs (top-exceptions), croissance p95, pression OBD/cache.
Risques : cascade dans les paiements/backends.

10. 2 БД: replication lag / lock storm

Stabilisation : suspension des jobs/reports lourds ; Rediriger les lectures vers l'assistant ; Augmenter le wal_buffers/replika-sloty.
Diagnostics : longues transactions, demandes de blocage, changements de plan.
Fixation : indices/hints, réaménagement des jobs, partitionnement des requêtes.

10. 3 Kafka consumer lag

Stabilisation : dimensionner temporairement le consumer's ; réduire la production à partir de services non critiques ; augmenter les lots/quotas.
Diagnostic : rebalances, lentes désérialisations, pauses GC.
Vérification : lag → à la valeur cible, pas de drop.

10. 4 K8s NodeNotReady/tempête de ressources

Stabilisation : cordon + drain ; redistribuer les charges ; vérifier le CNI/overlay ; éteindre les DaemonSet bruyants.
Diagnostic : disk pressure, OOM, throttling, drops réseau.
Prévention : pod dissolution des budgets, limites de ressources/demandes.

10. 5 TLS/certificats expirent

Stabilisation : mise à jour forcée du secret/ingress ; override temporaire.
Diagnostic : chaîne de confiance, clock-skew.
Prévention : alertes T-30/T-7/T-1, auto-renewal.

10. 6 DDoS/trafic anormal

Stabilisation : WAF/bot règles, rate-limit/geo-filtres, upstream shed load.
Diagnostic : profils d'attaque (L3/4/7), sources, « parapluies ».
Prévention : anycast, autoscaling, cache, play-nice avec les fournisseurs.

10. 7 Paiement PSP-Outdoor

Stabilisation : routage intelligent sur d'autres PSP/méthodes ; Soulevez retry avec un gitter ; dégradation « douce » de l'IU.
Diagnostic : spike des pannes par code, statuts API/PSP Status Page.
Communications : Apdates transparentes pour les entreprises et le Sapport, statistiques de ND/conversion correctes.

10. 8 Incident de sécurité/fuite de PII

Stabilisation : Isolation des nœuds/rotation secrète, verrouillage d'exfiltration, Legal Hold.
Diagnostic : accès temporel, sujets/champs touchés.
Avis : organismes de réglementation/partenaires/utilisateurs selon les exigences des juridictions.
Prévention : renforcement de la DLP/segmentation, « least privilège ».

11) Automatisation des playbooks

Commandes ChatOps : '/ic set sev 1 ', '/deploy rollback api 1. 23. 4`, `/feature off X`.
Runbook-bots : étapes semi-automatiques (drain node, flip traffic, purge cache).
Self-healing hooks : détecteur → mitigation standard (rate-limit, restart, scale).
Auto-création de cartes/temporisation à partir d'alerts et de commandes.

12) Qualité des playbooks : check-list

• Symptômes clairs et détecteurs (métriques/logs/tracés).
• Étapes rapides de stabilisation avec évaluation des risques.
• Les commandes/scripts sont à jour, vérifiés dans staging.
• Vérification de la récupération de SLO.
• Modèles de communication et critères d'updates externes.
• Référence post mortem et APA après fermeture.

13) Post mortem (blameless) et CAPA

L'objectif est de s'instruire, pas de trouver le coupable.
Contenu : ce qui s'est passé, comment on a découvert ce qui était bon/mauvais, la contribution des facteurs (ceux + processus), les actions pour prévenir.
Délai : SEV-1 - dans les 48 heures ; SEV-2 - 3 jours ouvrables.
CAPA : propriétaires spécifiques, échéancier, effets mesurables (diminution du TTMT/croissance du TTMT).

14) Aspects juridiques et base de preuve

Legal Hold : gel des logs/pistes/alerts, stockage write-once.
Chaîne de stockage des artefacts : accès par rôle, contrôle de l'intégrité.
Avis réglementaires : délais/modèles pour les administrations (en particulier pour les paiements/IPI touchés).
Privacy : minimiser et masquer les IPI lors de l'analyse.

15) Mesures de l'efficacité du processus d'incident

MTTD/MTTA/MTR par quartier et par domaine.
SEV correct (underrating/overrating).
Proportion d'incidents auto-mitigate.
Couverture de pleybuks top N scénarios (> 90 %).
Exécution du CAPA dans les délais.

16) Mise en œuvre par étapes

1. Semaine 1 : matrice SEV, rôles on-call, modèle de carte générale, règlement war-room.
2. Semaine 2 : Pleybooks pour le top 5 des symptômes (5xx, DB-lag, Kafka-lag, NodeNotReady, TLS).
3. Semaine 3 : ChatOps/bots, auto-création de cartes, modèles de communication/StatusPage.
4. Semaine 4 + : Pleybooks de sécurité, PSP-outeiji, Legal Hold, régulièrement drague/jeux de chaos.

17) Exemples de rangées « rapides » (fragments)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

Drain node

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Feature-flag OFF (exemple)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) Mini-FAQ

Quand soulever un SEV-1 ?
Lorsque la fonction clé SLO/Business (paiements, login, jeu) souffre, et burn-rate « mange » le budget des heures à l'avance.

Qu'est-ce qui est plus important - RCA ou récupération ?
Toujours stabilisation, puis RCA. Le temps avant la stabilisation est le principal indicateur.

Dois-je tout automatiser ?
Automatiser les étapes fréquentes et sécurisées ; rare/risqué - via semi-auto et confirmation IC.

Total

Un processus d'incident robuste repose sur trois piliers : des rôles clairs et des règles SEV, des playbooks/ranks de qualité avec automatisation et une culture post mortem sans frais. Fixez les modèles, entraînez-vous en ligne, mesurez le MTTR/budget défectueux et améliorez constamment les détecteurs et les playbooks, ce qui réduit directement les risques et le coût des interruptions de service.