热修复发布流程要解决的是紧急缺陷与发布秩序之间的冲突：既让影响线上业务的问题尽快修复，又保留必要的评审、验证和回退准备。本文按缺陷定级与准入、修复分支与最小改动、验证与回归、灰度发布与观察、全量与回退、复盘归档六个环节展开，说明每一步的输入、动作、产出和完成标志，适用于处于版本交付与维护阶段的研发团队。
要点总览（TL;DR）
- 热修复准入要同时满足三个条件：影响线上核心业务或大量用户、严重级别达到团队约定门槛、无法等到下一个常规版本；仅因催促而绕开评审不属于合理准入。
- 流程主干为六步：缺陷定级与准入、修复分支与最小改动、验证与回归范围、灰度发布与观察、全量与回退准备、事后复盘与版本归档，每步都要有输入、动作、产出和完成标志。
- 热修复可以压缩评审会议、缩小回归范围、缩短观察时长，但代码评审、验证记录、发布审批和回退预案四项控制点必须保留。
- 角色分工要落到缺陷提出方、研发负责人、修复研发、测试、发布负责人、运维/值班和业务方，紧急授权需事先约定批准人、补审时限和归档位置。
- 发布前、发布中、发布后三段检查由发布负责人确认，重点防住跳过回归、灰度范围过窄、回退预案缺失和记录不留痕四类失效点。
热修复发布流程的核心步骤与准入条件
热修复不是常规发布的替代通道，而是一条控制点保留、评审强度压缩的快速路径。判断一次缺陷是否走热修复，需要同时看三个条件：影响范围是否涉及线上核心业务或大量用户，严重级别是否达到团队事先约定的热修复门槛，以及缺陷能否等到下一个常规版本发布。三者缺一不可。仅因为业务方催促、时间紧就绕开评审，属于准入判断失效，而不是合理的热修复。
准入通过后，按以下六步推进。每一步都要有明确输入、动作、产出和完成标志，缺一项就视为该步骤未完成。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 缺陷定级与准入 | 缺陷单、影响范围说明、线上现象记录 | 确认严重级别，判断影响范围与能否等待常规版本，给出是否走热修复的结论 | 热修复工单，含定级结论与准入理由 | 研发负责人与测试共同确认准入，工单状态进入“已批准” | 缺陷提出方发起，研发负责人审批 |
| 2. 修复分支与最小改动 | 热修复工单、当前线上版本对应的代码基线 | 从线上版本基线拉出修复分支，只改与缺陷直接相关的代码，附改动说明 | 修复分支、改动说明、代码评审记录 | 代码评审通过，改动范围经评审确认无夹带 | 修复研发，评审人复核 |
| 3. 验证与回归范围 | 修复分支构建产物、缺陷复现步骤 | 验证缺陷已修复，并按影响面确定回归范围，执行回归用例 | 验证记录，含修复验证结论与回归用例清单 | 缺陷验证通过，约定回归范围内的用例全部通过 | 测试负责人 |
| 4. 灰度发布与观察 | 通过验证的构建产物、灰度方案 | 按预设范围发布灰度，观察约定指标与时长，判断是否放量 | 灰度发布记录，含观察指标数据与放量结论 | 观察期内指标符合放量条件，发布负责人确认放量 | 发布负责人，运维/值班配合 |
| 5. 全量与回退准备 | 灰度结论、回退预案 | 全量发布，同时保持回退预案可执行；出现触发条件立即回退 | 全量发布记录、回退预案执行状态 | 全量发布完成且观察期平稳，或按预案完成回退并记录 | 发布负责人，运维/值班执行 |
| 6. 事后复盘与版本归档 | 全流程记录、监控数据 | 复盘缺陷根因与流程执行情况，将修复合并回主干，归档发布记录 | 复盘记录、归档后的版本记录 | 复盘结论与改进项登记完成，修复已合入主干 | 研发负责人组织，各角色参与 |
热修复与常规发布的差异在评审强度，不在控制点数量。常规发布可以按计划做完整的需求评审、多轮测试和分批放量；热修复可以压缩评审会议、缩小回归范围、缩短观察时长，但代码评审、验证记录、发布审批和回退预案这四项必须保留。把“简化”理解为“取消”，是热修复流程最常见的失控起点。
角色分工与各环节交付物
热修复节奏快，角色边界如果靠口头约定，容易出现“谁都以为别人确认过”的空档。建议在流程启动前就把发起、审批、修复、验证、发布、复盘六类职责落到具体角色，并规定每个角色留下的记录形式。
| 角色 | 主要职责 | 关键交付物 | 记录留存位置 |
|---|---|---|---|
| 缺陷提出方（业务方或值班） | 描述线上现象、影响范围与业务损失，发起热修复申请 | 缺陷单、影响范围说明 | 缺陷工作项 |
| 研发负责人 | 审批准入、指派修复人、组织复盘 | 准入结论、修复指派记录、复盘记录 | 热修复工单、复盘文档 |
| 修复研发 | 拉修复分支、完成最小改动、提交代码评审 | 修复分支、改动说明、评审记录 | 代码仓库与评审记录 |
| 测试 | 验证缺陷修复、确定并执行回归范围 | 验证记录、回归用例清单 | 测试记录，关联热修复工单 |
| 发布负责人 | 制定灰度方案与回退预案、执行发布、确认放量与回退 | 灰度方案、发布记录、回退预案 | 发布记录文档 |
| 运维/值班 | 执行发布操作、监控指标、按触发条件发起回退 | 监控数据、操作日志、回退执行记录 | 监控平台与发布记录 |
| 业务方 | 确认业务影响、参与灰度观察、验收修复效果 | 业务验收意见 | 热修复工单的验收记录 |
紧急情况下可以启用先发布后补审的授权机制，但需要事先写清三件事：谁有权批准这种授权，补审的时限是多久，补审记录归档到哪里。授权只针对发布审批这一环，代码评审和验证记录仍应在发布前完成；如果确实来不及，补审范围要明确覆盖这两项，并由研发负责人跟踪到关闭。授权记录本身也是交付物，不能只存在于即时通讯的聊天记录里。
当缺陷、修复分支、验证记录和发布记录分散在不同工具中时，状态流转容易断档。ONES 可以把热修复工单作为工作项承载定级、审批和验收状态，把验证记录、灰度方案与回退预案作为关联文档随工单流转，让每个环节的负责人和产出在同一处可查，减少靠人工同步进度造成的遗漏。
一次热修复的完整示例
以下为演示情景，用于说明流程如何落地，不代表真实案例。某在线服务在晚间出现部分用户提交订单后状态未更新的问题，值班人员从监控告警和用户反馈中确认现象，随即发起热修复申请。
20:10 缺陷定级与准入。值班人员提交缺陷单，记录受影响功能、出现时间与初步影响范围。研发负责人判断该问题影响订单状态展示，属于核心交易链路，严重级别达到热修复门槛，且无法等待下一个常规版本，批准走热修复通道。热修复工单状态变为“已批准”，指派修复研发。
20:25 修复分支与最小改动。修复研发从当前线上版本基线拉出修复分支，定位到状态更新逻辑中的一处判断条件错误，只修改该条件并补充一条针对性单元测试。改动说明写明修改点、影响函数与不涉及的范围。评审人在线完成代码评审，确认改动无夹带。
20:50 验证与回归范围。测试在预发环境按缺陷复现步骤验证修复生效，并根据影响面确定回归范围：订单提交、状态查询、状态变更通知三条主链路。回归用例执行完毕，全部通过，验证记录关联到热修复工单。
21:20 灰度发布与观察。发布负责人提前写好灰度方案：先发布到一小组实例，观察订单状态更新成功率与错误日志数量，观察期设定为团队约定的时长，指标平稳才放量。灰度期间指标正常，发布负责人确认放量。
21:50 全量与回退准备。全量发布前，回退预案已写明触发条件：状态更新成功率低于约定阈值或错误日志出现同类异常即回退，回退操作由值班人员执行。全量发布后观察期内指标平稳，未触发回退。
次日 10:00 复盘与归档。研发负责人组织复盘，确认根因为边界条件未覆盖，改进项包括补充该类场景的自动化用例。修复分支合并回主干，热修复工单、验证记录、灰度数据与发布记录一并归档到对应版本记录下，形成可追溯的完整链路。
热修复流程的完成检查与常见失效点
热修复是否真正完成，不能只看“线上恢复了”。建议按发布前、发布中、发布后三段逐项核对，检查结果由发布负责人确认，证据随发布记录归档。
| 阶段 | 检查项 | 通过标准 |
|---|---|---|
| 发布前 | 准入结论是否记录 | 热修复工单含定级结论与准入理由，审批人明确 |
| 发布前 | 改动范围是否受控 | 修复分支基于线上版本基线，代码评审通过，改动说明完整 |
| 发布前 | 验证与回归是否完成 | 缺陷验证通过，约定回归范围内用例全部通过并有记录 |
| 发布前 | 灰度方案与回退预案是否就绪 | 观察指标、观察时长、放量条件、回退触发条件均已写定 |
| 发布中 | 灰度观察是否按方案执行 | 观察数据有记录，放量判断有依据，未擅自扩大灰度范围 |
| 发布中 | 回退通道是否可用 | 回退操作人和操作方式明确，触发后能按预案执行 |
| 发布后 | 全量观察是否平稳 | 观察期内关键指标正常，无同类异常复现 |
| 发布后 | 复盘与归档是否完成 | 复盘记录含根因与改进项，修复已合回主干，记录归档到版本下 |
流程失效通常集中在四个位置。跳过回归：只验证缺陷本身，未检查修复是否影响相邻功能，控制点是把回归范围写进验证记录并作为发布前置条件。灰度范围过窄：灰度实例与真实流量特征差异大，观察不到问题，控制点是在灰度方案中说明灰度范围的选择依据。回退预案缺失：发布后才发现无法快速回退，控制点是把回退触发条件与操作人写进发布前检查项。记录不留痕：关键判断只存在于聊天记录，事后无法追溯，控制点是把每步产出关联到热修复工单或发布记录，由发布负责人在关闭工单前核对完整性。
常见问题
热修复和常规发布在评审上到底能简化到什么程度？
可以简化的是评审形式和覆盖广度：减少评审会议次数、缩小回归用例范围、缩短灰度观察时长。需要保留的是四项控制点：代码评审、验证记录、发布审批和回退预案。判断标准是看这次简化是否让某个控制点失去可核验的记录，如果代码改动没有评审记录、回归结果没有留档、发布没有审批人、回退没有触发条件，就超出了合理简化的范围。
紧急情况下先发布后补审，补审应该覆盖哪些内容？
先发布后补审通常只针对发布审批这一环。补审范围至少要覆盖发布前未能完成的代码评审和验证记录，并明确补审时限、补审责任人和记录归档位置。补审记录本身也是交付物，应关联到热修复工单，由研发负责人跟踪到关闭。如果补审只补审批签字、不补代码评审和验证，等于把风险留在了线上。
灰度观察多久、放量多少才合适？
这类参数没有统一标准，取决于业务流量特征、系统规模和缺陷影响面。可操作的做法是在灰度方案里事先写定三件事：观察哪些指标、观察多长时间、满足什么条件才放量。灰度范围的选择依据也要写清楚，避免灰度实例与真实流量差异过大导致观察不到问题。观察期和放量条件一旦写定，发布过程中按方案执行，不临时扩大灰度范围。
热修复完成后，修复分支和记录应该怎么处理？
复盘结束后，修复分支要合并回主干，避免下次常规版本发布时把这次修复覆盖掉。热修复工单、验证记录、灰度数据、发布记录和复盘结论应归档到对应版本记录下，形成可追溯的链路。归档不是走形式，它决定了下次出现同类缺陷时能否快速查到当时的判断依据和改动范围。
小团队人手少，六步流程能不能合并？
可以合并执行动作，但要保留每一步的产出。例如同一人兼任修复研发和发布负责人时，代码评审仍需由另一人完成，验证记录和发布记录仍要分别留档。合并的是人手，不是控制点。团队规模较小时，可以把准入判断和修复指派放在同一次沟通中完成，但准入结论要落到工单上，不能只停留在口头。
