发布风险评估表模板：评估维度与风险等级

发布风险评估表用“评估维度×风险等级”两轴组织：维度回答查什么，等级回答风险多大、怎么处置。本文给出一张可直接复制填写的空白表，覆盖变更范围与影响面、依赖与集成、数据与回滚、验证与监控、人员与窗口、合规与审批六类维度，并按发生可能性与影响程度组合出低、中、高、极高四级，对应放行、加严验证、需审批、暂缓发布四类处置，同时附一份完整填写示例和模板维护方法。

要点总览（TL;DR）

• 发布风险评估表按“评估维度×风险等级”两轴组织：六个维度回答查什么，四级等级回答风险多大、怎么处置。
• 六个评估维度为变更范围与影响面、依赖与集成、数据与回滚、验证与监控、人员与窗口、合规与审批，每行先打可能性与影响两项分。
• 风险等级由发生可能性（低/中/高）与影响程度（局部/部分用户/核心中断）组合得出，对应直接放行、加严验证、需审批、暂缓发布四类处置。
• 综合等级取六个维度中最高的那一档，业务高峰发布、核心链路首次上线、涉及资金或敏感数据、依赖方同日发布等情形至少上调一档。
• 必填字段包括发布单号、版本号、影响面、回滚方案、风险等级、处置结论、评估人与日期；灰度比例、观察期等按发布类型补充。

可复制空白模板：发布风险评估表

下表是评估表的主体结构，复制到文档或表格工具中即可逐行填写。表头记录发布基本信息，六个维度各占一行，每行先打可能性与影响两项分，再汇总为综合等级和处置结论，最后补齐回滚方案与验证证据。

发布单号	版本号	评估人	评估日期	发布窗口

评估维度	检查内容摘要	可能性（低/中/高）	影响程度（局部/部分用户/核心中断）	维度风险提示	回滚方案与验证证据
变更范围与影响面	涉及模块、用户比例、核心链路
依赖与集成	上下游系统、接口变更、第三方服务
数据与回滚	数据结构变更、回滚脚本、备份可用性
验证与监控	测试覆盖、灰度方案、监控告警与观察期
人员与窗口	值班安排、发布时段、业务高峰避让
合规与审批	变更审批、安全与合规检查项
综合结论	综合风险等级：低 / 中 / 高 / 极高	处置结论：直接放行 / 加严验证 / 需审批 / 暂缓发布		评估人签字与日期：

填写顺序建议从下往上：先确认合规与审批是否齐备，再逐行评估前五个维度，最后汇总综合等级。综合等级取六个维度中最高的那一档，避免用平均分掩盖单点高风险。

六个评估维度分别查什么

每个维度对应一组具体问题，填表人按“检查内容”逐项核对，用“判断依据”决定可能性与影响怎么打分。维度之间不重复计分，同一事实只在最相关的维度里体现一次。

评估维度	检查内容	判断依据
变更范围与影响面	涉及哪些模块、影响用户比例、是否触及登录、支付、下单等核心链路	改动文件与模块清单、影响用户占比估算、核心链路清单比对结果
依赖与集成	上下游系统是否同步变更、接口协议是否调整、第三方服务是否可用	接口变更记录、联调结果、第三方服务状态与联系人确认
数据与回滚	是否改数据结构、回滚脚本是否验证、备份是否可用	数据库变更脚本评审记录、回滚演练结果、备份恢复验证记录
验证与监控	测试覆盖是否充分、灰度方案是否明确、监控告警是否配置、观察期多长	测试报告与覆盖率、灰度比例与放量节奏、告警规则与值班观察安排
人员与窗口	值班人员是否到位、发布时段是否避开业务高峰、是否有应急联系人	值班表、业务流量时段数据、应急响应名单
合规与审批	变更审批是否完成、安全扫描与合规检查项是否通过	审批记录、安全扫描报告、合规检查清单签署结果

填写时把“检查内容”当作提问，“判断依据”当作证据来源。证据缺失的维度不能直接打低分，应记为待补充并在处置结论中体现。评估表本身需要与发布单放在一起，ONES Wiki 支持文档关联项目任务，页面组可关联项目，评估记录与需求、发布任务可以互相对应，便于发布后回溯当时的判断依据。

风险等级怎么定：可能性与影响组合

风险等级由发生可能性与影响程度两个维度组合得出，单看一项容易失真：高影响但概率低的事件若只按概率打分会被低估，低影响但高频出现的问题也不该占用过多审批资源。先分别定级，再查矩阵。

可能性分级标准

• 低：同类变更近期无故障记录，测试与灰度覆盖充分，回滚路径已验证。
• 中：存在未完全验证的环节，或依赖方状态不完全可控，但已有应对预案。
• 高：首次变更、缺少测试覆盖、依赖方同步变更未联调，或回滚方案未演练。

影响程度分级标准

• 局部：影响单个非核心功能或小比例内部用户，可快速隔离。
• 部分用户：影响部分外部用户或非核心链路，有降级方案。
• 核心业务中断：影响登录、支付、下单等核心链路，或大面积用户不可用。

组合矩阵与处置

可能性 \ 影响	局部	部分用户	核心业务中断
低	低：直接放行	低：直接放行	中：加严验证
中	低：直接放行	中：加严验证	高：需审批
高	中：加严验证	高：需审批	极高：暂缓发布

四级处置的含义：直接放行按常规流程发布；加严验证要求补充灰度、扩大测试范围或延长观察期后再放行；需审批要求变更负责人之外的审批人确认回滚方案与监控安排；暂缓发布要求先消除高风险因素，重新评估后再排期。

等级升级的例外情形需要单独写明：发布窗口落在业务高峰期、核心链路首次上线、涉及资金或用户敏感数据、依赖方同日发布，任一情形出现时综合等级至少上调一档。例外规则应写进模板说明，避免每次评估临时争论。

必填与选填字段

字段取舍的原则是：缺少就无法判断风险或无法追责的字段必填，只影响执行细节的字段按场景补充。必填字段漏填时评估表不生效。

字段	必填/选填	说明
发布单号	必填	与发布系统或发布单记录对应
版本号	必填	精确到本次发布的具体版本
影响面	必填	涉及模块与影响用户范围
回滚方案	必填	回滚步骤、触发条件、责任人
风险等级	必填	低/中/高/极高四级之一
处置结论	必填	放行/加严验证/需审批/暂缓发布
评估人与日期	必填	便于事后追溯判断依据
灰度比例	选填	有灰度发布安排时填写
观察期时长	选填	发布后需要重点观察的时间段
关联变更单	选填	同一批次的其他变更，便于合并评估
第三方依赖联系人	选填	依赖外部服务时补充

不同发布类型的字段差异：常规迭代发布按上表执行；紧急修复发布可先填必填字段并在发布后 24 小时内补齐选填项，但回滚方案与影响面不得省略；首次上线类发布应额外填写灰度比例、观察期时长和第三方依赖联系人，并把验证证据作为附件关联。

填写示例：一次常规版本发布

以下示例为演示情景：某常规迭代版本对支付链路做了一处小改动，用于说明字段如何落地，不代表真实项目数据。

字段	填写内容
发布单号 / 版本号	REL-2024-0312 / v3.8.2
评估人 / 日期 / 窗口	张工 / 3 月 12 日 / 当日 22:00–23:00
变更范围与影响面	支付回调重试逻辑调整，影响约 5% 支付订单，不触及下单主流程
依赖与集成	依赖支付网关接口，本次无协议变更，已与网关方确认当日无同步发布
数据与回滚	无数据结构变更；回滚脚本已在预发验证，配置项可一键回退
验证与监控	单测覆盖回调分支，灰度 10% 观察 2 小时，支付失败率告警已配置
人员与窗口	值班两人，窗口避开交易高峰，网关方联系人已确认在线
合规与审批	变更审批已通过，安全扫描无新增高危项

打分与结论：可能性为中（回调逻辑存在未完全覆盖的边界场景），影响程度为部分用户，查矩阵得中等级，处置为加严验证——先灰度 10% 观察 2 小时，支付失败率无异常后再全量。回滚验证证据为预发环境的回滚演练记录与配置回退截图，随评估表一并归档。

模板的调整与维护方法

模板需要随团队发布节奏和事故经验持续调整，调整的依据来自复盘而不是主观感觉。以下规则可作为维护起点。

• 按发布频率与业务关键度裁剪维度：高频低风险发布可合并“人员与窗口”和“合规与审批”两行，核心链路发布保留全部六行并附加验证证据要求。
• 等级阈值随事故复盘调整：每次事故复盘后检查当时的评估结论与实际影响是否一致，若多次出现低估，上调对应维度的可能性判定标准或补充升级例外。
• 保留模板版本与评审记录：模板每次修改记录版本号、修改人、修改原因，评审记录与模板放在同一文档空间。ONES Wiki 的页面模板库支持一键创建制式化文档模板，文档实时同步并记录所有页面版本，支持随时查看与回滚，适合承载模板的版本管理；读写权限可按角色配置，评估表与审批记录可限定在发布相关角色范围内。
• 与发布单、变更审批字段对齐：评估表中的发布单号、版本号、处置结论应与发布单和审批记录使用同一字段口径，避免同一发布在不同系统里出现两套编号，事后核对困难。

建议每季度检查一次模板使用情况：统计各等级的分布比例，若“直接放行”占比长期接近全部，说明维度判定过松；若“暂缓发布”频繁出现，说明前置检查环节需要前移。调整后的模板在下一个发布周期生效，旧版本保留备查。

常见问题

紧急修复发布来不及填完整评估表，怎么处理？

紧急修复可以只填必填字段先行发布，但影响面与回滚方案两项不能省略，它们是判断风险与事后追责的最低依据。发布完成后在 24 小时内补齐灰度比例、观察期时长等选填项，并把实际影响与评估结论做一次对照。若紧急发布反复出现，建议在模板中单列一类“紧急发布”字段集，明确哪些项可后补、补录时限多长，避免每次临时协商。

六个维度打分后，综合等级能不能取平均分？

不建议取平均。平均分会把单点高风险稀释掉，例如数据与回滚维度为高、其余五项为低，平均后可能落到中等级而被直接放行。模板采用“取最高档”规则：六个维度中任一维度达到高或极高，综合等级即为该档。若团队希望保留整体视角，可以在综合结论旁附一行平均分作参考，但处置结论以最高档为准。

评估表填完后放在哪里，才能和发布单、审批记录对得上？

评估表应与发布单放在同一处并共用同一套编号：发布单号、版本号、处置结论在评估表、发布单和审批记录中使用相同字段口径。ONES Wiki 支持文档关联项目任务，页面组可关联项目，评估记录与需求、发布任务可以互相对应，便于发布后回溯当时的判断依据（F4）。评估表本身可借助页面模板库一键创建，减少每次从零起草的重复工作（F2）。

模板用久了“直接放行”占比越来越高，是风险真的降低了还是判定变松了？

先看等级分布再下结论。建议每季度统计一次各等级占比：若“直接放行”长期接近全部，通常说明维度判定标准偏松，可上调可能性判定门槛或补充升级例外；若“暂缓发布”频繁出现，说明前置检查环节需要前移，把问题挡在评估之前。判断依据应来自事故复盘——比对当时评估结论与实际影响是否一致，多次低估的维度优先调整。

小团队发布频率低，六个维度都要保留吗？

可以按发布频率与业务关键度裁剪。高频低风险发布可将“人员与窗口”和“合规与审批”合并为一行；核心链路发布、首次上线、涉及资金或用户敏感数据的发布应保留全部六行，并附加验证证据要求。裁剪的前提是保留必填字段，尤其是影响面与回滚方案。模板修改后记录版本号与修改原因，旧版本保留备查，便于对照不同时期的评估口径。