SOP:

Standardizarea procedurilor de operare

1) De ce aveți nevoie de ea

SOP este sistemul de operare al companiei. Standardizarea elimină haosul și „stilurile individuale”, reduce MTTR, alertează zgomotul și riscurile incidente, accelerează îmbarcarea și face rezultatele reproductibile.

• Reducerea variabilității acțiunilor în incidente și rutine.
• Accelerarea formării și îmbunătățirea calității handoverelor.
• Asigurați-procese auditabile: audit, măsurători, îmbunătățiri de date.
• Asigurarea respectării cerințelor de reglementare și interne.

2) Principii de standardizare

1. Format uniform și terminologie. O notație, o definiție (SLO, ETA, Owner).
2. Actionabil, nu o enciclopedie. Numai pași verificabili, criterii de succes și rollback.
3. Ramificare minimă. Clar dacă/apoi soluții în loc de freewheeling.
4. Versioning și proprietate. Fiecare POS are un proprietar, o versiune și o dată de revizuire.
5. Integrarea cu instrumente. Link-uri către tablouri de bord, bilete, ficheflags, comenzi CLI.
6. Disponibilitatea în timpul serviciului. Căutați rapid, citiți, executați cu un singur link.
7. Îmbunătățire continuă. Post-mortems → sarcini de actualizare SOP.

3) Cadrul SOP (șablon)

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

Declanșatoare: error_budget_burn> 4x 10m, api_p99> 1. 3 × valoarea iniţială 10m

• 1) Pauză canar în release-tool
• 2) Verificați panourile „Schimbarea siguranței” și „API p99”
• 3) Creați biletul REG- , specificați linia de bază/fereastra
• DoD: p99 ≤ 1. 1 × valoarea iniţială 15m,
• Rollback: dezactivați complet steagul, postmortem ≤72ch

SOP: PSP Provider Feilover

Declanşatoare: quota_usage>0. 9 SAU outbound_error_rate>2×baseline 5m

• 1) Activați rutarea PSP-Y (config/buton)
• 2) Verificați conversia depozitului și P95 PSP-Y
• 3) Adnotări pe grafice, actualizare în # incident-canal
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300ms 10m
• Rollback: 20% revenire parțială a traficului la stabilizarea PSP-X

12) Liste de verificare

Lista de verificare a pregătirii SOP:
Obiectivul și declanșatoarele sunt clare și măsurabile.
[] Există pași pentru comenzi/link-uri.
[] DoD/Rollback formulat.
[] Escaladările și contactele sunt relevante.
[] Metadatele sunt umplute (proprietar, versiune, last_review).
[] Link checker și CI validator trece.

Lista de verificare a aplicațiilor SOP (în incident):
[] SOP deschis de la Incident Manager/panel link.
[] Pașii sunt finalizate și rezultatele înregistrate.
[] DoD Atins/Nu - Verificat.
[] Acțiunile/neconcordanțele sunt înregistrate în bilet.
[] Actualizări SOP/îmbunătățiri create de sarcini (dacă este necesar).

13) Instruire și onboarding

Mini-cursuri privind POS-urile cheie (Plăți/Pariuri/Jocuri/KYC).
Shadow taxă cu utilizarea obligatorie a SOP în formare.
Săptămânal „Clinici SOP”: 30 de minute de analiză/îmbunătățire.
Simulări (zile de joc): dezvoltarea SOP-urilor DR și incidente.

14) SOP Change Management

RFC prin PR, etichete „minor/major/breaking”.
Modificări de rupere - cu instruire obligatorie și anunț.
Notificări automate către proprietarii de domenii și de gardă.
Separat „SOP-Release Notes” la sfârșitul fiecărei săptămâni.

15) Anti-modele

Forma liberă „după cum se dovedește” și diferite modele de comandă.
POS fără proprietar/revizie/data revizuirii.
Texte „enciclopedice” în loc de acțiuni pas cu pas.
Nu Rollback/DoD - nimic pentru a verifica succesul cu.
Link-uri rupte, „manual de la chat” comenzi, privat „secret” pași.
SOP invizibil se schimbă fără înregistrare sau antrenament.

16) 30/60/90 - plan de implementare

30 de zile:
Aprobați șablonul SOP și standardele minime.
Creați un depozit 'ops-sop/' (docs-as-code), activați linterele CI.
Digitizați 10-15 POS-uri critice (incidente/comunicate/furnizori).
Conectați managerul de incidente și panourile de vizibilitate la link-urile SOP.

60 de zile:
Acoperire Reach ≥ 70% pentru scenarii critice.
Lansați săptămânal „clinici SOP” și training-uri de gardă.
Adăugați căutare AI (RAG) prin SOP și TL; Carduri DR.
Introduceți SLA de revizuire (180 de zile) și raportați POS-urile scadente.

90 de zile:
Acoperire ≥ 90%, Rata de utilizare ≥ 70% din incidente.
Încorporați DoD/Rollback în toate SOP-urile, închideți legăturile rupte (0).
Legați KPI SOP la comanda OKR (MTTR, Schimbați rata de eșec).
Retro și înregistrați îmbunătățirile trimestrului următor.

17) ÎNTREBĂRI FRECVENTE

Î: Cu ce este SOP diferit de runbook?
R: POS - procedură standardizată (regulament „cum să”). Runbook - instrucțiuni detaliate pentru un anumit caz/serviciu. Adesea, POS se referă la una sau mai multe cărți de alergare.

Î: Câte detalii ar trebui să existe în POS?
R: Suficient pentru ca operatorul să efectueze acțiuni fără a „săpa” în chat. Tot ceea ce nu afectează acțiunea este în materiale de referință separate.

Î: Cum să mențineți relevanța?
A: revizii SLA (≤180 zile), memento-uri automate, lintere CI și metrici de utilizare/DoD. Orice incident de abatere → sarcina de actualizare SOP.