Standard Operating Procedures

1) Cos'è SOP e perché è necessario

SOP (Standard Operating Procesure) è una sequenza formalizzata e approvata di passaggi per le operazioni ripetute con input/uscite comprensibili, ruoli e criteri di qualità.

• Riduzione della variabilità dell'esecuzione e dei rischi.
• Riduzione di MTTA/MTTR grazie alle azioni pronte.
• Compilazione e verifica: riproduzione, tracciabilità.
• Apprendimento più veloce e «shadow → solo».

SOP playbook: playbook - struttura di soluzioni con bivio, SOP - regola lineare per lo script specifico (o ramo playbook).

2) Principi «buona» SOP

Outcome-Driven - Fuoco sul risultato (SLO/Criteri aziendali), non solo sui passaggi.
Precisione: comandi, parametri, effetti previsti e punti di controllo.
Protezione predefinita: gate, limiti, backout/rollback.
Minimo contesto: note brevi + collegamenti a runbook/diagnostica dettagliate.
Rilevanza data, proprietario, versione, scadenza.
Eseguibilità: disponibilità JIT/JEA, controlli preimpostati, modelli di artefatto.

3) Struttura SOP standard (scheletro)

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) Directory SOP e possesso

Un unico repository (Docs-as-Code) con i tag «domain/ops», «service/checkout», «risk/high», «provider/psp-a».
La scheda del proprietario è la squadra, i contatti di turno, il proprietario di riserva.
SLA rilevante (ad esempio, revisione ogni ≤90 giorni o dopo un incidente/rilascio).
Linter/Validatore SOP (CI) - Controlla la struttura, i collegamenti, i proprietari, la durata della gelosia.

5) Ciclo di vita SOP

1. Avvia (dopo un incidente/esercitazione/nuovo processo).
2. Bozza (autore = proprietario del servizio/processo).
3. Ruota (SRE/Security/Legale/Comms - per dominio).
4. Pilota (tabletop/game day) - Misuriamo il tempo, le scoperte e le modifiche.
5. Pubblicazione (versione, data, numero, modelli in CMDB/directory del servizio).
6. Applicazioni operative (annotazioni in ticket/chat, raccolta evidence).
7. Aggiornamento (RCA/CAPE, RCA, RAVA, Architettura modificata).
8. Backup/deprecazione (sostituito da un nuovo socket SOP/playbook).

6) Collegamenti con manufatti adiacenti

Playbook: SOP - «ramo lineare» all'interno del playbook; Riferimento dei passaggi.
Runbook e: dettagli tecnici/script sono riportati in runbook, SOP fa riferimento.
Criteri (Policy-as-Code) - Gate di tolleranza, retenze, RBAC - Riferimenti obbligatori.
SLO/SLI: criteri di successo e garde-rails.
Matrice di scalate: ruoli/timing in caso di errore dell'esecuzione della SOP.
Finestre di servizio: requisiti slot/command per high-risk SOP.

7) Metriche di efficienza SOP

Time-to-Execute (mediana/p95) - Quanto richiede la procedura.
Success Rate è la percentuale di esecuzione riuscita senza scalare o ripristinare.
Evidence Completeness è il riempimento degli artefatti.
IMPATTO SLO - Se c'è degrado durante/dopo il passo (burn-minuto).
Defect Density - Osservazioni su 10 SOP durante la gelosia/esercitazione.
Freshness è una quota di SOP con ≤90 giorni di gelosia.
Adoption - Quanti alert/finestre sono realmente collegati alla SOP.

8) Foglio di assegno dell'autore di SOP

• Gli obiettivi e i limiti dell'applicazione sono definiti.
• Ruoli, accessibili e finestre - Descritto.
• Gate di qualità e SLO - misurabili, ci sono fonti di segnale.
• I passaggi sono eseguibili: comandi/script, risultati attesi, verifiche.
• Backout/rollback e criteri di avvio sono chiari.
• I modelli comm sono allegati.
• L'elenco Evidence è strutturato.
• Versione/data/proprietario/gelosia specificata.

9) Foglio di assegno esecutore SOP

• Preimpostazioni e disponibilità JIT/JEA confermate.
• Ticket/war-room aperto e annotazioni attivate.
• Osservabilità: i dashboard/alert giusti sono aperti.
• Eseguire le operazioni in ordine; Dopo ognuno, la verifica.
• In caso di violazione dei gardreil - backout immediato e escalation.
• L'evidenza è piena; Controllo finale SLO/Business SLI.
• Ticket chiuso, stato pagina/comms aggiornato.

10) Esempi di SOP (sezioni)

10. 1 SOP (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 UPGRADE pianificato (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 - Commutazione del provider 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 (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) Automazione intorno a SOP

Modello SOP: generazione di scheletro con RACI/gate/comm-block.
Bot performer: passaggi con assegno box, timer, promemoria cadence, raccolta automatica evidence.
Integrazione con CMDB/directory: il servizio dispone di un elenco di SOP rilevanti.
Annotazioni di telemetria: «SOP-RUN: <ID> step N» consente l'analisi rapida.
Criteri di tolleranza: il deposito/finestra viene avviato solo con gate verdi SOP.

12) Anti-pattern

SOP senza proprietario/data è un documento «morto».
Istruzioni gonfiate senza criteri di successo e backout.
Comandi/chiavi incoerenti - Rischio di errori e fughe.
Versioni diverse in wiki e nel repository - la differenza tra le origini della verità.
No evidence - non c'è niente da confermare qualità/compilation.
«Una SOP per tutti i casi» - Si perde l'esecuzione.

13) Road map di implementazione (4-6 settimane)

1. Ned. 1: approvare il modello SOP, il linter e la directory Selezionare i primi 10 script.
2. Ned. 2: scrivere SOP per rilasci/rimborsi/provider/backup; piloti tabletop.
3. Ned. 3: collegare ChatOps-bot e annotazioni di telemetria collegare gli alert alla SOP.
4. Ned. 4: grafico trimestrale geloso; immettere le metriche Freshness/Success Rate.
5. Ned. 5-6 - Coprire il 90% delle operazioni critiche; DR/Security-SOP; automatizzare la raccolta di evidence.

14) Totale

SOP rende le operazioni prevedibili e verificabili: gate di qualità unificate, passi dettagliati, ruoli espliciti e reversibilità. In associazione con playbook, regole, SLO e automazione, questo trasforma l'operatività in una linea di produzione affidabile: reazioni rapide, rischi minimi e responsabilità comprensibili.