怎么用这份清单
这份清单面向“平台与治理类变更”，包括平台能力发布、LiveOps 活动上线、GM 工具上线、观测与 SLO 规则变更、架构规则启用。它不替代具体产品的发布清单，而是补上“复用与协作”相关的检查项。
每条检查都要求三样东西：证据、owner、失败时怎么办。只打勾不给证据的检查，等于没做。
B.1 平台能力上线
| # | 检查项 | 证据 | owner | 未通过时 |
|---|---|---|---|---|
| 1 | 能力契约已登记，含 SLA、配额、owner | 契约文件链接 | 平台团队 | 不得开放调用 |
| 2 | 所有调用方已列入 consumers | 调用方清单 | 平台团队 | 补登记后再发 |
| 3 | 配额默认值与峰值已评估 | 容量表或估算 | 平台团队 | 按最小配额发布 |
| 4 | 变更通知已发出且满足通知期 | 通知记录 | 平台团队 | 推迟发布 |
| 5 | 兼容窗口与弃用计划已公布 | 版本矩阵 | 平台团队 | 不得标记稳定版 |
| 6 | 退出与数据导出方案已验证 | 导出演练记录 | 平台团队 | 标记为实验能力 |
| 7 | 平台自身有 SLO 与告警 | SLO 文档、告警链接 | SRE | 先补观测 |
| 8 | 故障时调用方的降级方案已确认 | 降级开关清单 | 各调用方 | 逐个确认后再发 |
平台能力最容易漏掉第 6 项与第 8 项。前者决定调用方能否离开，后者决定平台故障时产品是否一起死。
B.2 LiveOps 活动上线
| # | 检查项 | 证据 | owner | 未通过时 |
|---|---|---|---|---|
| 1 | 活动时间窗、时区与互斥关系已校验 | 校验报告 | 运营 | 修正配置 |
| 2 | 奖励表总额与单玩家上限已校验 | 奖励汇总表 | 策划 + 运营 | 调整奖励 |
| 3 | 配置版本快照已生成 | 版本号 | 运营 | 重新发布 |
| 4 | 灰度范围与放量节奏已确认 | 灰度计划 | 运营 + 服务端 | 缩小灰度 |
| 5 | 回滚开关可用且演练过 | 演练记录 | 服务端 | 延迟上线 |
| 6 | 发奖速率与异常告警已配置 | 告警链接 | SRE | 补告警 |
| 7 | 客服话术与补偿口径已同步 | 客服文档 | 客服负责人 | 同步后再发 |
| 8 | 活动结束后的数据归档与对账已安排 | 任务清单 | 数据 | 补任务 |
活动上线最常见的两个事故是“奖励算错”和“配置重复生效”。第 2 项与第 3 项分别对应这两类问题，不能省。
B.3 GM 工具上线
| # | 检查项 | 证据 | owner | 未通过时 |
|---|---|---|---|---|
| 1 | 动作级权限已定义，最小权限可执行 | 权限矩阵 | 平台团队 | 不得开放 |
| 2 | 高风险动作强制双人复核 | 审批配置 | 平台团队 | 降级为只读 |
| 3 | 所有命令带幂等键并可查询执行记录 | 执行账本样例 | 平台团队 | 不得上线 |
| 4 | 补偿与追回流程已定义 | 补偿方案 | 运营 + 服务端 | 限制批量操作 |
| 5 | 操作审计日志不可篡改且有保留期 | 审计配置 | 安全 | 先补审计 |
| 6 | 紧急通道有留痕与补审批机制 | 流程文档 | 运营负责人 | 关闭紧急通道 |
| 7 | 客服只读视图已脱敏 | 脱敏规则 | 安全 | 限制字段 |
| 8 | 批量操作有数量上限与二次确认 | 界面/接口限制 | 平台团队 | 禁用批量 |
GM 工具的风险不在“能不能改”，而在“改错了能不能查、能不能退”。第 3、4、5 项是底线。
B.4 观测与 SLO 变更
| # | 检查项 | 证据 | owner | 未通过时 |
|---|---|---|---|---|
| 1 | 新增指标有明确口径（分子、分母、窗口） | 指标文档 | SRE | 不上线 |
| 2 | 指标基数与成本已评估 | 基数估算 | SRE | 降低维度 |
| 3 | SLI 与 SLO 已定义，排除项写清 | SLO 文档 | SRE + 技术负责人 | 先观察 |
| 4 | 告警可行动，附 runbook | 告警链接 + runbook | SRE | 降为通知 |
| 5 | 告警去重、抑制与维护窗口已配置 | 配置记录 | SRE | 补配置 |
| 6 | 值班表与升级路径已更新 | 值班表 | SRE 负责人 | 补值班 |
| 7 | 错误预算与发布门禁已对齐 | 门禁配置 | 技术负责人 | 暂不启用门禁 |
| 8 | 仪表盘对产品团队可见 | 仪表盘链接 | SRE | 补权限 |
观测变更本身也可能引发事故：指标基数爆炸、告警风暴、仪表盘拖垮查询。第 2 项与第 5 项是常见的止血点。
B.5 治理规则启用
| # | 检查项 | 证据 | owner | 未通过时 |
|---|---|---|---|---|
| 1 | 规则有明确 scope、check、severity | 规则文件 | 架构组 | 不启用 |
| 2 | 现有违规已盘点并分级 | 违规报告 | 架构组 | 先告警不阻断 |
| 3 | 豁免有 owner 与过期时间 | 豁免清单 | 架构组 | 不启用阻断 |
| 4 | 规则误报率可接受 | 试运行报告 | 架构组 | 调整规则 |
| 5 | CI 集成不影响主流程时长 | 构建耗时对比 | 平台团队 | 异步检查 |
| 6 | 违规提示包含修复指引 | 规则文档 | 架构组 | 补文档 |
| 7 | 规则本身有 owner 与评审周期 | 规则台账 | 架构组 | 补台账 |
| 8 | 规则废弃流程已定义 | 流程文档 | 架构组 | 暂缓 |
规则启用的正确顺序是：先观察 → 再告警 → 最后阻断。直接阻断会让团队把规则当成障碍，而不是保护。
B.6 上线中的核对
发布开始后，每 5–10 分钟核对一次：
- 关键 SLI 是否在预算内；
- 错误率、延迟、发奖速率是否偏离基线；
- 是否有新的告警触发，是否可归因到本次变更；
- 灰度范围内的玩家反馈是否异常；
- 回滚开关是否仍然可用。
上线中不要同时做两件有风险的事。如果必须连续发布，先确认上一批的观测窗口已经结束。
B.7 上线后的核对
| 时间点 | 核对内容 | 负责人 |
|---|---|---|
| 1 小时 | SLI、告警、客服反馈 | 发布负责人 |
| 24 小时 | 错误预算消耗、数据对账 | SRE + 数据 |
| 7 天 | 变更成功率、回滚率、玩家影响 | 技术负责人 |
| 30 天 | 契约遵守情况、豁免到期提醒 | 架构组 |
上线后 7 天的数据要回填到发布记录里。没有回填的发布，下一次评审时无法判断它是否真的成功。
B.8 一页纸版本
如果只能带一页纸进评审室，保留下面八条：
- owner 是谁，SLA 是多少；
- 调用方有哪些，配额够不够；
- 变更怎么通知，兼容窗口多久；
- 出问题怎么回滚，演练过没有；
- 观测看哪些指标，告警能不能行动；
- 高权限操作有没有双人复核与审计；
- 规则误报怎么办，豁免什么时候到期；
- 上线后谁来核对，什么时候回填数据。
这八条答不上来，说明变更还没有准备好，不是文档还没写完。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。