Standard Operating Procedures

1）什麼是SOP,為什麼需要它

SOP（標準操作程序）是用於可重復操作的正式批準步驟序列，具有可理解的輸入/輸出，角色和質量標準。

• 降低執行變異性和風險。
• 通過完成操作來減少MTTA/MTTR。
• 合規和審計：可重復性，可跟蹤性。
• 提前：加快學習速度和「shadow → solo」。

SOP ≠花花公子：花花公子是帶有叉子的決策樹，SOP是特定腳本（或花花公子分支）的線性法規。

2）「良好」SOP原則

Outcome-Driven：專註於結果（SLO/業務標準）,而不僅僅是步驟。
明確性：命令，參數，預期效果和控制點。
默認安全性：網關、限值、背面/滾回指定。
上下文最小：簡短註釋+引用詳細的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）標記為：「域/操作」，「服務/檢查」，「風險/高」，「提供者/psp-a」。
所有者卡：團隊，值班聯系人，後備所有者。
相關性SLA（例如，每≤90天或事件/發布後進行一次修訂）。
Linter/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執行失敗時的角色/時間。
服務窗口：高風險SOP的插槽/通用要求。

7） SOP效率指標

時間到執行（中位數/p95）-過程需要多少時間。
成功率-在沒有升級/回滾的情況下成功執行的比例。
Evidence Completeness-文物填充。
SLO Impact-步驟期間/之後是否有降解（燃燒分鐘）。
Defect Density-在10 SOP上進行評論/演習時的評論。
Freshness是具有≤90天咆哮的SOP份額。
Adoption-實際綁定到SOP的分量/窗口。

8）SOP作者的支票清單

• 目標和適用範圍已經確定。
• 角色、訪問和窗口-描述。
• 質量門和SLO-可測量，有信號源。
• 可執行步驟：命令/腳本，預期結果，驗證。
• Backout/rollback和啟動標準-明確。
• Comm模板隨附。
• Evidence列表是結構化的。
• 版本/日期/所有者/評論。

9）SOP表演者的支票清單

• 已確認JIT/JEA的預定義和可用性。
• 已打開tiket/war-room,並包含註釋。
• 可觀察性：所需的dashbords/alerta是開放的。
• 執行順序步驟；每個之後-驗證。
• 在違反加德雷爾的情況下-立即退縮和升級。
• Evidence已滿；最終的SLO/Business SLI驗證。
• Ticket已關閉,狀態頁面/comms已更新。

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：計劃的DB升級（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/gate/comm塊生成骨架。
機器人藝術家：帶有支票盒的步驟，計時器，cadence提醒，自動彈出事件。
與CMDB/目錄集成：服務包括相關的SOP列表。
遙測註釋：「SOP-RUN：<ID> step N」 →快速解析。
公差策略：dploy/窗口僅在綠色 SOP門時開始。

12）反模式

沒有所有者/日期咆哮的SOP是「死者」文檔。
沒有成功標準的誇張指令和背景。
不一致的命令/密鑰是錯誤和泄漏的風險。
Wiki和存儲庫中的不同版本是真相來源的差異。
沒有evidence-沒有什麼可以確認質量/合規性。
「每個案例一個SOP」-失去可執行性。

13）實施路線圖（4-6周）

1.奈德。1：批準SOP模板,linter和目錄；選擇前10個腳本。
2.奈德。2：為發布/回滾/提供商/備份編寫SOP；tabletop飛行員。
3.奈德。3：連接ChatOps機器人和遙測註釋；將Alertes與SOP關聯。
4.奈德。4：季度時間表咆哮；輸入新生/成功率指標。
5.奈德。5-6：覆蓋90%的關鍵交易；DR/Security-SOP;自動收集事件。

14）結果

SOP使操作具有可預測性和可驗證性：單個質量門，詳細步驟，顯式角色和可逆性。通過與花花公子、政策、SLO和自動化相結合，它將運營轉變為可靠的生產線--快速反應、最小風險和可理解的責任。