SOP:

Standaryzacja procedur operacyjnych

1) Dlaczego go potrzebujesz

Normalizacja usuwa chaos i „indywidualne style”, zmniejsza MTTR, alarmuje hałas i ryzyko incydentów, przyspiesza wejście na pokład i umożliwia odtwarzanie wyników.

• Zmniejszenie zmienności działań w incydentach i rutynach.
• Przyspieszyć trening i poprawić jakość uchwytów.
• Sprawdź procesy: audyt, mierniki, ulepszenia danych.
• Zapewnienie zgodności z wymogami regulacyjnymi i wewnętrznymi.

2) Zasady normalizacji

1. Jednolity format i terminologia. Jedna notacja, jedna definicja (SLO, ETA, właściciel).
2. Czynna, nie encyklopedia. Tylko weryfikowalne kroki, kryteria sukcesu i zwrot.
3. Minimalne rozgałęzienie. Wyczyść jeśli/następnie rozwiązania zamiast freewheeling.
4. Wersioning i własność. Każdy SOP ma właściciela, wersję i datę wersji.
5. Integracja z narzędziami. Linki do desek rozdzielczych, biletów, ficheflagów, poleceń CLI.
6. Dostępność w dyżurze. Szybko wyszukaj, przeczytaj, wykonaj jednym linkiem.
7. Ciągła poprawa. Pośmiertne → zadania aktualizacji SOP.

3) Ramy SOP (szablon)

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

Wyzwalacze: error_budget_burn> 4x 10m, api_p99> 1. 3 × wartość wyjściowa 10 m

• 1) Pauza kanarka w narzędzie uwolnienia
• 2) Panele kontrolne „Zmiana bezpieczeństwa” i „API p99”
• 3) Utwórz bilet REG- , określ linię bazową/okno
• DoD: p99 ≤ 1. 1 × wartość wyjściowa 15m,
• Rollback: wyłączyć flagę całkowicie, postmortem ≤ 72ch

SOP: PSP Provider Feilover

Wyzwalacze: quota_usage>0. 9 LUB outbound_error_rate>2×baseline 5m

• 1) Włącz routing PSP-Y (config/przycisk)
• 2) Sprawdź konwersję depozytu i p95 PSP-Y
• 3) Adnotacje na wykresach, aktualizacja w # incydent-kanał
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300 ms 10 m
• Rollback: 20% częściowy zwrot ruchu przy stabilizacji PSP-X

12) Listy kontrolne

Lista kontrolna gotowości SOP:
[] Cel i wyzwalacze są jasne i wymierne.
[] Istnieją kroki dla poleceń/linków.
[] Formuła DoD/Rollback.
[] Istotne są eskalacje i kontakty.
[] Metadane są wypełnione (właściciel, wersja last_review).
[] Link checker i CI validator pass.

Lista kontrolna aplikacji SOP (w incydencie):
[] SOP otwarte z Incydent Manager/panel link.
[] Etapy są zakończone i wyniki rejestrowane.
[] DoD Reached/Not - Checked.
[] Działania/niespójności są zapisywane w bilecie.
[] Aktualizacje/ulepszenia SOP stworzone przez zadania (w razie potrzeby).

13) Szkolenie i wejście na pokład

Mini-kursy na kluczowych SOP (Płatności/Zakłady/Gry/KYC).
Obowiązek cienia z obowiązkowym wykorzystaniem SOP w szkoleniu.
Tygodniowa „klinika SOP”: 30 minut analizy/poprawy.
Symulacje (gra-dni): rozwój DR i incydentów SOP.

14) Zarządzanie zmianą SOP

RFC poprzez PR, znaczniki „minor/major/breaking”.
Przełamanie zmian - z obowiązkowym treningiem i ogłoszeniem.
Automatyczne powiadomienia do właścicieli domeny i dyżurów.
Oddzielne „SOP-Release Notes” na koniec każdego tygodnia.

15) Anty-wzory

Wolna forma „jak się okazuje” i różne wzory przez polecenie.
SOP bez właściciela/zmiany/zmiany daty.
Teksty „encyklopedyczne” zamiast działań krok po kroku.
Brak Rollback/DoD - nic do sprawdzenia sukcesu.
Złamane linki, „instrukcja z czatu” polecenia, prywatne „tajne” kroki.
Niewidoczne zmiany SOP bez nagrywania lub szkolenia.

16) 30/60/90 - plan realizacji

30 dni:
Zatwierdzaj szablon SOP i minimalne standardy.
Utwórz repozytorium 'ops-sop/' (docs-as-code), włącz lintery CI.
Digitalizacja 10-15 krytycznych SOP (incydenty/wydania/dostawcy).
Podłącz Menedżer incydentów i panele widoczności do łączy SOP.

60 dni:
Zasięg zasięgu ≥ 70% dla scenariuszy krytycznych.
Uruchom cotygodniowe „kliniki SOP” i szkolenia dyżurne.
Dodaj wyszukiwanie AI (RAG) przez SOP i TL; Karty DR.
Wprowadź przegląd SLA (180 dni) i zgłosić przeszłość należnych SOP.

90 dni:
Zasięg ≥ 90%, Wskaźnik użycia ≥ 70% incydentów.
Wbudować DoD/Rollback we wszystkich operacjach SOP, zamknąć złamane linki (0).
Powiązanie SOP KPI z poleceniem OKR (MTTR, Change Failure Rate).
Retro i rekord kolejnych ulepszeń kwartału.

17) FAQ

P: Jak SOP różni się od runbooka?
Odp.: SOP - standardowa procedura (regulacja „jak”). Runbook - szczegółowe instrukcje dotyczące konkretnego przypadku/usługi. Często SOP odnosi się do jednego lub kilku książek startowych.

P: Ile szczegółów powinno być w SOP?
Odp.: Wystarczy, aby operator wykonywał czynności bez „kopania” w czacie. Wszystko, co nie wpływa na działanie, znajduje się w oddzielnych materiałach referencyjnych.

P: Jak zachować znaczenie?
Odp.: korekty SLA (≤ 180 dni), automatyczne przypomnienia, lintery CI i mierniki użycia/DoD. Każdy incydent odchylenia → zadanie aktualizacji SOP.