SOP：<短動作/目標>

操作程序的標準化

1）為什麼需要它

SOP是公司的「操作操作系統」。標準化消除了混亂和「定制樣式」，降低了MTTR，警報噪音和事件風險，加快了爬行速度，並使結果可重現。

• 減少事件和例行操作的變異性。
• 加快培訓速度，提高獵頭質量。
• 使流程可驗證：審計、指標、數據改進。
• 確保遵守監管和內部要求。

2）標準化原則

1.統一格式和術語。一個符號，一個定義（SLO，ETA，Owner）。
2.Actionable，非百科全書。僅可驗證的步驟，成功和回滾標準。
3.最小分支。明確的「如果/那麼」解決方案而不是自由陳述。
4.選拔和所有權。每個SOP都具有所有者，版本和修訂日期。
5.與工具集成。指的是dashbords，tiketas，ficheflagi，CLI命令。
6.On coll中的可用性。快速搜索，閱讀，執行單個鏈接。
7.持續改進。Mortems →任務來更新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

Steps:

1） Pause canary in release-tool（鏈接）

2）檢查「Change Safety」和「API p99」面板"

3）創建REG- ticket,指定基線/窗口

DoD: p99 ≤ 1.1 ×基線15 m，錯誤<基線× 1。2

Rollback： 完全禁用標誌,驗屍≤72ch

SOP: PSP Provider Feilover

Triggers: quota_usage>0.9 OR outbound_error_rate>2×baseline 5m

Steps:

1）啟用PSP-Y路由器（config/按鈕）

2）檢查存款轉換和p95 PSP-Y

3）圖表上的註釋，在#incident頻道中更新

DoD: success_rate ≥ 99.5%, p95 ≤ 300毫秒10米

Rollback： PSP-X穩定時部分流量返回20%

12）支票單

SOP準備就緒支票清單：
［］目標和觸發因素是可以理解和可衡量的。
［］有帶有命令/鏈接的逐步操作。
［］DoD/Rollback的措辭。
［］升級和聯系是相關的。
［］元數據已滿（所有者、版本、last_review)。
［］Link checker和CI驗證器通過。

SOP應用支票清單（在事件中）：
［］SOP從Incident Manager/窗格中的鏈接打開。
［］已執行步驟並記錄了結果。
［］國防部達到/不達到-註意。
［］動作/不一致記錄在tiket中。
［］SOP的更新/改進是由任務（如果需要）創建的。

13）培訓和提拔

關鍵的SOP（Payments/Bets/Games/KYC）迷你課程。
影子值班，在訓練中強制使用SOP。
每周「SOP診所」：30分鐘的分析/改進。
模擬（遊戲日）：運行DR-和事件SOP。

14） SOP變更管理

RFC通過PR，標記「小調/專業/突破」。
突破性變化-強制性培訓和公告。
自動通知域所有者及其所有者。
每個星期結束時單獨的「SOP-Release Notes」。

15）反模式

自由形式「如何工作」和不同的命令模式。
沒有所有者/版本/修訂日期的SOP。
「百科全書」文本代替了回合制動作。
沒有Rollback/DoD-沒有什麼可驗證成功的。
命中鏈接，「手動聊天」命令，私人「秘密」步驟。
無形的SOP更改而無需記錄和培訓。

16）30/60/90-實施計劃

30天：
批準SOP模板和最低標準。
創建存儲庫'ops-sop/'（docs-as-code）,啟用CI linters。
數字化10-15個關鍵SOP（事件/版本/提供程序）。
將Incident Manager和可觀察性面板連接到SOP鏈接。

60天：
在關鍵情況下達到Coverage ≥ 70%。
每周啟動「SOP診所」和全日制培訓。
通過SOP和TL添加AI搜索（RAG）；DR卡。
引入評論SLA （180天）和報告逾期的SOP。

90天：
Coverage ≥ 90%，Usage Rate ≥ 70%的事件。
將DoD/Rollback嵌入到所有SOP中,關閉位鏈接（0）。
將KPI SOP綁定到OKR命令（MTTR，更改失敗率）。
復古並記錄下一季度的改進。

17) FAQ

問：SOP與運行簿有何不同？
A： SOP-標準化程序（規則「如何正確」）。Runbook-針對特定案例/服務的詳細說明。通常，SOP會引用一個或多個運行簿。

Q： SOP應該有多少細節?
答：正好如此之多，以至於操作員無需在聊天中「深入了解」即可執行操作。任何不影響行動的東西都包含在單獨的參考資料中。

問：如何保持相關性？
答：修訂版SLA（≤180天），自動提醒，CI linter和Usage/DoD度量。任何異常事件→ SOP更新的任務。