线上紧急修复的发布流程与记录要求

线上出现严重缺陷时，热修复通道要同时做到两件事：把发布链路压到最短，把记录留到最全。可执行的做法是：确认故障等级并授权启动，从线上版本对应的基线拉出热修复分支，修复后做针对性验证与最小范围回归，经授权人批准后灰度发布并观察，异常时按预案回滚。全程至少留存六类记录：故障与定级、修复分支与提交、验证结论、发布审批、发布与观察结果、回滚或收尾复盘。

要点总览（TL;DR）

• 热修复通道要窄而快：先按影响面和可等待性确认故障等级，由授权人书面批准启动，并限定本次只做最小变更。
• 修复分支从线上运行版本对应的基线拉出，提交关联缺陷单；验证通过后按约定时机合并回主干，防止下次常规发布覆盖修复。
• 验证分两层：针对缺陷路径定向验证，再对与变更相关的核心链路做最小回归；审批与发布执行分离，灰度阶段预设观察指标与回滚阈值。
• 全程至少留存六类记录：故障与定级、分支与提交、验证结论、发布审批、发布与观察结果、回滚或收尾复盘，每类明确责任人与存放位置。
• 流程是否可用，看一次热修复结束后能否在同一处查到从故障发现到发布收尾的完整证据链，且下次常规发布不会覆盖本次修复。

热修复通道怎么设：触发条件与授权

热修复通道的价值在于“快”，前提是入口足够窄。如果任何缺陷都能走紧急发布，审批会流于形式，记录也会被省略。建议在流程文件中先写清触发条件，再指定授权人，最后划出与常规发布的边界。

触发条件通常围绕影响面和可等待性判断：核心业务功能不可用或严重降级、资金或数据出现错误、大量用户受影响、存在安全风险，且常规发布周期内无法等待。缺陷等级可按组织既有口径划分，例如将“线上严重缺陷”定义为影响核心链路且有持续扩大趋势的问题。定级由值班或一线提交初判，由授权人确认，避免单人凭感觉启动。

授权人应是熟悉线上风险的管理角色，例如技术负责人或发布负责人，并在流程文件中列明备份授权人，保证非工作时间也能启动。审批人与后续发布执行人宜分开设置，形成相互制约。

项目	规则建议	启动时需产出
触发条件	核心功能不可用、资金或数据错误、大范围用户受影响、安全风险，且无法等待常规发布	故障单，含现象、影响范围、初判等级
定级确认	值班初判，授权人确认等级；等级调整需留痕	定级结论与确认时间
启动授权	授权人书面确认启动热修复，并指定修复负责人、验证人、发布执行人	授权记录与角色指派
通道边界	仅限本次缺陷的最小变更；顺带的功能改动、重构、依赖升级不进入热修复	变更范围说明
回滚预案	启动时即明确回滚方式与触发阈值	回滚预案要点

启动环节的输出应是一份可追溯的授权记录：谁在什么时间、基于什么影响判断、批准了哪个范围的修复。这份记录既是后续审批的依据，也是复盘时判断定级是否合理的材料。

从问题确认到修复分支：操作步骤

热修复最容易出错的环节是分支来源。正确做法是从线上正在运行的版本对应的基线拉出热修复分支，不从主干最新代码拉出。主干上可能已包含尚未发布的功能和变更，直接基于主干修复会把未验证内容带入线上。分支命名建议体现缺陷单号与版本，便于检索。

修复提交要保持粒度小、目的单一，每次提交关联对应缺陷单，提交说明写清改了什么、为什么改。修复过程中如需调整方案，应在缺陷单中补充说明，避免只留在聊天记录里。

步骤	输入	动作	输出	完成标志
1. 问题确认	监控告警、用户反馈、值班记录	复现问题，记录现象、影响用户与功能范围、首次发现时间	故障单初稿	影响范围可描述，等级有初判
2. 启动授权	故障单初稿	授权人确认等级并批准启动，指派角色	授权记录	授权人与角色明确
3. 拉热修复分支	线上运行版本基线	从对应基线创建分支，命名含缺陷单号	热修复分支	分支来源可核对
4. 修复与提交	热修复分支、缺陷单	最小范围修改，提交关联缺陷单	提交记录与变更说明	变更范围与缺陷单一致
5. 提交验证	修复后的分支	交验证人做针对性验证	验证任务与结论	验证人确认通过或退回
6. 合并回主干	已验证的修复提交	按约定时机合并回主干并记录	合并记录	主干包含该修复，下次发布不覆盖

合并回主干的时机有两种常见安排：发布验证通过后立即合并，或在观察期结束后合并。前者能尽早防止下次常规发布覆盖修复，后者能避免把可能回滚的改动带入主干。无论选哪种，都要在流程中写明并由修复负责人执行，合并记录与缺陷单关联，防止修复在后续版本中丢失。

验证与发布：最小回归、灰度与回滚

热修复的验证范围按影响面取舍，不追求全量回归，但也不能只靠开发自测。基本做法是两层：针对缺陷路径做定向验证，确认原问题已修复且未引入相邻功能异常；再对核心链路做最小回归，覆盖登录、下单、支付等关键路径中与本次变更相关的部分。验证结论由测试或指定验证人确认，写明验证项、结果和未覆盖项。

发布审批关注三件事：变更范围是否与授权一致、验证结论是否充分、回滚预案是否可执行。审批通过后按预定窗口发布，发布执行人负责操作与观察，审批人不兼任执行，保证风险判断与操作分离。

环节	执行要点	记录产出
针对性验证	复现原缺陷场景，确认修复；检查相邻功能	验证项与结果
最小回归	覆盖与变更相关的核心链路，列明未覆盖范围	回归清单与结论
发布审批	核对变更范围、验证结论、回滚预案	审批意见与时间
灰度发布	先小流量或部分节点发布，预设观察指标与观察时长	灰度范围与开始时间
观察	盯错误率、核心接口成功率、关键业务指标，与发布前基线对比	观察数据与结论
回滚	达到预设阈值即执行回滚，回滚后再次观察并记录	回滚原因、步骤、结果

回滚触发条件应在发布前写明，例如核心接口错误率超过阈值、关键功能不可用、业务指标明显偏离基线。触发后由发布执行人按预案操作，授权人确认，回滚完成后同样记录时间、影响范围和恢复情况。回滚步骤要提前演练过，避免紧急时刻才发现脚本或开关不可用。

记录要求：热修复必须留哪些证据

热修复通道缩短的是审批层级和等待时间，记录项不能随之减少。记录的作用是让事后能回答三个问题：当时判断依据是什么、改了什么、结果如何。建议按六类记录固定下来，每类明确责任人、时点和存放位置。

记录项	责任人	时点	存放位置
故障与定级记录：现象、影响范围、等级、确认人	值班/一线提交，授权人确认	启动热修复前	缺陷单或故障单
分支与提交记录：分支来源、提交清单、变更说明	修复负责人	修复过程中	代码仓库与缺陷单关联
验证结论：验证项、结果、未覆盖项、验证人	测试或指定验证人	发布前	缺陷单或验证记录
发布审批：审批人意见、批准时间、回滚预案	审批人	发布前	审批记录
发布与观察结果：灰度范围、观察指标、结论	发布执行人	发布及观察期	发布记录
回滚或收尾复盘：回滚原因与结果，或复盘结论与改进项	发布负责人	回滚时或观察期结束后	复盘文档

这些记录分散在缺陷单、代码仓库、审批流和发布记录中时，容易出现关联断裂。可以在研发管理工具中把缺陷单作为主线，将修复分支、提交、验证结论、审批和发布结果挂接到同一工作项下，使一次热修复的证据链在一个入口可查。ONES 的工作项与代码关联、审批和文档能力可以承载这类衔接，具体配置按团队现有流程设定。

复盘记录不必等到重大故障才写。每次热修复结束后，用简短篇幅记录根因、修复方式、验证是否充分、发布是否顺利、有无可改进的流程点，并归入知识库，供后续同类问题参考。

角色分工与交付物

热修复涉及多个角色，职责不清时最容易出现“都在看、没人定”的情况。建议在流程文件中固定角色与交付物，并明确审批与执行分离。

角色	主要职责	交付物
值班/一线	发现并初判问题，提交故障单，通知相关角色	故障单初稿、影响范围描述
授权人（审批人）	确认定级，批准启动与发布，确认回滚决定	启动授权、发布审批意见
修复负责人（开发）	拉分支、修复、提交、合并回主干	热修复分支、提交记录、变更说明
验证人（测试）	定向验证与最小回归，给出验证结论	验证记录与结论
发布执行人	执行发布与灰度，观察指标，按预案回滚	发布记录、观察数据、回滚记录
业务方	确认业务影响，参与验收与对外沟通	业务影响说明、验收意见

审批人与执行人分离是基本约束：授权人批准发布但不亲自操作，发布执行人操作但不自行批准。人员紧张时可由备份角色顶替，但顶替关系要事先写明，不能临时口头指定。

示例：一次支付故障的热修复全过程

以下为演示情景，用于串联流程与记录，不代表真实案例。

某系统在晚间出现部分用户支付成功后订单状态未更新。值班人员通过监控告警和用户反馈确认现象，记录影响范围：约一小时内部分支付订单状态异常，涉及支付回调处理逻辑。值班提交故障单，初判为线上严重缺陷。

授权人确认定级，批准启动热修复，指定修复负责人、验证人和发布执行人，同时要求发布前给出回滚预案。修复负责人从线上运行版本对应的基线拉出热修复分支，定位到回调处理中的状态判断问题，做最小范围修改，提交关联缺陷单并写明变更说明。

验证人复现原场景确认修复，并对下单、支付、订单查询核心链路做最小回归，记录验证项与未覆盖项。授权人核对变更范围与验证结论，批准发布。发布执行人先对小部分流量灰度，观察支付成功率与订单状态一致率，与发布前基线对比，确认无异常后扩大范围。

观察期结束后，修复负责人将修复合并回主干并记录。发布负责人整理收尾记录：故障时间线、根因、修复内容、验证结论、发布与观察数据，归入复盘文档，并提出补充该类回调场景监控的改进项。

完成检查：热修复流程是否可用的核对项

流程写完后，用下面的清单逐项核对，判断它能否在真实故障中跑起来。任一项不满足，都应在下次故障前补齐。

类别	核对项	判定
流程可执行性	触发条件与定级口径已写入流程文件，团队可查	是/否
流程可执行性	授权人及备份授权人已指定，非工作时间可联系	是/否
流程可执行性	热修复分支从线上版本基线拉出的做法已明确	是/否
流程可执行性	回滚预案可执行，且近期演练或验证过	是/否
记录完整性	六类记录均有责任人和存放位置	是/否
记录完整性	缺陷单能关联分支、提交、验证与审批记录	是/否
记录完整性	复盘记录有固定模板和归档位置	是/否
阻断项	无授权启动、无验证结论、无回滚预案时不得发布	是/否
阻断项	修复未合并回主干前，下次常规发布需检查是否覆盖该修复	是/否

完成条件可以概括为：一次热修复结束后，能在同一处查到从故障发现到发布收尾的完整证据链，且下次常规发布不会覆盖本次修复。达到这个状态，流程和记录才算真正可用。

常见问题

热修复分支合并回主干，应该在发布前还是观察期结束后？

两种安排都可行，取决于团队对回滚风险的判断。发布验证通过后立即合并，能尽早防止下次常规发布覆盖修复；观察期结束后再合并，可以避免把可能回滚的改动带入主干。无论选哪种，都要在流程文件中写明时机，由修复负责人执行，并把合并记录与缺陷单关联。若选择观察期后合并，需要在下次常规发布前检查该修复是否已被覆盖。

非工作时间发生线上故障，授权人联系不上怎么办？

流程文件中应事先指定备份授权人，并写明顶替关系，保证非工作时间也能启动热修复。备份授权人拥有与授权人相同的定级确认和发布审批权限，顶替情况需在授权记录中注明。人员临时口头指定容易造成责任不清，建议把值班表与授权人名单放在团队可查的位置，随人员变动同步更新。

热修复只改了一行代码，验证和记录能不能简化？

变更行数少不代表风险低，线上修复的影响取决于改动位置而非代码量。验证可以按影响面取舍，但针对缺陷路径的定向验证和与变更相关的最小回归仍要做，验证结论需由测试或指定验证人确认。记录项同样不宜省略，至少保留故障与定级、提交与变更说明、验证结论、发布审批和发布结果，否则事后无法回答当时改了什么、依据是什么。

回滚后原缺陷仍未解决，接下来怎么走？

回滚记录完成后，应把问题退回故障单重新评估：确认原修复方案是否失效、影响范围是否扩大、是否需要调整定级。再次启动热修复时，从当前线上运行版本基线重新拉分支，避免沿用已回滚的提交。若短时间内无法给出可靠修复，可与业务方确认降级方案或临时规避措施，并在记录中写明决策依据和后续计划。

热修复记录分散在多个系统里，怎么保证证据链完整？

常见做法是以缺陷单为主线，把修复分支、提交、验证结论、审批意见和发布结果都挂接到同一工作项下，使一次热修复的证据在一个入口可查。ONES 的工作项与代码关联、审批和文档能力可以承载这类衔接，具体配置按团队现有流程设定。若暂时无法统一到一处，至少在缺陷单中登记各类记录的链接或编号，复盘时按编号逐项核对。