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和自动化相结合，它将运营转变为可靠的生产线--快速反应、最小风险和可理解的责任。