Opérations de playbooks

1) Qu'est-ce qu'un playbook et en quoi il diffère d'un runbook

Runbook est une instruction linéaire étape par étape pour une opération type/alerte (« fais une fois, deux, trois »).
Pleybuk est un arbre de décision pour les scénarios de bifurcation : différents symptômes → différentes hypothèses → différentes branches d'action. Inclut les critères de sélection, les conditions de gate et les branches de fallback.
L'objectif du playbook est de réduire le MTTA/MTR et le niveau d'improvisation en cas d'incertitude.

2) Où les playbooks sont nécessaires en premier lieu

Incidents : chute du SLO (availability/latency/success), échec du SLI (conversion/succès des paiements).
Changements : sorties, migrations, drapeaux ficha, configi (canary/rollback).
Fenêtres de service : mises à niveau OBD/courtiers, rotation des certificats.
Fournisseurs : PSP/KYC/CDN/IDP - dégradation et swich-over.
Sécurité : clé compromise, activité suspecte.
DataOps : retard de fraîcheur, dérive du circuit, dégradation de la pipline.

3) Normes de Pleybuk (composition minimale)

1. Carte : ID, Version/Date, Propriétaire (équipe/rôle), Services/régions/tenants, Politiques/normes connexes.
2. Objectif et conditions de lancement : quels SLO/SLI nous protégeons, quels alertes/déclencheurs sont applicables.
3. Symptômes ↔ Hypothèses : tableau des correspondances, comment couper rapidement les hypothèses erronées.
4. Arbre de décision : bifurcations, gates de sécurité, critères d'arrêt/continuation.
5. Actions : blocs pas à pas avec commandes/liens vers runbook '.
6. Communications : modèle d'update (Impakt→Diagnostika→Deystviya→Sled. apdate), les canaux et les fréquences.
7. Retour/folback : backout clair, limites et indicateur de dégradation UX.
8. Critères d'achèvement : métriques, fenêtres temporelles d'observation.
9. Evidence : quoi enregistrer (logs, graphiques, captures d'écran, ID de tickets).
10. Historique des changements : changelog, restrictions connues.

4) Taxonomie des playbooks (exemple de catalogue)

INC- - incidents (SLO/SLI, fournisseurs, infrastructure).
REL- - sorties, rebonds, configis/drapeaux.
MW- - fenêtres de service (DB/queue/cert/OS).
SEC- - sécurité (accès, clés, activités suspectes).
DATA- - fraîcheur/qualité/schémas.
PROV- - fournisseurs externes (PSP/KYC/CDN/Email/SMS).

5) Cycle de vie et possession

1. Initiation : d'après les résultats de l'incident/simulation/modification.
2. Brouillon : auteur = propriétaire du service ; revu : SRE/security/data (par domaine).
3. Pilote : tabletop/game-day ; fixation du temps de passage et des défauts.
4. Publication : dans repo (Docs-as-Code), version, tags, liens vers les dashboards.
5. Actualisation : par RCA/CAPA, au moins une fois par trimestre ; SLA de fraîcheur.
6. Archive/Dépréciation : en cas de remplacement/perte de pertinence.

6) Intégration avec les outils

Alert → Playbook : Chaque règle de page fait référence à exactement un playbook de base.
ChatOps : '/play start <id> 'ouvre la carte, enregistre l'evidence, met les minuteries de l'update.
CMDB/annuaire : le service a une liste de pleybooks pertinents, propriétaires, SLO, dashboards.
GitOps : playbooks et runbook 'et vivent à Git, passent la rhubarbe PR et les linters.

7) Métriques de qualité des playbooks

Activability : ≥ 90 % des lancements donnent lieu à des actions concrètes sans escalade « par ignorance ».
Time-to-first-action : minute ou deux de Page à la première étape significative.
Coverage :% des alertes de page ayant un pleybook lié (objectif 100 %).
Freshness : la proportion de playbooks est fraîche 90 jours.
Taux de défaut : remarques sur les rhubarbes/simulations pour 100 pleybuks.
Reuse : Combien de fois le playbook a-t-il été réellement appliqué (et à quels résultats).

8) Anti-modèles

« Pleybuk-encyclopédie » de 20 pages sans arbre de décision.
Commandes sans attentes de résultats (« exécuter X » - qu'est-ce qui doit changer ?).
Il n'y a pas de plan et de limites - le risque d'escalade du problème.
Les canaux/intervalles de communication ne sont pas indiqués - augmentation des risques de RP.
Pleybuk sans propriétaire/date de mise à jour - personne ne croit en sa pertinence.
Des dizaines de playbooks similaires au lieu d'un paramétrable.

9) Mini modèle de playbook (idée YAML)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Exemples finis (fragments)

A) Paiements : « Le fournisseur se dégrade dans une région »

Symptômes : diminution de la success_ratio de la cohorte TR, augmentation du délai PSP-A.
Solutions : réduire le poids du PSP-A pour le TR, inclure le degrade-UX, renforcer les retraits avec le budget du SLA ≤, préparer l'update client.
Backout : Retour de poids sous SLI vert 60 minutes.

B) OBD : « Croissance p99 et connection errors »

Symptômes : p99↑, erreurs de connexion reset, croissance des événements wait.
Solutions : activer les scripts read-only, limiter la charge de write, mettre à l'échelle le pool/réplica, si nécessaire, un failover chaud.
Backout : Retour en arrière des paramètres, réplique prime.

C) Cache : « Taux de Miss ↑ charge → sur la base de données »

Symptômes : taux de miss> 40 %, augmentation de l'UPC OBD.
Solutions : équilibrer la politique d'évocation, augmenter la mémoire/sharding, activer temporairement read-through, limiter le RPS sur les clés chaudes.
Backout : revenir à la politique, recréer un shard problématique.

D) CDN : « Dégradation régionale des contenus »

Symptômes : augmentation de latency/timeout dans un pays, plaintes RUM.
Solutions : modifier la carte routing/GSLB, contourner les POP problématiques, réduire la TTL, activer l'origin-shield.
Comms : État-update avec géographie de l'influence.

E) KYC : « Échec des identifications »

Symptômes : baisse du taux d'approbation, croissance de la vendor_error.
Solutions : passer une partie du trafic à un fournisseur alternatif, réduire la rigueur des règles (dans le cadre de la politique), lancer une révision manuelle pour VIP.
Conformité : journal de toutes les modifications, notifications Risk/Legal si nécessaire.

11) Communications (modèle d'update)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Chèque de l'auteur du playbook

• L'objectif, les propriétaires, les SLO/SLI et les déclencheurs sont indiqués.
• Il y a un tableau « Symptômes ↔ Hypothèses » et un arbre de décision.
• Étapes réalisables avec les résultats attendus et les jeux de sécurité.
• Backout/fallback et conditions de retour sont prescrites.
• Modèle de communication et fréquence d'update.
• Liens vers dashboards/alerts/logs-search/tracks.
• Section obligatoire evidence et critères d'achèvement.
• Version, date, SLA de fraîcheur, historique des changements.

13) Chèque-feuille revueur

• Pleybuk est joué sur tabletop/game-day.
• Les étapes sont sûres (limites/canari/auto-back), les secrets ne sont pas révélés.
• Les rôles et l'escalade sont clairs ; IC/Comms sont indiqués.
• Il n'y a pas de chevauchement avec les pleybooks voisins ; les paramètres ont été avancés.
• Il est clair quand arrêter et aller à fallback/rollback.
• Le document est disponible en 1 clic.

14) Paramétrage et surutilisation

Déduire les variables (région, fournisseur, seuils) dans 'values.'.
Les étapes générales (par exemple, « réduire le poids du fournisseur », « activer degrade-UX ») sont formalisées par des runbook 'ami distincts.
Supportez les générateurs des modèles : 'plb new --type = INC --service = payments'.

15) Feuille de route pour la mise en œuvre (4-6 semaines)

1. L'inventaire des alertes de page → comparer chaque pleybuck de base.
2. Modèles : approuver la structure YAML/Markdown, les chèques-feuilles et les linters.
3. Les 5 meilleurs scénarios (paiements/OBD/CDN/KYC/cache) → écrire/reculer sur tabletop.
4. Intégration : liens d'alerts, commandes ChatOps, evidence-bot.
5. Exercice : mini-drill hebdomadaire d'un pleybuk ; AAR→uluchsheniya.
6. SLA de fraîcheur et rhubarbe trimestriel ; rapport sur les métriques de qualité.

16) Résultat

Les playbooks sont des scripts opérationnels avec des fourches et des balustrades qui traduisent le chaos « et que faire ? » en une séquence prévisible de décisions. Lorsque les playbooks sont standardisés, intégrés aux alertes et régulièrement entraînés, l'équipe réagit plus rapidement, les risques sont contrôlés et l'entreprise voit la stabilité et la maturité de l'exploitation.