模板不是文档格式，是最小证据集
卷四反复强调：治理动作要留下证据。模板的作用不是让文档看起来整齐，而是保证每次决策都回答了同样几个问题。缺字段的模板比没有模板更危险，因为它会制造“已经评估过”的错觉。
下面七份模板覆盖了全书最常见的治理场景。每份都给出最小字段集，可以按团队规模裁剪，但不建议删掉 owner、时间与回滚这三类字段。
A.1 平台能力契约
用于第 1.1 节。一个平台能力一份，随能力版本演进。
capability: account
version: 2.3
owner_team: platform-account
consumers:
- rift-arena
- archipelago
- bubble-workshop
sla:
availability: 99.95%
p99_latency_ms: 120
error_budget_window: 30d
quota:
default_qps: 2000
burst_qps: 4000
quota_change_lead_time: 5d
change_policy:
notice_window: 14d
breaking_change_window: 90d
deprecation_owner: platform-account
support:
oncall: platform-account-primary
escalation: platform-lead
exit:
data_export: supported
migration_assistance: 30d
最小字段说明：
| 字段 | 为什么必须有 |
|---|---|
owner_team | 没有 owner 的能力最终会变成孤儿服务 |
consumers | 变更影响面必须可枚举，不能靠记忆 |
sla | 调用方需要知道能依赖到什么程度 |
quota | 没有配额的平台会被单个产品打满 |
change_policy | 兼容窗口与通知期是契约的一部分 |
exit | 没有退出机制的平台就是锁定 |
常见误用：把 consumers 写成“所有游戏”；把 SLA 写成 100%；把配额写成“按需申请”却不写审批时限。
A.2 架构决策记录（ADR）
用于第 8.1、12.1 节。一份 ADR 只记录一个决定。
# ADR-014 活动配置采用版本快照而非原地修改
- 状态：已接受
- 日期：2026-10-18
- 决策者：架构评审组
- 关联：风险 R-07、路线图 Q4-LiveOps
## 背景
活动配置目前原地修改，回滚依赖数据库备份，平均恢复时间 40 分钟。
## 选项
1. 原地修改 + 备份回滚
2. 每次发布生成不可变版本快照，运行时按版本加载
3. 引入独立配置中心，活动服务只读
## 决定
采用选项 2。活动配置发布时生成版本快照，运行时持有版本号，回滚即切换版本号。
## 后果
- 正面：回滚从 40 分钟降到分钟级；审计可以精确到版本。
- 负面：配置存储量增长；需要处理快照清理。
- 风险：旧版本被引用时不能删除，需要引用计数。
## 验证
回滚演练一次，目标 5 分钟内完成；快照清理任务上线后观察一个月。
常见误用：把 ADR 写成会议纪要；只写选了什么，不写放弃了什么；没有验证方式。
A.3 架构评审结论
用于第 8.1 节。评审必须有结论，不能只写“原则同意”。
review_id: AR-2026-041
subject: 跨服赛事结算链路改造
level: cross-product
reviewers: [arch-lead, platform-pay, sre-lead]
decision: approved-with-conditions
conditions:
- id: C1
text: 结算回传必须带幂等键，并提供重复回传测试
owner: rift-arena-server
due: 2026-11-20
- id: C2
text: 上线前完成一次跨区故障演练
owner: rift-arena-server
due: 2026-11-25
risks:
- id: R-11
text: 跨区网络抖动导致结算延迟
mitigation: 超时补偿队列 + 对账任务
rollback: 关闭赛事入口，保留已结算记录
评审结论只允许三种：approved、approved-with-conditions、rejected。approved-with-conditions 必须写明条件、owner 与截止时间，否则等同于无结论。
A.4 风险台账
用于第 8.2、12.1 节。风险不是待办事项，它必须有触发条件与缓解措施。
- id: R-07
title: 活动配置回滚依赖人工
impact: 高
likelihood: 中
trigger: 活动上线后 30 分钟内出现奖励异常
mitigation: 版本快照 + 一键回滚
owner: liveops-platform
review_date: 2026-12-01
status: mitigating
台账每月复盘一次。超过 review_date 未更新的风险自动标红；连续两个季度没有变化的低风险可以关闭，但必须记录关闭理由。
A.5 GM 操作工单
用于第 3.1、3.2 节。所有高权限操作都必须能追溯到一张工单。
ticket: GM-2026-11872
action: grant_item
target_player: P-883021
item: event_token_2026
quantity: 3
reason: 活动奖励漏发补偿
requested_by: cs-agent-17
approved_by: ops-lead-03
second_review: gm-lead-01
idempotency_key: gm-2026-11872-P-883021-event_token_2026
executed_at: 2026-11-04T02:10:00+08:00
evidence: gm-exec-11872.json
rollback_plan: 扣除同批次发放，若不足则转人工复核
双人复核的两个角色不能来自同一汇报线；紧急通道可以先执行，但必须在 24 小时内补审批并标注 emergency: true。
A.6 事故复盘报告
用于第 7.2 节。复盘不是追责文档，重点是系统性原因与可验证的改进项。
# 事故复盘：活动开服奖励重复发放
- 事故等级：P1
- 影响时间：2026-10-27 20:03 — 20:41
- 影响范围：裂隙战场 3 个服，约 1.2 万玩家
- 指挥：sre-lead
- 状态：已完成
## 时间线
- 20:03 活动配置发布
- 20:07 客服收到奖励异常反馈
- 20:12 确认重复发放，暂停活动
- 20:41 完成多发放回收与补偿
## 根因
配置发布服务在重试时未校验幂等键，同一活动版本被应用两次。
## 系统性原因
1. 配置发布没有幂等约束；
2. 活动开服缺少奖励总额上限校验；
3. 告警只监控服务错误率，没有监控发奖速率。
## 改进项
| ID | 改进 | owner | 截止 | 验收 |
|---|---|---|---|---|
| A1 | 配置发布增加幂等键 | liveops-platform | 11-10 | 重试测试通过 |
| A2 | 奖励总额超阈值阻断 | liveops-platform | 11-15 | 单测 + 演练 |
| A3 | 发奖速率告警 | sre | 11-08 | 告警可触发 |
改进项必须可验收；“加强意识”“完善流程”不是改进项。
A.7 规则豁免单
用于第 8.3 节。任何绕过自动检查的例外都要有期限与 owner。
rule: no-cross-service-database-access
exception_id: EX-2026-009
path: internal/legacy/report
owner: data-team
reason: 报表服务尚未完成数据接口迁移
compensating_control: 只读账号 + 每周审计
expires: 2027-03-31
reviewed_by: arch-lead
豁免到期后规则自动恢复阻断。需要续期必须重新评审，不能自动延期。
A.8 模板使用建议
- 小团队可以只保留 A.1、A.2、A.5、A.6 四份，其余用会议记录代替；
- 模板字段与自动检查尽量同名，减少人工转录；
- 所有模板都应有机器可读版本（YAML/JSON），文档版本由它生成；
- 模板每半年评审一次，删掉从未被使用的字段。
模板的价值不在于填得全，而在于缺了哪一项会被立刻发现。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。