《后端架构设计·演进与治理》附录 C 上线治理检查清单

C.1 怎么用这份清单

这份清单不是发布流程的替代品，而是评审时的提问脚本。每一项都要求三样东西：证据、通过条件、失败后的回退动作。只勾“已完成”不算通过，必须能指出证据放在哪里、由谁维护、多久失效。

使用方式：

1. 上线前由变更负责人逐项填写，不能填的标“不适用”并写理由；
2. 评审人随机抽查三项，要求现场打开证据；
3. 任何一项“无证据”且属于关键路径，暂停发布；
4. 发布后 7 天内复核一次，确认证据仍然有效。

清单分六类，共 26 项。不是每次发布都要全跑：新增服务、拆分、跨租户变更、数据库迁移、重大流量活动应当全跑；日常小版本可以只跑标注“必查”的项。

发布类型与必查范围

这张表只决定“查哪些”，不降低单项标准。简化不等于免检：被简化的类别如果出现异常信号，应当立即升级为全查。

C.2 拆分与边界（4 项）

S-1 的关键不是“想拆”，而是“有数据证明现在的边界在拖累变更”。S-2 最容易被跳过：拆服务不拆数据，等于把共享表变成分布式共享表，故障面只会更大。

C.3 契约与兼容（5 项）

契约检查的核心不是“文档更新了没有”，而是“如果消费者不升级，会不会坏”。C-5 必须是真的会失败的门禁，不能是“生成报告供参考”。

C.4 观测与 SLO（5 项）

O-1 是最容易“看起来有、实际没有”的一项。判断标准很简单：用户投诉时，能不能用这个 SLI 复现“用户确实失败了”。不能，就说明它测的是服务，不是用户。

C.5 混沌与发布（6 项）

R-3 是发布治理的分水岭。没有回滚演练的“回滚脚本”，和没有消防演练的消防通道差不多：存在，但没人知道能不能用。

C.6 租户与安全（4 项）

T-2 必须在网关或统一入口做，不能依赖每个服务自己检查。只要有一个服务漏检，跨租户泄漏就会发生；而这类事故的修复成本远高于上线前的一次拒绝。

C.7 平台与成本（4 项）

P-1 和 P-2 经常被误解为“平台团队的自嗨指标”。实际上它们回答的是：组织是否真的通过平台降低了交付成本，而不是又维护了一套工具。

C.8 一页式评审表

把上面的条目压缩成一页，评审时逐行确认。空白不等于通过，必须写“有证据/不适用/未通过”。

评审结论只有三种：

• 通过：关键项全部有证据，非关键项有明确的不适用理由；
• 有条件通过：存在未验证项，但有回退动作、责任人和截止日期；
• 不通过：关键项无证据，或回退动作不可执行。

“有条件通过”不是免责，它必须带一个可验收的截止日期；到期未完成，下一次发布自动降为“不通过”。

C.9 证据留存

证据不需要统一格式，但必须满足四个条件：

1. 可定位：评审人能在一个链接或一个目录里找到；
2. 可复现：命令、输入、环境齐全，别人能重跑；
3. 有时效：写明生成时间，超过 30 天的容量/演练数据需要重跑；
4. 有责任人：每份证据有一个维护人，不能是“团队公共”。

建议的最小留存结构：

release-evidence/
  <change-id>/
    split/           拆分评估与依赖图
    contract/        schema diff、消费者清单、契约测试
    observability/   SLI 查询、看板快照、告警规则
    release/         制品摘要、金丝雀记录、回滚演练
    chaos/           实验计划、止损记录、回归项
    tenant/          越权测试、身份与密钥审计
    cost/            标签报告、单位成本口径
    review.md        一页式评审表与结论

这份目录不需要复杂工具，一个对象存储桶加命名规范就能做到。真正难的是坚持每次发布都留，而不是事后补。

C.10 常见错误

• 把清单当审批表。 清单的目的是暴露证据缺口，不是收集签字；签字齐全但证据缺失，比不做清单更危险。
• 关键项没有失败路径。 “必须通过”但没有“不通过怎么办”，评审会被迫放行。
• 证据只在个人电脑里。 人一休假就失效，等于没有证据。
• 演练记录只写成功。 没有失败场景和回归项的演练报告，不能证明系统能承受故障。
• 成本只做总量对比。 总量下降可能只是业务量下降；没有单位经济，无法判断架构是否真的变便宜。
• 清单一年不更新。 系统、团队和监管都在变，清单需要至少每季度复核一次。

C.11 发布后 24 小时复核

上线不是治理的终点。发布后 24 小时是信号最密集、也最容易被忽略的窗口；很多问题不会在发布当下暴露，而是在缓存过期、定时任务触发或流量高峰时出现。

复核不通过时，不要先争论“是否属于发布导致”。先确认回滚能否让指标恢复；如果能，回滚就是最便宜的诊断工具。回滚后再分析原因，比在故障中定位代码更安全。

C.12 与四卷的对应关系

这份清单不是孤立存在的，它把四卷的判断压成了发布时的检查项。

带着这张表读四卷，会比按章节顺序读更容易建立联系：每一次发布，都是四卷结论的一次联合验收。

C.13 最小证据模板

如果团队还没有统一的证据目录，可以从下面这份模板开始。它不依赖特定工具，复制到任意文档系统即可使用。

变更编号：
变更摘要：
影响服务 / 租户：
计划发布时间窗：
回滚负责人：

[拆分]
触发条件与数据：
共享数据 owner：
回退路径与演练时间：

[契约]
兼容性检查结果：
消费者清单与调用量：
弃用窗口：

[观测]
SLI 定义与查询：
基线（发布前 7 天）：
告警与 runbook：

[发布]
制品摘要：
金丝雀阶段与门禁：
回滚演练耗时：

[混沌]
实验场景与爆炸半径：
止损条件：
回归项与 owner：

[租户]
隔离级别与越权测试：
服务身份与权限：
密钥轮换记录：

[成本]
owner 标签覆盖：
单位成本口径：
未分摊比例与处置人：

评审结论：通过 / 有条件通过 / 不通过
未完成项与截止日期：

模板的价值在于暴露空白。任何一格写不出来，都对应一个尚未回答的治理问题；先补空白，再谈发布。

C.14 小结

这份清单把卷四的六类治理动作压成 26 个检查项，每项都要求证据、通过条件和回退动作。它的价值不在于“覆盖全面”，而在于把“我们觉得没问题”变成“我们能证明哪里没问题、哪里还没证明”。

上线治理的终点不是一张全部打勾的表，而是一个团队能在十分钟内说清：这次变更改了什么、影响谁、失败了怎么退、证据在哪。如果做不到，清单再长也只是形式。