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, ошибок < baseline×1.2
• Rollback: полное отключение флага, постмортем ≤72ч

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.