SOP: <коротка дія/мета>

Стандартизація операційних процедур

1) Навіщо це потрібно

SOP - це «операційна ОС» компанії. Стандартизація прибирає хаос і «індивідуальні стилі», знижує MTTR, шум алертів і ризики інцидентів, прискорює онбординг і робить результати відтвореними.

• Знизити варіативність дій при інцидентах і рутинах.
• Прискорити навчання і підвищити якість хендоверів.
• Зробити процеси перевіреними: аудит, метрики, поліпшення за даними.
• Забезпечити відповідність регуляторним та внутрішнім вимогам.

2) Принципи стандартизації

1. Єдиний формат і термінологія. Одна нотація, одні визначення (SLO, ETA, Owner).
2. Actionable, не енциклопедія. Тільки перевіряються кроки, критерії успіху і відкату.
3. Мінімальне розгалуження. Чіткі рішення «якщо/то» замість вільного викладу.
4. Версіонування та володіння. У кожного SOP є власник, версія і дата ревізії.
5. Інтеграція з інструментами. Посилання на дашборди, тікети, фічефлаги, команди CLI.
6. Доступність в он-коллі. Швидко пошукати, прочитати, виконати одним посиланням.
7. Безперервне поліпшення. Постмортеми → завдання на оновлення SOP.

3) Каркас SOP (шаблон)

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) Pause canary в release-tool (посилання)
• 2) Перевірити панелі «Change Safety» і «API p99»
• 3) Створити тікет REG- , вказати baseline/вікно
• DoD: p99 ≤ 1. 1 × baseline 15m, помилок
• Rollback: повне відключення прапора, постмортем ≤72ch

SOP: PSP Provider Feilover

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

• 1) Включити роутинг PSP-Y (конфіг/кнопка)
• 2) Перевірити конверсію депозитів і p95 PSP-Y
• 3) Анотації на графіках, апдейт в #incident -channel
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300мс 10м
• Rollback: часткове повернення трафіку 20% при стабілізації PSP-X

12) Чек-листи

Чек-лист готовності SOP:
[] Мета і тригери зрозумілі і вимірні.
[] Є покрокові дії з командами/посиланнями.
[] DoD/Rollback сформульовані.
[] Ескалації та контакти актуальні.
Метадані заповнені (owner, version, last_review).
[] Лінк-чекер і валідатор CI проходять.

Чек-лист застосування SOP (в інциденті):
[] SOP відкритий з Incident Manager/посилання на панелі.
[] Виконані кроки і зафіксовані результати.
[] DoD досягнутий/ні - зазначено.
[] Дії/невідповідності записані в тікеті.
[] Оновлення/поліпшення SOP створені завданнями (якщо знадобилися).

13) Навчання та онбординг

Міні-курси за ключовими SOP (Payments/Bets/Games/KYC).
Shadow-чергування з обов'язковим застосуванням SOP на тренуваннях.
Щотижневі «SOP-клініки»: 30 хвилин розборів/поліпшень.
Симуляції (game-days): відпрацювання DR- і інцидентних SOP.

14) Управління змінами SOP

RFC через PR, теги'minor/major/breaking'.
Breaking-зміни - з обов'язковим навчанням і анонсом.
Авто-повідомлення власникам доменів і он-колу.
Окремий «SOP-Release Notes» в кінці кожного тижня.

15) Анти-патерни

Вільна форма «як вийде» і різні шаблони по командах.
SOP без власника/версії/дати ревізії.
«Енциклопедичні» тексти замість покрокових дій.
Немає Rollback/DoD - немає чим перевіряти успіх.
Биті посилання, команди «вручну з чату», приватні «секретні» кроки.
Невидимі зміни SOP без запису та навчання.

16) 30/60/90 - план впровадження

30 днів:
Затвердити шаблон SOP і мінімальні стандарти.
Створити репозиторій'ops-sop/' (docs-as-code), включити CI-лінтери.
Оцифрувати 10-15 критичних SOP (інциденти/релізи/провайдери).
Підключити Incident Manager і панелі спостережуваності до посилань SOP.

60 днів:
Досягти Coverage ≥ 70% за критичними сценаріями.
Запустити щотижневі «SOP-клініки» і тренінги он-колла.
Додати AI-пошук (RAG) по SOP і TL; DR картки.
Ввести Review SLA (180 днів) і звітність за простроченими SOP.

90 днів:
Coverage ≥ 90%, Usage Rate ≥ 70% інцидентів.
Вбудувати DoD/Rollback у всі SOP, закрити биті посилання (0).
Прив'язати KPI SOP до OKR команд (MTTR, Change Failure Rate).
Провести ретро і зафіксувати поліпшення наступного кварталу.

17) FAQ

Q: Чим SOP відрізняється від runbook?
A: SOP - стандартизована процедура (регламент «як правильно»). Runbook - деталізовані інструкції для конкретного кейса/сервісу. Часто SOP посилається на один або кілька runbook.

Q: Скільки деталей повинно бути в SOP?
A: Рівно стільки, щоб оператор зміг виконати дії без «докопування» в чат. Все, що не впливає на дію - в окремі довідкові матеріали.

Q: Як підтримувати актуальність?
A: SLA ревізії (≤180 днів), автоматичні нагадування, CI-лінтери і метрика Usage/DoD. Будь-який інцидент з відхиленнями → завдання на оновлення SOP.