Standard Operating Procedures

1) Що таке SOP і навіщо він потрібен

SOP (Standard Operating Procedure) - це формалізована, затверджена послідовність кроків для повторюваних операцій зі зрозумілими входами/виходами, ролями та критеріями якості.

• Зниження варіативності виконання і ризиків.
• Скорочення MTTA/MTTR за рахунок готових дій.
• Комплаєнс і аудит: відтворюваність, трасіруемость.
• Онбординг: прискорення навчання і «shadow → solo».

SOP ≠ плейбук: плейбук - дерево рішень з розвилками, SOP - лінійний регламент на конкретний сценарій (або гілку плейбука).

2) Принципи «хорошого» SOP

Outcome-Driven: фокус на результат (SLO/бізнес-критерії), не тільки на кроках.
Однозначність: команди, параметри, очікувані ефекти та точки контролю.
Типова безпека: гейти, ліміти, backout/rollback прописані.
Мінімум контексту: короткі примітки + посилання на докладні runbook/діагностику.
Актуальність: дата рев'ю, власник, версія, термін дії.
Здійсненність: доступи JIT/JEA, перевірки передумов, шаблони артефактів.

3) Стандартна структура SOP (скелет)

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) Каталог SOP і володіння

Єдиний репозиторій (Docs-as-Code) з тегами: `domain/ops`, `service/checkout`, `risk/high`, `provider/psp-a`.
Картка власника: команда, чергові контакти, резервний власник.
SLA актуальності (наприклад, перегляд кожні ≤90 днів або після інциденту/релізу).
Лінтер/валідатор SOP (CI): перевірка структури, посилань, власників, терміну рев'ю.

5) Життєвий цикл SOP

1. Ініціювання (після інциденту/навчання/нового процесу).
2. Чернетка (автор = власник сервісу/процесу).
3. Рев'ю (SRE/Security/Legal/Comms - по домену).
4. Пілот (tabletop/game day): вимірюємо час, знахідки → правки.
5. Публікація (версія, дата, номер, шаблони в CMDB/каталозі сервісу).
6. Операційне застосування (анотації в тікетах/чатах, збір evidence).
7. Оновлення (за RCA/CAPA, за терміном рев'ю, за змінами архітектури).
8. Архівація/депрекація (замінений новим SOP/плейбуком).

6) Зв'язки з сусідніми артефактами

Плейбуки: SOP - «лінійна гілка» всередині плейбука; посилання з кроків.
Runbook’и: технічні подробиці/скрипти винесені в runbook, SOP посилається.
Політики (Policy-as-Code): гейти допуску, ретенції, RBAC - обов'язкові посилання.
SLO/SLI: критерії успіху і garde-rails.
Матриця ескалацій: ролі/таймінги при збої виконання SOP.
Вікна обслуговування: вимоги до слоту/комам для high-risk SOP.

7) Метрики ефективності SOP

Time-to-Execute (медіана/р95) - скільки займає процедура.
Success Rate - частка успішних виконань без ескалації/відкату.
Evidence Completeness - заповненість артефактів.
SLO Impact - чи є деградації під час/після кроку (burn-хвилини).
Defect Density - зауваження при рев'ю/навчаннях на 10 SOP.
Freshness - частка SOP з рев'ю ≤90 днів.
Adoption - скільки алертів/віконів реально прив'язані до SOP.

8) Чек-лист автора SOP

• Мета і межі застосування визначені.
• Ролі, доступи та вікна - описані.
• Гейти якості і SLO - вимірні, є джерела сигналів.
• Кроки здійсненні: команди/скрипти, очікувані результати, верифікація.
• Backout/rollback і критерії запуску - чітко.
• Комм-шаблони прикладені.
• Evidence-список структурований.
• Версія/дата/власник/рев'ю вказані.

9) Чек-лист виконавця SOP

• Підтверджені передумови і доступи JIT/JEA.
• Відкрито тікет/war-room і включені анотації.
• Спостережуваність: потрібні дашборди/алерти відкриті.
• Виконую кроки по порядку; після кожного - верифікація.
• При порушенні гардрейлів - негайний backout і ескалація.
• Evidence заповнений; підсумкова перевірка SLO/бізнес-SLI.
• Тікет закритий, статус-сторінка/коммс оновлені.

10) Приклади SOP (фрагменти)

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: Плановий апгрейд БД (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: Перемикання 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) Автоматизація навколо SOP

Шаблонізатор SOP: генерація скелета з RACI/гейтами/комм-блоком.
Бот-виконавець: кроки з чек-боксами, таймери, нагадування по cadence, автозбір evidence.
Інтеграція з CMDB/каталогом: у сервісу - список релевантних SOP.
Анотації телеметрії: “SOP-RUN:<ID> step N" → швидкий розбір.
Політики допуску: деплой/вікно стартують тільки при зелених гейтах SOP.

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

SOP без власника/дати рев'ю - «мертвий» документ.
Роздуті інструкції без критеріїв успіху і backout.
Неузгоджені команди/ключі - ризик помилок і витоків.
Різні версії в wiki і в репозиторії - розбіжність джерел істини.
Немає evidence - нічим підтвердити якість/комплаєнс.
«Один SOP на всі випадки» - втрачається здійсненність.

13) Дорожня карта впровадження (4-6 тижнів)

1. Нед. 1: затвердити шаблон SOP, лінтер і каталог; вибрати топ-10 сценаріїв.
2. Нед. 2: написати SOP для релізів/відкату/провайдера/бекапів; пілоти tabletop.
3. Нед. 3: підключити ChatOps-бота і анотації телеметрії; зв'язати алерти з SOP.
4. Нед. 4: квартальний графік рев'ю; ввести метрики Freshness/Success Rate.
5. Нед. 5–6: покрити 90% критичних операцій; DR/Security-SOP; автоматизувати збір evidence.

14) Підсумок

SOP робить операції передбачуваними і перевіряються: єдині гейти якості, детальні кроки, явні ролі і оборотність. У зв'язці з плейбуками, політиками, SLO і автоматизацією це перетворює експлуатацію в надійну виробничу лінію - швидкі реакції, мінімальний ризик і зрозуміла відповідальність.