Standard Operating Procedures

1) Qu'est-ce qu'un SOP et pourquoi il est nécessaire

SOP (Standard Operating Procedure) est une séquence d'étapes formalisées et approuvées pour les opérations répétables avec entrées/sorties compréhensibles, rôles et critères de qualité.

• Réduction de la variabilité de l'exécution et des risques.
• Réduction de MTTA/MTR grâce à des actions prêtes à l'emploi.
• Conformité et audit : reproductibilité, tracabilité.
• Onbording : accélération de l'apprentissage et « shadow → solo ».

SOP ≠ Pleybook : Pleybook est un arbre de décision avec des bifurcations, SOP est un règlement linéaire pour un scénario particulier (ou une branche de pleybook).

2) Les principes du « bon » SOP

Outcome-Driven : focus sur les résultats (SLO/critères d'affaires), pas seulement sur les étapes.
Sans ambiguïté : commandes, paramètres, effets attendus et points de contrôle.
Sécurité par défaut : gates, limites, backout/rollback sont prescrits.
Minimum de contexte : notes courtes + liens vers un runbook/diagnostic détaillé.
Pertinence : date d'échéance, propriétaire, version, date d'expiration.
Exécutabilité : accès JIT/JEA, vérification des conditions préalables, modèles d'artefacts.

3) Structure SOP standard (squelette)

ID/Version/Review Date
Name and short purpose (what and why)
Scope (Services/Regions/Tenants, SEV/Risk)
Roles and Responsibilities (RACI: R/A/C/I)
Preconditions (accesses, windows, stage, reserve, artifacts)
Materials/tools (dashboards, feature flags, repos, keys)
Quality gates (SLO-gardrails, quorum of probes, alerts)
Step-by-step instruction (step → command → expected result → verification)
Branches (if X - perform Y) [minimum]
Backout/Rollback (start conditions, steps, verification)
Communications (who, when, where; message templates)
Evidence (what to save: screenshots, logs, chexums, links)
Completion (success criteria, watching who closes the ticket)
Change History (What, By Whom, and Why)

4) Catalogue SOP et propriété

Un référentiel unique (Docs-as-Code) avec les balises : 'domain/ops', 'service/checkout', 'risk/high', 'provider/psp-a'.
Carte de propriétaire : équipe, contacts de service, propriétaire de réserve.
L'ALS de la pertinence (par exemple, un examen tous les ≤90 jours ou après un incident/un communiqué).
Linter/Validateur SOP (CI) : vérification de la structure, des références, des propriétaires, de la durée de la jalousie.

5) Cycle de vie SOP

1. Initiation (après incident/exercice/nouveau processus).
2. Brouillon (auteur = propriétaire du service/processus).
3. Revew (SRE/Security/Legal/Comms - par domaine).
4. Pilote (tabletop/game day) : nous mesurons le temps, les découvertes → les modifications.
5. Publication (version, date, numéro, modèles dans le répertoire/service de la DGCM).
6. Application opérationnelle (annotations dans les tiquets/chats, collecte d'evidence).
7. Mise à jour (par RCA/CAPA, par date limite, par changement d'architecture).
8. Archivage/dépréciation (remplacé par le nouveau SOP/Pleybook).

6) Liens avec les artefacts voisins

Playbooks : SOP est une « branche linéaire » à l'intérieur du playbook ; lien des étapes.
Runbook 'et : détails techniques/scripts sortis dans runbook, SOP référence.
Politiques (Policy-as-Code) : Gets d'admission, de retraite, RBAC - références obligatoires.
SLO/SLI : critères de réussite et garde-rails.
Matrice d'escalade : rôles/temporisations lorsque l'exécution du SOP échoue.
Fenêtres de service : exigences de slot/Commons pour les SOP à risque élevé.

7) Métriques d'efficacité SOP

Time-to-Execute (médiane/p95) - combien prend la procédure.
Le taux de réussite est une proportion de performances réussies sans escalade/reculs.
Evidence Completeness - remplissage des artefacts.
SLO Impact - y a-t-il des dégradations pendant/après l'étape (burn-minute).
Defect Density - Remarques sur les rhumes/exercices sur 10 SOP.
Freshness est la proportion de SOP avec rhubarbe pendant ≤90 jours.
Adoption - Combien d'alerts/d'ocons sont vraiment liés au SOP.

8) Chèque de l'auteur de SOP

• Le but et les limites de l'application sont définis.
• Rôles, accès et fenêtres - décrits.
• Gates de qualité et SLO - mesurables, il y a des sources de signaux.
• Étapes exécutables : commandes/scripts, résultats attendus, vérification.
• Backout/rollback et critères de démarrage - clairement.
• Les modèles de com sont joints.
• Evidence-list est structuré.
• Version/date/propriétaire/rhubarbe indiqué.

9) Chèque d'artiste SOP

• Les conditions préalables et l'accès au JIT/JEA ont été confirmés.
• Le tiquet/war-room est ouvert et les annotations sont incluses.
• Observabilité : Les bons dashboards/alerts sont ouverts.
• Je fais des pas dans l'ordre ; après chacun, la vérification.
• En cas de violation des gardrails - backout immédiat et escalade.
• Evidence est plein ; Vérification finale de SLO/SLI d'entreprise.
• Tiquet fermé, page de statut/comms mis à jour.

10) Exemples de SOP (fragments)

10. 1 SOP : Canarian Release (REL-ROLLBACK-01)

The goal: to return the stable version when the burn-rate is exceeded or the p99 grows.
Scope: checkout-api service (prod, EU).
Roles: Release (R), IC (A in SEV-1), P1 (R), Comms (I).
Preconditions: feature flags are ready; JEA accesses; release-annotations included.
Gates: slo. payment_success, http_p99; quorum synthetic EU/US + RUM.
Steps:
1) Freeze unrelated depleys.
2) rollback to tag v2. 3. 7 (command...) → waiting 5 minutes.
I expect: p99↓, error_rate↓, burn-rate <threshold.
3) Business SLI check (payment success, conversion) 10 min.
4) Remove the suppression of alerts; update release annotation.
Backout: if rollback does not help - escalate to IC, enable degrade-UX, consider failover.
Comms: "Rolled back; metrics stabilize; next update in 15 minutes."
Evidence: before/after screenshots, link to dashboards, command and output.
Completion: 30 min green SLOs; close the ticket; assign an RCA (if SEV-1).
Version: 1. 6 (2025-10-28)

10. 2 SOP : Mise à niveau planifiée des OBD (MW-DB-UPGRADE-02)

Purpose: update PostgreSQL minor without data loss.
Area: payments-db (prod EU), 02: 00-04: 00 Europe/Kyiv.
Roles: DB Lead (R), SRE (C), Service Owner (A), Comms (R clients).
Preconditions: OK backups; replica in sync; Test upgrade passed.
Gates: lag≤30s, error_rate<0. 5%, p99 <400ms, SLO green 30m.
Steps:
1) Transfer traffic to canary replica 1%→5%→25%; SLI monitoring.
2) Consistently upgrade secondary nodes → switch over → upgrade of the former primary.
3) Restore replication, check consistency.
Backout: promote stable replica; return writer; rolling back packets.
Comms: T-7/-2 days and T-60/-15 min alert; updates q = 30m during the window.
Evidence: migration logs, checksums, p95/p99 graphs.
Completion: observation 60m without burn; MW report with evidence.
Version: 2. 1 (2025-09-12)

10. 3 SOP : Changement de fournisseur de PSP (PROV-PSP-SWITCH-01)

Objective: to maintain payment success_ratio in case of PSP-A degradation.
Trigger: PSP-A red/partial status + success_ratio% ≥2 drop.
Steps:
1) Install weights: PSP-A 30%, PSP-B 70%.
2) Turn on the degrade_payments_ux; enhance retrays (within SLA).
3) Monitor fraud_rate/chargeback-risk 30m.
Backout: Regain weights at green SLI 60m.
Comms: status page (first ≤15m, cadence 30m).

10. 4 SOP : Vérification de la récupération de backup (DATA-BACKUP-RESTORE-CHECK-03)

Objective: weekly verification of recoverability.
Steps: lift from backup in isolation → hash control → consistency requests → report.
Success criterion: time-to-restore ≤ 45 min; 100% integrity.

11) Automatisation autour de SOP

Modèle SOP : Génération de squelette avec RACI/Gates/Commm Block.
Bot Performer : étapes avec check-box, minuteries, rappels par cadence, auto-collecte evidence.
Intégration avec le CMDB/catalogue : le service a une liste de SOP pertinents.
Annotations de télémétrie : « SOP-RUN : <ID> step N » → analyse rapide.
Stratégies de tolérance : deploy/fenêtre ne démarre que sous les jeux SOP verts.

12) Anti-modèles

Un SOP sans propriétaire/date est un document « mort ».
Instructions gonflées sans critères de succès et backout.
Commandes/clés incohérentes - risque d'erreurs et de fuites.
Les différentes versions du wiki et du référentiel sont la divergence des sources de vérité.
Pas d'evidence - rien pour confirmer la qualité/conformité.
« Un SOP pour tous les cas » - l'exécutabilité est perdue.

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

1. Ned. 1 : approuver le modèle SOP, le linter et le catalogue ; choisir les 10 meilleurs scénarios.
2. Ned. 2 : écrire un SOP pour les sorties/recto/fournisseur/backup ; pilotes tabletop.
3. Ned. 3 : connecter le bot ChatOps et les annotations de télémétrie ; lier les alertes au SOP.
4. Ned. 4 : emploi du temps trimestriel ; entrez les métriques Freshness/Success Rate.
5. Ned. 5-6 : couvrir 90 % des opérations critiques ; DR/Security-SOP; automatiser la collecte d'evidence.

14) Résultat

Le SOP rend les opérations prévisibles et vérifiables : Gates de qualité uniques, étapes détaillées, rôles explicites et réversibilité. En liaison avec les pleybuks, les politiques, les SLO et l'automatisation, cela transforme l'exploitation en une ligne de production fiable - des réactions rapides, un risque minimum et une responsabilité compréhensible.