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 (медиана/p95) — сколько занимает процедура.
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 и автоматизацией это превращает эксплуатацию в надежную производственную линию — быстрые реакции, минимальный риск и понятная ответственность.