线上严重缺陷发生时，热修复要在尽量短的时间内完成修复，同时保证改动可追溯、可回退。本文按问题确认、修复分支、验证、发布、回滚五个阶段给出端到端设计，说明每个阶段的输入、负责人、产出记录与完成标志，并附角色矩阵、工单示例和完成检查清单。文中会自然提及ONES在热修复工单与发布记录衔接上的支持方向。
要点总览（TL;DR）
- 热修复按问题确认、修复分支、验证、发布、回滚五个阶段设计，五个阶段共用一张热修复工单，所有改动、验证结论和发布记录挂在这张工单下。
- 问题确认阶段先做定级和影响面评估，再判断是否走热修复；不满足准入条件的缺陷回到常规迭代修复，替代处理同样记录在工单里。
- 修复分支从线上运行版本对应的基线拉出，坚持最小改动原则，发布稳定后及时回合并主干并记录结果。
- 验证按单元、接口、回归、线上四层安排，配合灰度或小流量放量；发布前必须准备好回滚预案，明确回退方式、步骤、影响和责任人。
- 流程是否可用，按准入规则、分支规范、验证模板、回滚预案、工单记录、复盘机制、角色授权和演练八项逐条核对。
热修复流程的核心答案与五阶段步骤
热修复流程可以按五个阶段串起来：问题确认、修复分支、验证、发布、回滚。每个阶段都要有明确的输入、负责人、产出记录和完成标志，五个阶段共用一张热修复工单，所有改动、验证结论和发布记录都挂在这张工单下，保证事后能追溯、能回退、能复盘。
设计时先解决一个分流问题：并非所有线上问题都走热修复。判断依据是缺陷严重程度、影响用户范围、是否存在可接受的临时规避手段。满足准入条件的进入热修复通道，不满足的回到常规迭代修复。分流判断放在问题确认阶段完成，避免修复做到一半才发现不该走紧急通道。
下表给出五阶段流程总览，可作为流程文档的第一页。
| 阶段 | 输入 | 关键动作 | 负责人 | 产出物 | 完成标志 |
|---|---|---|---|---|---|
| 问题确认 | 线上告警、用户反馈、监控异常 | 定级、评估影响面、判断是否走热修复 | 值班负责人，决策人审批 | 热修复工单（含现象、影响范围、版本、发现时间） | 准入结论明确，工单已指派修复开发 |
| 修复分支 | 线上运行版本对应的基线、热修复工单 | 从基线拉修复分支，做最小改动，关联工单 | 修复开发 | 修复分支、代码改动记录、自测说明 | 改动提交完成，自测通过，分支已关联工单 |
| 验证 | 修复分支构建产物、定向验证用例 | 分层验证，必要时灰度或小流量放量 | 验证人 | 验证记录、灰度观察数据 | 各层验证通过，灰度指标正常 |
| 发布 | 验证通过的制品、回滚预案 | 选择发布窗口，走紧急审批，执行发布并观察 | 发布负责人 | 发布记录、观察指标记录 | 观察期内指标稳定，发布确认完成 |
| 回滚 | 发布记录、回滚预案、观察异常信号 | 判断是否触发回滚，执行回退，处置后续 | 发布负责人，决策人确认 | 回滚记录、复盘记录 | 服务恢复，复盘结论归档 |
回滚阶段在流程上排在最后，但回滚预案必须在发布之前准备好。流程设计时把回滚当作发布的配套动作，而不是出问题后的临时补救，这样紧急发布才真正可控可退。
问题确认：定级、影响面与是否走热修复
问题确认阶段要回答三个问题：缺陷有多严重、影响多少用户和业务、是否值得走热修复通道。这一步做扎实，后续的紧急审批和资源投入才有依据。
定级标准建议按业务影响划分，而不是只看技术现象。例如：核心交易链路不可用、大面积用户无法登录、数据错误导致资金或订单异常，属于最高级别；部分功能异常但有替代路径、影响范围局限在少数用户，属于次一级；界面显示问题、非核心功能异常，通常不进入热修复。定级结果直接决定审批层级和发布窗口的紧迫程度。
影响面评估至少覆盖四个维度：受影响用户或租户的数量与比例、受影响的业务功能与交易金额、是否涉及数据正确性、是否已有用户投诉或对外可见的故障。评估结论写进工单，作为准入判断的依据。
热修复准入条件可以写成清单，逐项核对：
- 缺陷已复现或现象明确，能定位到具体版本和模块；
- 影响达到定级标准中的紧急级别；
- 没有可接受的临时规避方案，或规避方案成本高于热修复；
- 修复改动范围可控，能在约定时间内完成验证；
- 回滚方案可行，回退不会造成更大影响。
不满足准入条件时，替代处理包括：通过配置开关或流量调度临时止损、把修复排入最近的常规迭代、对受影响用户做告知和补偿。这些处理同样要记录在工单里，说明不走热修复的理由。
问题确认阶段的记录字段建议包含：现象描述、首次发现时间、发现来源、影响范围、涉及版本、定级结论、准入判断、确认人与决策人。确认人负责收集信息和给出初步判断，决策人负责批准是否进入热修复通道以及授权紧急审批。两个角色分开，避免一线人员独自承担放行责任。
修复分支怎么拉：最小改动与版本基线管理
修复分支必须从线上正在运行的版本对应的基线拉出，而不是从主干最新代码拉。线上版本与基线一一对应，修复分支基于这个基线，才能保证发布内容只包含本次修复，不夹带主干上尚未验证的改动。
分支命名建议包含工单编号和版本信息，例如 fix/工单号-版本号，便于从分支反查工单、从工单定位分支。分支创建后立即在热修复工单中登记分支地址和基线版本，形成关联。
最小改动原则是这一阶段的核心约束。具体做法包括：只修改与缺陷直接相关的代码；不顺手重构、不升级依赖、不调整无关配置；如果修复必须引入较大改动，回到问题确认阶段重新评估是否适合热修复。改动范围越大，验证成本和回滚风险越高，紧急通道承受不了这种不确定性。
修复开发完成自测后，提交改动说明和自测结论，工单状态流转到待验证。修复完成后向主干回合并的时机，建议在发布验证通过、线上观察稳定之后进行，回合并时把修复分支的提交 cherry-pick 或合并到主干，并在工单中记录回合并结果，避免主干长期缺失该修复、下次常规发布时缺陷复现。
分支操作规范可以归纳为四条：来源固定为线上版本基线；命名带工单号；改动边界以缺陷相关代码为限；发布稳定后及时回合并主干并记录。
验证环节：分层验证与灰度放量
热修复的验证时间被压缩，但验证层次不能省。建议按单元、接口、回归、线上四层安排，每层有明确的通过标准和负责人。
| 验证层 | 验证内容 | 通过标准 |
|---|---|---|
| 单元验证 | 修复代码的单元测试、边界条件 | 新增或修改的用例全部通过 |
| 接口验证 | 缺陷相关接口的请求响应、异常分支 | 接口行为符合预期，无新增报错 |
| 回归验证 | 缺陷所在模块及关联功能的核心用例 | 核心用例通过，无新增缺陷 |
| 线上验证 | 灰度或小流量环境下的真实请求 | 观察指标正常，缺陷现象消失 |
定向验证用例要围绕缺陷场景设计，覆盖缺陷复现路径、修复后的预期行为、以及相邻的边界场景。用例写在工单里，验证人逐条执行并记录结果，避免只凭经验点一遍就放行。
灰度或小流量放量的判断依据包括：缺陷影响的核心链路是否在灰度范围内、灰度用户或流量是否具有代表性、观察指标是否设置了明确的正常区间。灰度期间重点观察错误率、响应时间、关键业务成功率，指标回到正常区间并保持一段时间后，再决定全量发布。
验证不通过时，流程退回修复开发，在同一个修复分支上继续修改，重新走分层验证。退回原因记录在工单中，如果连续多次验证不通过，说明修复方案本身可能有问题，应升级到决策人重新评估是否继续走热修复。
发布与回滚：窗口、审批、观察与回退触发
发布窗口的选择要兼顾业务低峰和修复紧迫性。影响核心交易的缺陷应尽快发布，可以选择流量低谷时段执行；影响面有限但需要当天处理的缺陷，可以安排在业务低峰窗口。窗口选择结论和理由记录在工单中。
紧急审批路径要提前定义：谁有权批准热修复发布、审批需要看哪些材料（工单、验证记录、回滚预案）、审批时限是多少。审批人确认材料齐全后放行，审批记录留在工单里，事后可查。
发布前必须准备好回滚预案，内容包括：
- 回退方式：回退到上一版本制品、关闭功能开关、回滚数据库变更等，明确采用哪一种；
- 回退步骤：按顺序列出操作命令或操作入口，确保执行人不需要临场判断；
- 回退影响：回退期间的服务状态、可能丢失的数据、需要通知的对象；
- 回退责任人：谁执行、谁确认。
发布后进入观察期，观察指标至少包括错误率、响应时间、核心业务成功率、告警数量。观察时长根据缺陷影响面设定，核心链路建议覆盖一个业务高峰周期。观察期内指标稳定，发布确认完成；指标异常且与本次修复相关，触发回滚。
回滚触发条件建议写成可判断的规则，例如：错误率超过阈值并持续一定时间、核心业务成功率低于基线、出现新的严重告警。触发后由发布负责人执行回退，决策人确认回退范围，回退完成后记录回退时间、回退方式、服务恢复情况。回滚不是流程终点，回滚后要重新评估缺陷、分析回退原因，把结论写入复盘记录。
角色分工与各阶段交付物
热修复节奏快，角色职责必须提前定清楚，否则容易出现发现问题的人不敢定级、修复的人不知道找谁验证、发布的人找不到审批人的情况。下表给出角色职责矩阵。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 问题发现人 | 报告现象、提供复现信息、配合确认影响范围 | 问题描述与复现步骤 |
| 值班负责人 | 组织问题确认、给出定级建议、协调资源 | 定级结论、影响面评估 |
| 决策人 | 批准是否走热修复、授权紧急审批、确认回滚 | 准入审批记录、发布审批记录 |
| 修复开发 | 拉修复分支、完成最小改动、自测、回合并主干 | 修复分支、改动说明、自测记录 |
| 验证人 | 设计定向用例、执行分层验证、记录灰度观察 | 验证记录、灰度观察数据 |
| 发布负责人 | 准备回滚预案、执行发布、观察指标、执行回退 | 发布记录、回滚预案、回滚记录 |
各阶段交付物统一留存到热修复工单：问题确认记录、分支与改动记录、验证记录、发布与观察记录、回滚记录、复盘记录。留存要求是每个交付物有提交人、提交时间和结论，不能只留一句“已处理”。
跨角色交接要有确认动作：修复开发提交验证时在工单中@验证人并附自测结论；验证通过后由验证人更新工单状态并通知发布负责人；发布完成后发布负责人回填观察结果。每次交接以工单状态变更为准，口头沟通作为补充。
紧急情况下的授权与升级路径要写进流程：值班负责人无法判断定级时升级到决策人；修复方案超出最小改动范围时升级重新评估；发布后指标异常且回滚预案不足以恢复时，升级到技术负责人组织应急处置。升级路径明确到角色，不依赖个人。
记录要求与一次完整热修复示例
热修复工单是整条流程的记录载体，字段设计要能支撑追溯和复盘。建议包含以下字段：
| 字段 | 填写要求 |
|---|---|
| 缺陷现象 | 用户可见的表现、复现步骤、首次发现时间 |
| 影响范围 | 受影响用户或租户、业务功能、是否涉及数据 |
| 涉及版本 | 线上运行版本号与对应基线 |
| 定级与准入结论 | 定级结果、是否走热修复、决策人 |
| 修复分支 | 分支地址、基线版本、改动文件清单 |
| 验证记录 | 各层验证结果、定向用例执行情况、灰度数据 |
| 发布记录 | 发布窗口、审批人、发布制品版本、观察指标 |
| 回滚预案与回滚记录 | 回退方式、触发条件、实际是否回滚及结果 |
| 复盘记录 | 根因、流程改进项、责任人、完成时间 |
以下示例为演示情景，用于说明字段如何填写，不代表真实案例。
某系统在晚间出现部分用户支付失败。问题发现人提交现象：支付接口返回错误，复现步骤明确，首次发现时间为当晚 20:15。值班负责人评估影响面：受影响用户约占当日支付用户的 8%，涉及订单金额较大，判定为紧急级别，决策人批准走热修复。工单记录涉及版本为当前线上版本，准入结论为进入热修复通道。
修复开发从线上版本基线拉出 fix/工单号-版本号 分支，定位到一处参数校验逻辑错误，只修改该处代码，提交改动说明并完成自测。验证人按定向用例执行单元、接口、回归验证，全部通过后在灰度环境放量 10% 流量，观察支付成功率回到正常区间。发布负责人在业务低峰窗口执行发布，发布前准备好回退到上一版本制品的预案，发布后观察一个业务高峰周期，指标稳定，发布确认完成。修复分支在稳定后回合并到主干，工单记录回合并结果。
复盘记录写明根因、本次流程中验证用例覆盖不足的问题，以及补充用例、调整灰度比例等改进项和责任人。所有记录关联在同一张工单下，后续查询该缺陷时可以直接看到从发现到复盘的完整链路。
在工具层面，ONES 通过统一的业务需求池、产品需求池与工单系统支撑需求—任务—测试—缺陷的闭环，研发团队可以在任务和工单中完成开发、测试与修复；其流水线集成覆盖代码拉取、构建、自动化测试到部署发布，并支持与 Jenkins 等工具对接，便于把修复分支的构建与发布状态回填到同一工作项。具体字段模板和流程配置需按实际部署核验。
完成检查：流程可用的验收清单
热修复机制是否建立并可用，可以按下面的清单逐项核对。每项都应有对应的文档、模板或记录，而不是停留在口头约定。
- 流程与准入规则已成文：五阶段流程、定级标准、热修复准入条件、不走热修复的替代处理均有书面说明，并经过相关角色确认。
- 分支规范已落地：修复分支来源、命名规则、最小改动约束、回合并主干要求写入研发规范，团队按此执行。
- 验证模板可用：分层验证清单和定向用例模板已提供，验证人可以直接填写执行结果。
- 发布与回滚模板可用：发布检查项、回滚预案模板包含触发条件、回退步骤和责任人，发布前必须填写。
- 记录可追溯：热修复工单字段完整，缺陷、分支、验证、发布、回滚记录能关联到同一工单，任意一次热修复都能还原全过程。
- 复盘机制运行：每次热修复后产出复盘记录，改进项有责任人和完成时间，并跟踪关闭。
- 角色与授权明确：各阶段负责人、决策人、升级路径已公布，紧急审批路径经过确认。
- 演练或试运行已完成：至少用一次模拟缺陷走通从问题确认到回滚的完整流程，记录演练中发现的问题并修正流程。
清单全部满足，说明热修复流程具备执行条件；存在缺项时，优先补齐准入规则、回滚预案和工单记录三项，它们直接决定紧急发布是否可控可退。
常见问题
线上问题很多，怎么避免热修复通道被滥用？
把准入判断放在问题确认阶段，用清单逐项核对：缺陷能定位到具体版本和模块、影响达到紧急级别、没有可接受的临时规避方案、改动范围可控、回滚方案可行。任何一项不满足，就回到常规迭代修复，或先用配置开关、流量调度做临时止损。准入结论和理由写进工单，由决策人批准，避免一线人员独自放行。
修复分支已经发布上线，主干上的代码什么时候合并回去？
建议在发布验证通过、线上观察稳定之后回合并主干。回合并时把修复分支的提交 cherry-pick 或合并到主干，并在工单中记录回合并结果。这样主干不会长期缺失该修复，下次常规发布时缺陷不会复现。如果回合并过程中发现主干代码已变化、冲突较大，应重新评估改动范围，必要时升级到决策人确认处理方式。
灰度观察多久、看哪些指标才算验证通过？
观察时长按缺陷影响面设定，核心链路建议覆盖一个业务高峰周期。观察指标至少包括错误率、响应时间、核心业务成功率、告警数量，并为每项设置明确的正常区间。灰度期间指标回到正常区间并保持一段时间，再决定全量发布；指标异常且与本次修复相关，触发回滚。灰度用户或流量要具有代表性，缺陷影响的核心链路应包含在灰度范围内。
回滚之后，这次热修复算结束了吗？
回滚不是流程终点。回退完成后要记录回退时间、回退方式和服务恢复情况，然后重新评估缺陷、分析回退原因，把结论写入复盘记录。复盘要写明根因、本次流程中暴露的问题（例如验证用例覆盖不足、灰度比例不合理），以及改进项、责任人和完成时间，并跟踪关闭。回滚记录和复盘记录与本次热修复的其他记录关联在同一张工单下。
团队规模不大，这套流程能不能简化？
可以按实际团队情况裁剪执行形式，但几个关键控制点建议保留：准入判断要有明确结论和批准人；修复分支从线上版本基线拉出并关联工单；发布前准备好回滚预案；发布后有观察指标和观察时长。角色可以由同一人兼任，但决策与执行分开记录，避免自己批准自己发布。流程文档可以先从一页纸的五阶段总览和一张工单模板起步，运行几次后再补充细化。
