发布风险评估表通常由三部分构成：评估维度、风险等级，以及对应的处置与回滚条件。评估维度覆盖变更范围、技术复杂度、测试充分性、数据与配置、回滚可行性、发布窗口、监控就绪度和历史经验；风险等级按高、中、低三档汇总，并对应不同的审批层级、发布窗口和回滚预案要求。下面给出一份可直接复制填写的空白表，并说明各维度判断口径、等级规则、填写示例与模板维护方法。
要点总览（TL;DR）
- 发布风险评估表由评估维度、风险等级、处置与回滚条件三部分构成，八个维度按1～3分评分后汇总为高、中、低三档。
- 风险等级以最高单项评分作为下限，避免平均分掩盖单点高风险；高、中、低三档分别对应不同的审批层级、发布窗口和回滚预案要求。
- 必填字段覆盖发布单基本信息、八个维度评分与说明、汇总等级、评估结论、回滚触发条件与步骤、发布负责人签字；业务审批签字、灰度说明等按变更类型选填。
- 模板需要按团队变更类型增删维度、校准等级阈值，并通过复盘回写和版本管理保持长期可用。
- 评估表落地时可借助文档模板库固化表单，用页面版本记录评审与调整留痕。
可复制空白模板：发布风险评估表
下表为空白模板，复制到文档或表格工具中即可填写。评分栏采用1～3分制：1分为低风险，2分为中等风险，3分为高风险。汇总时取各维度最高分作为风险等级下限，再结合整体判断确定最终等级。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 发布单号 | |
| 变更名称 | ||
| 负责人 | ||
| 计划发布窗口 | ||
| 评估维度评分 | 变更范围与影响面 | 评分：____ 说明：____ |
| 技术复杂度与依赖 | 评分：____ 说明：____ | |
| 测试与验证充分性 | 评分：____ 说明：____ | |
| 数据与配置变更 | 评分：____ 说明：____ | |
| 回滚可行性 | 评分：____ 说明：____ | |
| 发布窗口与资源 | 评分：____ 说明：____ | |
| 监控与告警就绪度 | 评分：____ 说明：____ | |
| 历史故障与相似变更经验 | 评分：____ 说明：____ | |
| 汇总与结论 | 最高单项评分 | |
| 汇总风险等级 | □高 □中 □低 | |
| 评估结论 | □按计划发布 □补充措施后发布 □暂缓发布 | |
| 回滚预案 | 回滚触发条件 | |
| 回滚步骤与责任人 | ||
| 回滚验证方式 | ||
| 审批签字 | 发布负责人 | |
| 技术审批人 | ||
| 业务审批人（按等级需要） |
表格中“说明”栏用于记录评分依据，例如影响哪些用户群、依赖哪些外部系统、测试覆盖了哪些场景。评分与说明同时填写，后续复盘时才能判断当时的判断是否合理。
评估维度逐项说明
八个维度各自回答一个具体问题，填写时按同一口径判断，避免不同发布单之间评分不可比。以下说明给出每个维度的观察点和评分参考。
变更范围与影响面
看这次变更影响多少用户、多少业务线、是否涉及核心交易或登录等关键链路。影响面越大、越靠近核心链路，评分越高。仅影响内部工具或边缘页面的变更可评1分；影响部分用户的功能改动评2分；涉及全量用户或核心链路评3分。
技术复杂度与依赖
看变更涉及多少服务、是否存在跨团队依赖、是否引入新的中间件或外部接口。依赖越多、协调方越多，发布过程中出现意外的概率越高。单服务独立改动评1分；涉及两三个服务联动评2分；跨多个团队、存在强时序依赖评3分。
测试与验证充分性
看测试覆盖是否与变更范围匹配，是否完成回归、集成或灰度验证。注意此维度是反向评分：验证越充分，风险越低。已完成完整回归并有灰度验证评1分；仅覆盖主流程评2分；测试不完整或依赖发布后观察评3分。
数据与配置变更
看是否涉及数据库结构变更、数据迁移、配置项调整或开关切换。数据类变更往往难以快速撤销，需要单独评估。无数据与配置改动评1分；有可回退的配置调整评2分；涉及表结构变更或不可逆数据迁移评3分。
回滚可行性
看一旦发布异常，能否在可接受时间内恢复到上一版本。同样采用反向评分：回滚越简单，风险越低。一键回滚且已验证评1分；需要手动步骤但演练过评2分；回滚依赖数据修复或无法完整回退评3分。
发布窗口与资源
看发布时段是否处于业务高峰、是否有足够的值班人力、是否与其他变更冲突。工作日上午低峰期且有值班人员评1分；常规时段但人力有限评2分；业务高峰期或节假日前后发布评3分。
监控与告警就绪度
看关键指标、错误日志和业务告警是否已配置，发布后能否在几分钟内发现异常。核心指标与告警齐备评1分；部分指标缺失评2分；缺少关键监控、只能靠用户反馈发现问题评3分。
历史故障与相似变更经验
看同类变更过去是否出过故障、本次是否吸取了既往教训。无相关故障历史评1分；有过问题但已针对性加固评2分；同类变更近期反复出问题评3分。
风险等级划分与必填、选填字段
风险等级由各维度评分汇总得出，并决定审批层级和发布要求。建议以最高单项评分作为等级下限，防止平均分掩盖单点高风险。
| 风险等级 | 判定标准 | 审批与发布要求 |
|---|---|---|
| 低 | 各维度评分均为1分，或仅个别维度为2分且无3分项 | 发布负责人审批即可；可按常规窗口发布；回滚预案简要记录 |
| 中 | 存在2分项且无3分项，或整体判断需要额外关注 | 需技术审批人签字；选择低峰窗口发布；回滚预案需明确触发条件与步骤；发布期间安排值班观察 |
| 高 | 任一维度评3分，或多项2分叠加导致整体风险偏高 | 需技术审批人与业务审批人共同签字；避开业务高峰并提前通知相关方；回滚预案需演练或逐项确认；发布后设置观察期 |
必填字段包括：发布单号、变更名称、负责人、计划发布窗口、八个维度的评分与说明、最高单项评分、汇总风险等级、评估结论、回滚触发条件、回滚步骤与责任人、发布负责人签字。这些字段缺失时评估表不成立，不能进入发布流程。
选填字段包括：业务审批人签字（低风险发布可不填）、回滚验证方式（回滚步骤简单时可并入步骤说明）、关联需求或工单编号、灰度范围说明、发布后观察指标清单。选填字段按变更类型取舍，例如涉及数据迁移的发布应补充数据校验方式，纯前端样式调整可省略灰度说明。
填写示例：一次中等风险发布
以下为演示情景，不对应真实企业发布记录。背景：某业务系统调整订单列表的筛选逻辑，涉及前端页面与一个后端查询接口，计划在工作日上午低峰期发布。
| 字段 | 填写内容 |
|---|---|
| 发布单号 | REL-2024-0312 |
| 变更名称 | 订单列表筛选逻辑调整 |
| 负责人 | 张明（后端） |
| 计划发布窗口 | 周三 10:00–11:00 |
| 变更范围与影响面 | 评分2：影响使用订单列表的运营人员，不涉及下单与支付链路 |
| 技术复杂度与依赖 | 评分2：前端页面与查询接口联动，需两个小组配合发布 |
| 测试与验证充分性 | 评分2：主流程回归通过，边界筛选条件仅部分覆盖 |
| 数据与配置变更 | 评分1：无表结构变更，仅新增一个查询参数开关 |
| 回滚可行性 | 评分1：保留上一版本镜像，回滚操作已在上次发布中验证 |
| 发布窗口与资源 | 评分1：工作日上午低峰期，前后端各有一人值班 |
| 监控与告警就绪度 | 评分2：接口错误率告警已配置，筛选结果准确率暂无自动监控 |
| 历史故障与相似变更经验 | 评分2：半年前类似筛选改动出现过一次结果偏差，已补充测试用例 |
| 最高单项评分 | 2 |
| 汇总风险等级 | 中 |
| 评估结论 | 补充措施后发布：发布后一小时内人工抽查筛选结果 |
| 回滚触发条件 | 接口错误率超过阈值，或运营反馈筛选结果明显错误 |
| 回滚步骤与责任人 | 后端回退接口版本，前端回退页面资源，由张明执行、李华确认 |
| 回滚验证方式 | 回滚后抽查三个典型筛选条件，确认结果与上一版本一致 |
| 审批记录 | 发布负责人张明签字；技术审批人李华签字；业务审批人按中风险要求由运营主管王芳签字 |
这份示例展示了评分与结论之间的对应关系：没有3分项，但存在多个2分项，因此定为中风险，要求技术审批、低峰窗口、明确回滚触发条件和发布后人工抽查。若“测试与验证充分性”评为3分，则整体应升为高风险，需要业务审批并考虑推迟发布。
模板调整与维护方法
模板需要在团队实际使用中校准，否则容易出现评分普遍偏低、审批流于形式的情况。调整围绕维度、阈值和字段三个对象展开，并保留变更记录。
维度增删与权重调整
按变更类型增删维度。例如以数据类发布为主的团队，可把“数据与配置变更”拆分为“数据结构变更”和“数据迁移”两项；以客户端发布为主的团队，可增加“应用商店审核与灰度覆盖”维度。权重调整可通过给关键维度设置一票定级实现，即该维度评3分时整体直接定为高风险，不必等待汇总计算。
等级阈值校准
每季度回看已发布变更的实际结果：被定为低风险却出现故障的发布，说明某些维度评分偏低或阈值过松；被定为高风险但从未出问题的发布，可检查是否存在过度保守。校准依据是实际故障记录与评估结论的偏差，而非主观感受。调整阈值后应在新一轮发布中试运行，再正式替换。
评审后复盘回写模板
每次发布结束后，在复盘环节对照评估表检查：哪些维度准确预警了问题，哪些维度漏判。把结论回写到模板说明中，例如补充某类变更的典型评分参考，或新增一条回滚触发条件。回写内容应具体到字段和判断口径，避免只写“加强评估”这类无法执行的结论。
版本与责任人管理
模板本身应有版本号和责任人。每次调整记录变更内容、生效日期和调整原因，旧版本保留可查。责任人负责收集使用反馈并组织季度校准。若团队使用文档工具承载模板，可借助 ONES Wiki 的页面模板库一键创建制式化文档，并用页面版本记录每次调整，需要时查看或回滚到历史版本；评估表作为发布单的关联文档，与需求、任务进度对应，评审签字和回滚预案在同一页面留痕，便于发布后追溯。文档页面的版本回滚用于管理模板与记录本身，与发布回滚是两件不同的事，模板中应分别说明。
常见问题
八个评估维度是否必须全部保留，团队可以只选其中几项吗？
八个维度是通用框架，覆盖影响面、技术依赖、验证、数据、回滚、窗口、监控和历史经验。团队可以按变更类型增删，例如以数据迁移为主的发布可把“数据与配置变更”拆成两项，客户端发布可增加应用商店审核相关维度。调整时保持两点：一是维度之间尽量不重叠，二是每个维度都有明确的评分口径，否则不同发布单之间无法比较。删减后应在模板版本记录中写明原因和生效日期。
评分时多个维度都是2分，但没有任何3分项，应该定为中风险还是高风险？
按模板规则，没有3分项时通常定为中风险，但需要结合整体判断。如果多个2分项集中在同一条链路上，例如技术依赖复杂、测试覆盖不足、监控又不完整，风险会叠加，可以上调为高风险。建议在模板中增加一条说明：当2分项达到三项及以上且涉及核心链路时，由技术审批人决定是否升级。这样既保留规则的一致性，也给评审留出判断空间。
回滚预案写到什么程度才算合格，低风险发布可以简化吗？
回滚预案至少写清三件事：触发条件、执行步骤与责任人、回滚后的验证方式。低风险发布可以简化记录，例如把验证方式并入步骤说明，但触发条件和责任人不能省略。中风险发布要求明确触发条件与步骤，并安排发布期间值班观察；高风险发布要求回滚预案经过演练或逐项确认。判断标准是：发布当晚由另一位同事拿着预案也能执行回滚，就达到了可用的程度。
评估表放在文档里填写，评审签字和后续追溯怎么留痕？
常见做法是把评估表作为发布单的关联文档，评审签字、回滚预案和发布后观察记录都留在同一页面。ONES Wiki 支持页面模板库一键创建制式化文档，并记录页面版本，可查看或回滚到历史版本；文档页面还能嵌入任务进度与报表，需求与文档互相对应。需要注意，文档页面的版本回滚用于管理模板和记录本身，与发布回滚是两件事，模板中应分别说明，避免执行时混淆。
模板用了一段时间后评分普遍偏低，怎么校准？
先回看实际结果：被定为低风险却出现故障的发布，检查是哪个维度评分偏低或阈值过松；被定为高风险但长期无问题的发布，检查是否过度保守。校准依据是故障记录与评估结论的偏差，调整后先在新一轮发布中试运行，再正式替换。建议每季度做一次，并把调整内容、生效日期和原因写入版本记录，旧版本保留可查。
