Proceduri de operare standard

1) Ce este POS și de ce este necesar

SOP (Procedura standard de operare) este o secvență formalizată, validată de pași pentru operațiuni repetabile cu intrări/ieșiri ușor de înțeles, roluri și criterii de calitate.

• Reduceți variabilitatea execuției și riscurile.
• Reducerea MTTA/MTTR prin acțiuni off-the-raft.
• Conformitate și audit: reproductibilitate, trasabilitate.
• Onboarding: accelerarea învățării și umbra → solo.

SOP ≠ playbook: playbook - arbore de decizie cu furci, SOP - reguli liniare pentru un anumit scenariu (sau ramură playbook).

2) Principii bune POS

Bazat pe rezultate: se concentreze pe rezultate (SLO/criterii de afaceri), nu doar pași.
Unambiguitate: comenzi, parametri, efecte așteptate și puncte de control.
Securitate în mod implicit: porțile, limitele, backout/rollback sunt înregistrate.
Context minim: note scurte + link-uri către cărți detaliate/diagnostic.
Relevanță: data revizuirii, proprietarul, versiunea, data expirării.
Executabilitate: Accesorii JIT/JEA, controale de precondiție, șabloane artefact.

3) Structura standard SOP (schelet)

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) Directorul SOP și proprietatea

Un singur depozit (Docs-as-Code) cu etichete: „domeniu/ops”, „serviciu/checkout”, „risc/ridicat”, „furnizor/psp-a”.
Card de proprietar: echipa, contacte de serviciu, proprietar de rezervă.
Relevanţa SLA (de ex. revizuire la fiecare ≤90 zile sau după incident/eliberare).
Linter/SOP validator (CI): verificarea structurii, link-uri, proprietari, perioada de revizuire.

5) Ciclul de viață al POS

1. Inițiere (după incident/burghiu/proces nou).
2. Draft (autor = proprietar de servicii/procese).
3. Recenzie (SRE/Security/Legal/Comms - pe domenii).
4. Pilot (zi de masă/joc): măsoară timpul, găsește modificări →.
5. Publicare (versiune, dată, număr, șabloane în catalogul CMDB/service).
6. Aplicație operațională (adnotări în bilete/chat-uri, colectarea probelor).
7. Actualizare (prin RCA/CAPA, pe termen limită de revizuire, prin modificări de arhitectură).
8. Arhivare/epuizare (înlocuit de un nou SOP/playbook).

6) Conexiuni cu artefacte vecine

Playbooks: SOP - „ramură liniară” în interiorul playbook; referință de la pași.
Runbook 'și: detalii tehnice/scripturi sunt plasate în runbook, SOP se referă.
Politici (Policy-as-Code): porti de acces, permisiuni, RBAC - link-uri obligatorii.
SLO/SLI: criterii de succes și garde-șine.
Matrice de escaladare: roluri/temporizări atunci când execuția SOP eșuează.
Ferestre de întreținere: cerințe de slot/virgulă pentru SOP cu risc ridicat.

7) măsurători de performanță SOP

Timp de executat (mediană/p95) - cât durează procedura.
Rata de succes - rata de succes fără escaladare/rollback.
Dovezi Completitudinea - plinătatea artefactelor.
SLO Impact - există orice degradare în timpul/după pas (arde-minute).
Defect densitate - Revizuire/Exercitarea Note la 10 SOPs.
Prospețimea este proporția de POS-uri cu o revizuire de ≤90 zile.
Adopție - câte alerte/ferestre sunt de fapt legate de POS.

8) Lista de verificare a autorului SOP

• Scopul și limitele aplicației definite.
• Roluri, accesări și ferestre - descrise.
• Porțile de calitate și SLO sunt măsurabile, există surse de semnal.
• Pași executabili: comenzi/scripturi, rezultate așteptate, verificare.
• Backout/rollback și criterii de lansare - clar.
• Șabloanele comunicațiilor sunt atașate.
• Lista de dovezi este structurată.
• Versiunea/data/proprietar/revizuire specificată.

9) Lista de verificare SOP

• JIT/JEA premisele și accesele confirmate.
• Biletul/camera de război este deschisă și adnotările sunt incluse.
• Observabilitate: tablourile de bord/alertele necesare sunt deschise.
• Urmez pașii în ordine; după fiecare - verificare.
• În caz de încălcare a gardrails - backout imediat și escaladarea.
• Dovezile sunt complete; verificare finală SLO/SLI de afaceri.
• Bilet închis, status page/comms actualizat.

10) Exemple POS (fragmente)

10. 1 SOP: Canare rollback de lansare (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 DB programat (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: Comutare furnizor 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: Verificarea recuperării de rezervă (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) Automatizarea în jurul SOPs

Șablon SOP: generare schelet cu RACI/porți/virgulă bloc.
Bot performer: pași cu casete de selectare, cronometre, memento-uri cadență, probe auto-colectare.
Integrarea cu CMDB/Catalog - Service are o listă de POS-uri relevante.
Adnotări telemetrice: „SOP-RUN: <ID> pasul N” → parsare rapidă.
Politici de admitere: Implementarea/fereastra începe numai cu porți verzi POS.

12) Anti-modele

SOP fără revizuirea proprietarului/datei - document „mort”.
Instrucțiuni umflate fără criterii de succes și backout.
Comenzi/chei inconsecvente - risc de erori și scurgeri.
Diferite versiuni în wiki și în depozit sunt o divergență a surselor de adevăr.
Nicio dovadă - nimic care să confirme calitatea/conformitatea.
„Un POS pentru toate cazurile” - executabilitatea este pierdută.

13) Foaie de parcurs de implementare (4-6 săptămâni)

1. Ned. 1: aprobați șablonul, linterul și catalogul SOP; selectați top 10 scenarii.
2. Ned. 2: scrieți SOP pentru versiuni/rollback/provider/backup-uri; piloţi de masă.
3. Ned. 3: conectați adnotările ChatOps bot și telemetrie; asociază alertele cu POS-urile.
4. Ned. 4: programul trimestrial de revizuire; introduceți valorile ratei de prospețime/succes.
5. Ned. 5-6: acoperă 90% din operațiunile critice; DR/Security-SOP; automatizează colectarea probelor.

14) Linia de jos

POS face operațiunile previzibile și verificabile: porți de calitate uniforme, pași detaliați, roluri explicite și reversibilitate. În combinație cu playbook-uri, politicieni, SLO și automatizare, acest lucru transformă operațiunea într-o linie de producție fiabilă - reacții rapide, risc minim și responsabilitate ușor de înțeles.