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-
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更新的任务。