SOP :

Uniformisation des procédures opérationnelles

1) Pourquoi est-ce nécessaire

SOP est le « système d'exploitation » de la société. La standardisation élimine le chaos et les « styles individuels », réduit le MTTR, le bruit des alertes et les risques d'incidents, accélère l'onbording et rend les résultats reproductibles.

• Réduire la variabilité des actions en cas d'incident et de routine.
• Accélérer la formation et améliorer la qualité des handovers.
• Rendre les processus vérifiables : audit, métriques, améliorations selon les données.
• Assurer la conformité aux exigences réglementaires et internes.

2) Principes de normalisation

1. Format et terminologie uniques. Une notation, une définition (SLO, ETA, Owner).
2. Actionable, pas encyclopédie. Seulement les étapes vérifiables, les critères de succès et de retour.
3. Branche minimale. Des décisions claires « si/si » au lieu d'une déclaration libre.
4. Versioning et possession. Chaque SOP a un propriétaire, une version et une date de révision.
5. Intégration avec les outils. Liens vers dashboards, tiquets, ficheflags, commandes CLI.
6. Accessibilité en on-coll. Cherchez, lisez, exécutez rapidement avec un seul lien.
7. Amélioration continue. Les post-mortems → les tâches de mise à jour SOP.

3) Cadre SOP (modèle)

4) SOP classification

Incident: P1/P2 (critical), P3 (important).
Operational routines: releases, feature flags, database migrations, provider failover.
DR/BCP: disabling the region, restoring from backup, working offline.
Quality control/audit: revisions, readiness questionnaires, access.
Security/compliance: KYC/AML checks, log storage, privacy.

5) RACI: Ownership and Responsibility

Process    R (performer)    A (responsible)    C (consultant)    I (notify)
------------------------      ---------------      -----------------      ---------------      -------------
Create/Update SOP     Domain Owner       Head of Ops         SRE/Compliance      Teams
SLA Revision     Ops Enablement      Head of Ops        Domain leads     All
Use in an incident     On-call          Incident Manager      Domain Owner       Stakeholders

6) SOP lifecycle

1. Initiation: need from post-mortem/incident/audit.
2. Draft: by template, with specific artifacts and commands.
3. Review: Domain Owner + Head of Ops + specialized consultants.
4. Publishing: to portal/repository; annotations on dashboards.
5. Training: short training/screencast, knowledge test.
6. Application: recorded in ticket/incident.
7. Audit: by SLA revision or after a significant event.
8. Archiving: mark 'deprecated', indicate replacement.

7) Documentation as code (minimum standard)

We store SOP in Git (Markdown + YAML metadata), PR review, CI-lint.
Required fields are 'owner', 'version', 'last _ review', 'sla _ review'.
Link checker and structure validator in CI; auto-release portal after merge.
Significant changes - through changelog and notifications in the # ops channel.

8) SOP integrations

Incident Manager: Open SOP button when creating/escalating an incident.
Grafana/Observability: references from panels to relevant SOPs; release annotations.
Feature Flags/Release: canary step templates, SLO gates, rollback.
AI assistant: RAG search by SOP, TL; DR and proposals for action.
BCP/DR: DR-playbook automatically loaded by trigger.

9) SOP quality check (KPI and review)

KPI:
Coverage ≥ 90% of critical scenarios are closed by SOP.
Review SLA ≤ 180 days (share of overdue - 0).
Usage Rate ≥ 70% of overt SOP incidents.
DoD Pass Rate ≥ 90% of steps are closed with success criteria.
Broken Links = 0 (по CI).

Weekly monitoring:
Top 5 used and top 5 obsolete SOPs.
SOP communication ↔ postmortems: whether Preventive Actions have been performed.
Noisy SOPs (frequent rollback returns) are candidates for recycling.

10) Containment standards

Steps → specifics: commands/queries/parameters + expected effect in metric.
Time requirements: ETA for updates/next steps.
Escalation: clear matrix, contacts, backup channels.
Security: warnings, restrictions, PII/secrets - via vault/links.
Localization: in the on-call language (critical for distributed commands).

11) SOP examples (fragments)

SOP: Canary pause in SLO degradation

Triggers: error_budget_burn > 4x 10m, api_p99 > 1. 3×baseline 10m

• 1) Pause canary dans release-tool (lien)
• 2) Vérifier les panneaux « Changer la sécurité » et « API p99 »
• 3) Créer un tiquet REG- , spécifier baseline/fenêtre
• DoD: p99 ≤ 1. 1 × baseline 15m, erreurs
• Rollback : Désactivation totale du drapeau, post mortem ≤72ch

SOP: PSP Provider Feilover

Triggers: quota_usage>0. 9 OR outbound_error_rate>2×baseline 5m

• 1) Activer le routage PSP-Y (config/bouton)
• 2) Vérifier la conversion des dépôts et p95 PSP-Y
• 3) Annotations sur les graphiques, update dans # incident-channel
• DoD: success_rate ≥ 99. 5 %, p95 ≤ 300ms 10m
• Rollback : retour partiel du trafic de 20 % lors de la stabilisation de la PSP-X

12) Chèques-feuilles

Chèque de disponibilité SOP :
[] Le but et les déclencheurs sont compréhensibles et mesurables.
[] Il y a des actions étape par étape avec des commandes/liens.
[] DoD/Rollback sont formulés.
[] Les escalade et les contacts sont pertinents.
[] Les métadonnées sont remplies (owner, version, last_review).
[] Link-checker et validateur CI passent.

Chèque d'application SOP (dans l'incident) :
[] Le SOP est ouvert à partir du gestionnaire d'incidents/liens dans les panneaux.
[] Les étapes ont été franchies et les résultats enregistrés.
[] DoD atteint/non - noté.
[] Les actions/incohérences sont consignées dans un tiquet.
[] Les mises à jour/améliorations de SOP ont été créées par des tâches (si nécessaire).

13) Formation et onbording

Mini-cours sur les SOP clés (Payments/Bets/Games/KYC).
Shadow-service avec l'application obligatoire du SOP à l'entraînement.
« Cliniques SOP » hebdomadaires : 30 minutes d'analyse/amélioration.
Simulations (jeux-jours) : travail sur les SOP DR- et incidents.

14) Gestion des changements de SOP

RFC via PR, étiquettes « minor/major/breaking ».
Breaking-change - avec formation et annonce obligatoires.
Auto-notifications aux propriétaires de domaines et il-colla.
Un « SOP-Release Notes » distinct à la fin de chaque semaine.

15) Anti-modèles

Forme libre « comment ça marche » et différents modèles par équipe.
SOP sans propriétaire/version/date de révision.
Textes « encyclopédiques » au lieu d'actions pas à pas.
Pas de Rollback/DoD - rien pour vérifier le succès.
Liens battus, commandes manuelles du chat, étapes privées « secrètes ».
Modifications SOP invisibles sans enregistrement ni formation.

16) 30/60/90 - plan de mise en œuvre

30 jours :
Approuver le modèle SOP et les normes minimales.
Créer le référentiel 'ops-sop/' (docs-as-code), activer les linters CI.
Numériser 10-15 SOP critiques (incidents/sorties/fournisseurs).
Connecter le gestionnaire d'incidents et les panneaux d'observation aux liens SOP.

60 jours :
Atteindre Coverage ≥ 70 % dans des scénarios critiques.
Lancez les « cliniques SOP » hebdomadaires et les formations il-colla.
Ajouter une recherche AI (RAG) par SOP et TL ; DR de la carte.
Entrez la Revue SLA (180 jours) et la déclaration des SOP en retard.

90 jours :
Coverage ≥ 90 %, taux d'utilisation ≥ 70 % des incidents.
Intégrer DoD/Rollback dans tous les SOP, fermer les liens battus (0).
Lier le KPI SOP aux commandes OKR (MTTR, Change Failure Rate).
Faire rétro et enregistrer les améliorations du prochain trimestre.

17) FAQ

Q : En quoi le SOP diffère-t-il du runbook ?
R : Le SOP est une procédure normalisée (règlement « comme il convient »). Runbook - instructions détaillées pour un cas/service particulier. SOP fait souvent référence à un ou plusieurs runbook.

Q : Combien de pièces doit être dans le SOP ?
R : Exactement pour que l'opérateur puisse effectuer des actions sans « fouiller » dans le chat. Tout ce qui n'affecte pas l'action est dans des documents de référence distincts.

Q : Comment maintenir la pertinence ?
R : Révisions SLA (≤180 jours), rappels automatiques, linters CI et métriques Utilisation/DoD. Tout incident de rejet → une tâche de mise à jour SOP.