SOP

Standardizzazione delle procedure operative

1) Perché è necessario

Il sistema operativo SOP è un sistema operativo aziendale. La standardizzazione elimina il caos e gli stili individuali, riduce l'MTTR, il rumore degli alert e i rischi di incidenti, accelera l'onboarding e rende i risultati riproducibili.

• Ridurre la variabilità degli incidenti e delle routine.
• Accelerare la formazione e migliorare la qualità degli hendover.
• Rendi i processi verificabili: controllo, metriche, miglioramenti dei dati.
• Garantire la conformità ai requisiti regolatori e interni.

2) Principi di standardizzazione

1. Formato e terminologia unificati. Una notazione, singole definizioni (SLO, ETA, Owner).
2. Actionable, non l'enciclopedia. Solo passaggi verificabili, criteri di successo e ripristino.
3. Ramificazione minima. Soluzioni chiare, invece di parlare liberamente.
4. Versioning e possesso. Ogni SOP ha il proprietario, la versione e la data di revisione.
5. Integrazione con gli strumenti. Riferimenti a dashboard, ticket, ficcoflagi, comandi CLI.
6. Disponibilità all'interno del Colle. Cercare, leggere, eseguire rapidamente un collegamento.
7. Miglioramento continuo. Postmortem per l'aggiornamento di SOP.

3) Ossatura SOP (modello)

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) Pausa canary in release-tool (riferimento)
• 2) Controlla i pannelli «Change Safety» e «API p99»
• 3) Crea ticket REG- , specifica baseline/finestra
• DoD: p99 ≤ 1. 1 x baseline 15m, errori
• Rollback, disattivazione totale della bandiera

SOP: PSP Provider Feilover

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

• 1) Abilita routing PSP-Y (config/pulsante)
• 2) Controllare la conversione dei depositi e p95 PSP-Y
• 3) Annotazioni su grafici, apdate in # incident-channel
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300ms 10m
• Rollback: ritorno parziale del traffico del 20% con stabilizzazione PSP-X

12) Assegno fogli

Assegno foglio pronto SOP:
[] Obiettivo e trigger sono chiari e misurabili.
[] Ci sono azioni passo passo con comandi/collegamenti.
[] Le DoD/Rollback sono state formulate.
[] Le escalation e i contatti sono rilevanti.
[] Metadati completati (owner, variante, last _ review).
[] Il checker Link e il validatore CI passano.

Assegno foglio di applicazione SOP (in caso di incidente):
[] SOP è aperto da Incident Manager/Link ai pannelli.
[] Passi completati e risultati registrati.
[] DoD raggiunto/no - contrassegnato.
[] Le azioni/incongruenze sono scritte nel ticket.
[] Gli aggiornamenti/miglioramenti SOP sono stati creati da operazioni (se necessario).

13) Formazione e onboarding

Mini-corsi SOP chiave (Payments/Bets/Games/KYC).
Servizio Shadow con uso obbligatorio di SOP in allenamento.
Cliniche SOP settimanali: 30 minuti di analisi/miglioramento.
Simulazioni (game-days) - Consente di eseguire lo screening delle SOP DRR e degli incidenti.

14) Gestione delle modifiche SOP

RFC tramite PR, tag «minore/maggiore/breaking».
Modifiche breaking - con la formazione obbligatoria e l'annuncio.
Notifiche automatiche ai proprietari dei domini e al collet.
SOP-Release Note separato alla fine di ogni settimana.

15) Anti-pattern

Modulo libero «come funziona» e modelli diversi per comando.
SOP senza proprietario/versione/data di revisione.
I testi «enciclopedici» invece di fare passi avanti.
No, non c'è niente da verificare.
Collegamenti a bit, comandi manuali di chat, passaggi privati «segreti».
Modifiche non visibili alla SOP senza scrittura o formazione.

16) Piano di implementazione 30/60/90

30 giorni:
Approva modello SOP e standard minimi.
Crea un repository'ops-sop/' (docs-as-code), abilita i linter CI.
Digitalizzare 10-15 SOP critici (incidenti/release/provider).
Connettere Incident Manager e i dashboard di osservazione ai collegamenti SOP.

60 giorni:
Raggiungere Coverage per il 70% in scenari critici.
Avvia le «cliniche SOP» settimanali e i corsi di formazione.
Aggiungi ricerca AI per SOP e TL; Dott. schede.
Immettere Review SLA (180 giorni) e i report di SOP scaduti.

90 giorni:
Coverage  90%, Usage Rate 70% incidenti.
Inserisci il DoD/Rollback in tutte le SOP e chiudi i collegamenti a buca (0).
Aggancia KPI SOP ai comandi OKR (MTTR, Change Failure Rate).
Fare retromarcia e registrare i miglioramenti del prossimo trimestre.

17) FAQ

Q: Qual è la differenza tra SOP e runbook?
A: SOP - procedura standardizzata (regolamento «come è giusto»). Runbook - istruzioni dettagliate per una specifica valigetta/servizio. Spesso SOP fa riferimento a uno o più runbook.

Q: Quante parti devono essere presenti in SOP?
A: Esattamente il tempo che l'operatore può eseguire le azioni senza «finire» nella chat. Tutto ciò che non influisce sull'attività è nei singoli riferimenti.

Come mantenere l'attualità?
A: Revisioni SLA ( giorni), promemoria automatica, linter CI e metrica. Qualsiasi problema di deviazione richiede l'aggiornamento della SOP.