发布风险清单按发布批次逐条登记风险，让团队在发布前看清可能出问题的环节，在发布后知道什么信号出现时启动回滚。本文提供一张可直接复制使用的空白表，逐字段说明填写口径，区分必填与选填，并用一次版本发布填出完整示例，最后说明模板如何随发布节奏调整与维护。
要点总览（TL;DR）
- 发布风险清单按发布批次组织：表头信息区记录发布名称、版本号、发布窗口、负责人与评审日期，风险明细区一条风险占一行。
- 核心字段包括风险描述、影响范围、风险等级、预防措施、回滚触发条件、回滚方案、责任人与验证结果；风险类别、触发条件、可能性与影响程度可按需选填。
- 必填项缺失视为未完成登记，不能进入发布评审；风险等级为空时需补齐判定依据或由发布负责人给定并说明理由。
- 回滚触发条件写成可观测指标加阈值，回滚方案写明步骤、耗时与数据处置方式，不可逆变更单独标注补偿方案。
- 模板按发布类型裁剪，并在发布前评审、发布中更新、发布后归档三个节点维护，历史风险可沉淀为发布前检查项。
可复制空白模板：发布风险清单表
模板分为两部分：表头信息区记录本次发布的基本信息，风险明细区逐条登记风险。复制到文档或表格工具后，先填表头，再按行补充风险。风险明细的行数按实际风险数量增减，一条风险占一行，不把多个风险合并在一行里。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 发布名称 | |
| 版本号 | |
| 发布窗口 | |
| 发布负责人 | |
| 评审日期 |
风险明细区
| 序号 | 风险类别 | 风险描述 | 触发条件 | 影响范围 | 发生可能性 | 影响程度 | 风险等级 | 预防措施 | 回滚触发条件 | 回滚方案 | 责任人 | 验证结果 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||||||
| 2 | ||||||||||||
| 3 | ||||||||||||
| 4 | ||||||||||||
| 5 |
表格列较多时，可把“风险描述”与“触发条件”合并为一列书写，但回滚触发条件与回滚方案建议保留独立列，避免发布现场需要回滚时找不到判断依据。
字段说明：每一列记录什么
字段说明与空白表、填写示例使用同一套字段名和顺序。填写时先保证每条风险能被另一个人读懂：什么情况下会发生、影响谁、怎么防、什么信号出现时回滚、谁来执行、最后验证成什么样。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 风险类别 | 风险所属的类型 | 使用团队固定的类别词，便于统计和复用 | 数据库变更 |
| 风险描述 | 一句话说明风险是什么 | 写清对象和动作，不写“可能有问题”这类空话 | 订单表新增字段的迁移脚本在存量数据上执行超时 |
| 触发条件 | 风险在什么条件下发生 | 写可观察的前置条件或环境条件 | 存量订单量超过阈值且迁移未分批执行 |
| 影响范围 | 风险发生后波及的用户、功能或系统 | 写清功能模块、用户群体和关联系统 | 下单与订单查询功能，全部线上用户 |
| 发生可能性 | 风险发生的概率档位 | 固定使用高/中/低三档，团队统一口径 | 中 |
| 影响程度 | 风险发生后的损失档位 | 按对用户和业务的影响固定分档 | 高 |
| 风险等级 | 由可能性与影响程度共同判定 | 在模板中固定一种判定规则，如矩阵对照或评分相乘 | 高 |
| 预防措施 | 发布前降低发生概率或损失的动作 | 写具体动作和完成标志，不写“加强关注” | 迁移脚本先在预发环境用全量数据副本演练，并改为分批执行 |
| 回滚触发条件 | 发布后出现何种信号时启动回滚 | 写可观测指标及阈值，与预防措施分开填写 | 发布后30分钟内下单接口错误率超过1%或订单写入失败持续5分钟 |
| 回滚方案 | 回滚的具体步骤与约束 | 写步骤、预计耗时、数据是否可逆及回滚后验证方式 | 切回上一版本应用包，执行字段回退脚本，预计15分钟；新增字段数据保留不回删 |
| 责任人 | 对该风险预防与处置负责的人 | 写具体人名或岗位，不写团队名 | 后端负责人 张×× |
| 验证结果 | 发布后对该风险的确认结论 | 记录验证时间、验证方式和结论 | 发布后1小时检查迁移日志与下单成功率，未触发回滚条件，风险关闭 |
预防措施与回滚触发条件容易混写。预防措施发生在发布前，目标是让风险不发生或损失更小；回滚触发条件是发布后的判断标准，回答“看到什么就回滚”。两者分开填写，发布现场才能快速决策。回滚方案中遇到不可逆变更，例如已执行且无法回退的数据迁移，应单独标注，并给出补偿方案而不是简单写“回滚数据库”。
必填与选填：哪些字段不能空
必填项的作用是保证任何一条风险都能被评审、被执行、被验证。以下字段在常规发布中不允许为空；确实不适用时，填写“不适用”并说明原因，留空视为未完成登记。
| 字段 | 要求 | 理由 |
|---|---|---|
| 风险描述 | 必填 | 没有描述就无法评审和跟踪 |
| 影响范围 | 必填 | 决定发布决策和通知对象 |
| 风险等级 | 必填 | 决定评审优先级和是否需要回滚预案 |
| 预防措施 | 必填 | 没有预防动作的风险不应直接进入发布 |
| 回滚触发条件 | 必填 | 发布现场需要明确的判断依据 |
| 回滚方案 | 必填 | 触发回滚后需要有可执行步骤 |
| 责任人 | 必填 | 明确谁预防、谁判断、谁执行 |
| 验证结果 | 发布后必填 | 作为风险关闭的依据 |
| 字段 | 要求 | 适用场景 |
|---|---|---|
| 风险类别 | 选填 | 风险条目较多、需要分类统计时填写 |
| 触发条件 | 选填 | 风险成因较复杂、需要说明前置条件时填写 |
| 发生可能性 | 选填 | 采用矩阵法判定风险等级时填写 |
| 影响程度 | 选填 | 采用矩阵法判定风险等级时填写 |
风险等级为空时，该条风险视为未完成登记，不能进入发布评审。处理方式有两种：补齐可能性与影响程度后按团队规则判定，或由发布负责人直接给定等级并在评审中说明依据。小规模发布可以只登记高风险项，但必填字段同样不能空；高风险发布，例如涉及数据库结构变更、核心链路改造或对外接口不兼容的发布，建议全部字段填写完整，并增加评审人签字或确认记录。
填写示例：一次版本发布的风险清单
以下示例为演示情景，展示一次包含数据库变更与接口调整的版本发布如何填写清单。示例中的阈值、耗时和人名仅用于说明写法，实际填写以团队环境为准。
表头信息
| 字段 | 内容 |
|---|---|
| 发布名称 | 订单服务 3 月版本发布 |
| 版本号 | v2.8.0 |
| 发布窗口 | 3月18日 22:00–23:30 |
| 发布负责人 | 李×× |
| 评审日期 | 3月16日 |
风险明细
| 序号 | 风险类别 | 风险描述 | 触发条件 | 影响范围 | 可能性 | 影响程度 | 风险等级 | 预防措施 | 回滚触发条件 | 回滚方案 | 责任人 | 验证结果 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 数据库变更 | 订单表新增字段的迁移脚本在存量数据上执行超时 | 存量订单量超过阈值且未分批执行 | 下单与订单查询，全部线上用户 | 中 | 高 | 高 | 预发环境用全量数据副本演练，迁移改为分批执行并记录每批耗时 | 迁移单批执行超过10分钟，或下单接口错误率超过1% | 停止后续批次，切回上一版本应用包，新增字段保留不回删，预计15分钟 | 后端 张×× | 发布后1小时检查迁移日志与下单成功率，未触发回滚条件，风险关闭 |
| 2 | 接口兼容 | 订单查询接口返回结构新增字段，旧版客户端解析异常 | 旧版客户端未做未知字段兼容处理 | 使用旧版客户端的用户 | 中 | 中 | 中 | 新增字段保持向后兼容，灰度期间观察旧版客户端错误上报 | 旧版客户端接口错误率较发布前上升超过0.5% | 关闭新字段返回开关，恢复原返回结构，预计5分钟 | 客户端 王×× | 灰度2小时后旧版客户端错误率无上升，风险关闭 |
| 3 | 配置错误 | 发布时配置项漏配导致订单超时时间取默认值 | 配置中心未同步新增配置项 | 下单链路超时判定 | 低 | 高 | 中 | 发布检查单逐项核对配置项，发布后自动比对配置快照 | 配置比对发现差异，或下单超时率异常升高 | 从配置中心回滚到上一版本配置快照，预计3分钟 | 运维 赵×× | 发布后配置比对一致，超时率正常，风险关闭 |
| 4 | 依赖服务不可用 | 下游库存服务在发布窗口内进行自身变更，导致下单校验失败 | 下游服务同时段变更且未提前通知 | 下单校验环节 | 低 | 高 | 中 | 发布前与下游确认变更窗口，错开时间并保留降级开关 | 下单校验失败率超过2%且持续5分钟 | 打开降级开关跳过实时库存校验，改为异步补偿，预计2分钟 | 后端 张×× | 发布全程监控校验失败率，未触发降级，风险关闭 |
示例中每条风险的回滚触发条件都写成可观测指标加阈值，回滚方案写明步骤、耗时和数据处置方式。验证结果记录验证时间、检查对象和结论，作为风险关闭依据；若发布后未验证，该条保持“待验证”状态，不提前关闭。
调整与维护：让清单跟着发布节奏更新
模板需要按发布类型裁剪，并在发布前、发布中、发布后三个节点维护，否则清单会变成一次性文档，下一次发布重新从零写起。
按发布类型裁剪
- 常规小版本：保留必填字段，风险类别可只登记高风险项，回滚方案可引用标准回滚手册。
- 涉及数据库结构或数据迁移：增加数据可逆性说明，回滚方案中单独标注不可逆步骤和补偿措施。
- 对外接口或客户端兼容变更：增加兼容性验证项，回滚触发条件中加入旧版本客户端的错误率指标。
- 大促或冻结期前的发布：提高评审级别，全部字段填写完整，并增加发布负责人以外的复核人。
维护节点
- 发布前评审：逐条确认风险描述、等级、预防措施和回滚方案，缺失必填项的风险不进入发布。
- 发布中更新：记录实际触发情况、是否执行回滚、执行耗时，与计划值对照。
- 发布后归档：补齐验证结果，把本次实际发生的风险和新发现的风险补入清单，随发布记录一并归档。
历史风险可以复用为检查项：把过去发布中实际触发过的风险整理成发布前检查清单，每次评审逐条确认，检查项与风险清单中的类别对应。清单与发布记录、回滚记录保持一一对应，同一发布批次的清单、发布记录和回滚记录使用相同的发布名称与版本号，便于事后追溯。
当清单需要在多人之间评审、跟踪和归档时，可以把风险条目放进工作项管理，把模板放进文档库。ONES Wiki 支持使用模板库一键创建制式化文档，适合把本文的空白表固化为团队模板；文档支持关联项目任务，页面组可关联项目，风险清单能与对应的发布任务互相对应；文档实时同步并记录所有页面版本，支持随时查看与回滚，便于保留每次发布的清单版本；同时支持为不同角色配置不同的读写权限，让发布负责人维护、评审人确认、其他成员只读。需要说明的是，这里的版本回滚指文档页面版本，与发布回滚是两件事。具体套餐与配置范围以实际开通情况为准。
常见问题
发布风险清单和发布检查单有什么区别，需要两份都做吗？
两者记录的对象不同。发布检查单按固定步骤逐项确认“该做的动作是否完成”，例如配置是否核对、备份是否执行；发布风险清单按风险逐条登记“可能出什么问题、怎么防、什么信号出现时回滚”。
实践中可以两份都保留：检查单保证流程动作不漏，风险清单保证每条风险有预防措施和回滚依据。规模较小的常规发布也可以把检查项并入风险清单的预防措施列，但回滚触发条件与回滚方案仍应独立成列，便于发布现场快速判断。
风险等级用高/中/低三档还是评分相乘，团队应该怎么选？
两种口径都能用，关键是团队内固定一种并写进模板说明。三档法填写快，适合风险条目不多、评审以讨论为主的团队；评分相乘把发生可能性与影响程度各自量化后计算，适合风险条目多、需要排序和统计的场景。
选定后不要在同一次发布里混用。若采用三档法，可能性与影响程度两列仍建议填写，作为等级判定的依据；若采用评分法，需在模板中写明分值范围和分档阈值，避免不同人算出不同等级。
发布过程中发现清单里没登记的新风险，应该怎么处理？
先判断是否影响本次发布继续进行。若新风险可能波及核心功能或数据，按发布负责人的决策暂停发布或缩小发布范围，并当场补登该条风险，至少写清风险描述、影响范围、风险等级、回滚触发条件与责任人，再决定继续还是回滚。
若新风险影响有限，可先记录在清单的补充行中，标注发现时间和发现人，发布结束后补齐预防措施与验证结果，并在归档时纳入历史风险库，作为下一次发布的检查项。补登的风险同样不能留空必填字段。
回滚方案里遇到无法回退的数据迁移，清单上应该怎么写？
在回滚方案中单独标注不可逆步骤，写明哪一步无法回退、影响哪些数据，并给出补偿方案，例如保留新增字段不回删、通过数据修复脚本修正异常记录、对受影响订单做人工核对。同时把预计处置耗时写清楚，便于发布现场评估影响。
这类风险建议在发布前评审时提高评审级别，并在回滚触发条件中设置更敏感的阈值。若补偿方案本身需要较长时间，应在清单中注明发布窗口是否足够，必要时调整发布窗口或改为分批发布。
清单评审通过后，发布前又改了配置或依赖版本，需要重新评审吗？
需要看改动是否触及已登记风险的触发条件或回滚方案。若改动涉及数据库脚本、接口返回结构、核心配置项或下游依赖版本，应更新对应风险条目并重新确认回滚触发条件与回滚方案，由原评审人复核。
若只是与风险无关的文案或日志级别调整，可在清单中记录变更内容和时间，发布负责人确认后不必完整重评。无论哪种情况，清单的版本应与最终发布的版本号对应，避免发布现场拿到的清单与实际发布内容不一致。
