17-线上Bug热修复流程紧急分支、补丁合并、版本快速回退方案前言大家好我是黒漂技术佬。线上出 Bug 这种事就像你正吃着火锅唱着歌突然接到电话说柜子门打不开了。炸不炸慌不慌别急今天我们就来聊聊——当生产环境出了紧急 Bug如何建立一套标准化的热修复流程让团队不至于手忙脚乱、各自为战。一、线上 Bug 的急诊分诊先判断严重性不是所有 Bug 都值得走热修复流程。我们首先要对线上问题做分级级别描述例子响应时间P0 - 严重核心功能不可用、数据丢失、资金异常售货柜无法开门、支付扣款成功但未出货立即响应P1 - 紧急主要功能受损但有替代方案小程序页面加载慢但扫码仍可使用2小时内P2 - 普通非核心功能异常后台报表数据显示延迟下一个迭代修复P3 - 轻微UI瑕疵、文案错误页面间距异常排期修复只有 P0 和 P1 级别的 Bug 才需要走紧急热修复流程。二、Hotfix 分支的标准操作流程咱们团队的 Git 分支模型是master → develop → feature热修复要走专用通道。2.1 创建 hotfix 分支# 1. 确保当前在 master 分支且是最新代码gitcheckout mastergitpull origin master# 2. 从 master 创建 hotfix 分支命名规范hotfix/YYYYMMDD-简短描述gitcheckout-bhotfix/20240615-fix-lock-failure# 3. 推送到远程仓库gitpush origin hotfix/20240615-fix-lock-failure命名规范解释hotfix/日期-问题简述方便后续追溯。比如hotfix/20240615-fix-payment-duplicate一看就知道是修复支付重复扣款。2.2 修复代码并提交# 修复代码后...gitadd.gitcommit-mfix: 修复售货柜电磁锁偶发无法开启的问题 - 增加锁控指令重试机制失败后200ms内自动重发 - 调整GPIO电平保持时间从50ms延长至100ms - 关联Issue: #4782Commit 信息要写清楚做了什么修复、改了什么、为什么这样改、关联哪个 Issue。2.3 关键一步Cherry-Pick 双向合并hotfix 修复完成后必须合并到两个地方master 和 develop。# 合并到 master发版gitcheckout mastergitmerge --no-ff hotfix/20240615-fix-lock-failuregittag-av2.3.1-mhotfix: 修复锁控Buggitpush origin master--tags# 合并到 develop同步修复防止后续版本遗漏gitcheckout developgitmerge --no-ff hotfix/20240615-fix-lock-failuregitpush origin develop为什么不直接用 cherry-pickcherry-pick 会产生新的 commit hash导致 master 和 develop 上的修复 commit 不一致后续合并时容易出现冲突。--no-ff合并保留完整的提交历史双向合并是最稳妥的做法。三、版本快速回退关键时刻的后悔药3.1 K8s 服务回滚如果热修复引入了新问题或者修复方案有问题Kubernetes 支持秒级回滚# 查看部署历史kubectl rollouthistorydeployment/vending-machine-backend-nproduction# 回滚到上一个版本kubectl rollout undo deployment/vending-machine-backend-nproduction# 回滚到指定版本kubectl rollout undo deployment/vending-machine-backend-nproduction --to-revision3# 监控回滚状态kubectl rollout status deployment/vending-machine-backend-nproductionK8s 回滚的原理每次 Deployment 更新都会创建一个 ReplicaSetrollout undo就是把流量切回旧的 ReplicaSet。旧 Pod 依然在集群中只是没有流量进来而已。3.2 固件 OTA 回滚无人售货柜的安卓主板/瑞芯微固件也必须有回滚能力# 1. OTA 服务端下发回滚指令curl-XPOST http://ota-server/api/rollback\-d{device_id: VM-2024-0147, target_version: 2.3.0}# 2. 设备端收到指令后切换到备用分区# Android A/B 分区更新机制当前运行A分区OTA更新写B分区# 回滚时切换到A分区的旧系统固件回滚的核心在于 OTA 升级设计时就规划好双分区A/B Slot、保留最近3个版本的固件包、支持远程触发回滚。四、热修复后的测试验证热修复不是修完就完了必须有最小化但完整的验证流程本地验证开发人员修复后自测核心路径Code Review至少一名同事审查代码变更预发布环境验证在 staging 环境部署热修复版本执行回归测试用例灰度发布先灰度 5%-10% 的机器观察 30 分钟无异常再全量监控告警检查观察错误率、响应时间、成功率等核心指标五、实战案例售货柜吞货事故热修复全过程场景还原某天凌晨 2 点运维告警群里炸了——5 台售货柜连续出现支付成功但不出货的问题用户投诉电话打爆了客服。问题定位查看日志发现出货指令下发后电机驱动的 SPI 通信超时。进一步分析发现前一天发布的新版本中SPI 通信超时时间从 500ms 改为了 300ms为了优化出货速度但部分电机响应较慢导致超时失败。热修复流程分级判定为 P0立即响应创建 hotfix 分支hotfix/20240610-fix-spi-timeout修复将超时时间恢复为 500ms并增加自适应重试合并--no-ff合并到 master 和 developK8s 回滚部分已经部署了新版本的机器先用kubectl rollout undo回到旧版灰度验证先在 2 台柜子上热更验证确认出货正常全量部署剩余机器全量推送客服电话消停了耗时总计从接到告警到问题修复全量上线共计 47 分钟。六、热修复流程的三大铁律最后总结三条经验请刻在工位上不要跳过 Code Review——再紧急的 Bug也值得花 5 分钟让另一个人看一眼双向合并别忘了 develop——很多团队修完 master 就完事了结果下个版本又把 Bug 带回来了回滚方案前置设计——不是万一出问题怎么办的心态而是出问题时怎么最快恢复的设计线上 Bug 不可怕可怕的是没有流程。建立标准化的热修复机制团队才能在紧急时刻保持冷静、快速响应。
17-线上Bug热修复流程：紧急分支、补丁合并、版本快速回退方案
17-线上Bug热修复流程紧急分支、补丁合并、版本快速回退方案前言大家好我是黒漂技术佬。线上出 Bug 这种事就像你正吃着火锅唱着歌突然接到电话说柜子门打不开了。炸不炸慌不慌别急今天我们就来聊聊——当生产环境出了紧急 Bug如何建立一套标准化的热修复流程让团队不至于手忙脚乱、各自为战。一、线上 Bug 的急诊分诊先判断严重性不是所有 Bug 都值得走热修复流程。我们首先要对线上问题做分级级别描述例子响应时间P0 - 严重核心功能不可用、数据丢失、资金异常售货柜无法开门、支付扣款成功但未出货立即响应P1 - 紧急主要功能受损但有替代方案小程序页面加载慢但扫码仍可使用2小时内P2 - 普通非核心功能异常后台报表数据显示延迟下一个迭代修复P3 - 轻微UI瑕疵、文案错误页面间距异常排期修复只有 P0 和 P1 级别的 Bug 才需要走紧急热修复流程。二、Hotfix 分支的标准操作流程咱们团队的 Git 分支模型是master → develop → feature热修复要走专用通道。2.1 创建 hotfix 分支# 1. 确保当前在 master 分支且是最新代码gitcheckout mastergitpull origin master# 2. 从 master 创建 hotfix 分支命名规范hotfix/YYYYMMDD-简短描述gitcheckout-bhotfix/20240615-fix-lock-failure# 3. 推送到远程仓库gitpush origin hotfix/20240615-fix-lock-failure命名规范解释hotfix/日期-问题简述方便后续追溯。比如hotfix/20240615-fix-payment-duplicate一看就知道是修复支付重复扣款。2.2 修复代码并提交# 修复代码后...gitadd.gitcommit-mfix: 修复售货柜电磁锁偶发无法开启的问题 - 增加锁控指令重试机制失败后200ms内自动重发 - 调整GPIO电平保持时间从50ms延长至100ms - 关联Issue: #4782Commit 信息要写清楚做了什么修复、改了什么、为什么这样改、关联哪个 Issue。2.3 关键一步Cherry-Pick 双向合并hotfix 修复完成后必须合并到两个地方master 和 develop。# 合并到 master发版gitcheckout mastergitmerge --no-ff hotfix/20240615-fix-lock-failuregittag-av2.3.1-mhotfix: 修复锁控Buggitpush origin master--tags# 合并到 develop同步修复防止后续版本遗漏gitcheckout developgitmerge --no-ff hotfix/20240615-fix-lock-failuregitpush origin develop为什么不直接用 cherry-pickcherry-pick 会产生新的 commit hash导致 master 和 develop 上的修复 commit 不一致后续合并时容易出现冲突。--no-ff合并保留完整的提交历史双向合并是最稳妥的做法。三、版本快速回退关键时刻的后悔药3.1 K8s 服务回滚如果热修复引入了新问题或者修复方案有问题Kubernetes 支持秒级回滚# 查看部署历史kubectl rollouthistorydeployment/vending-machine-backend-nproduction# 回滚到上一个版本kubectl rollout undo deployment/vending-machine-backend-nproduction# 回滚到指定版本kubectl rollout undo deployment/vending-machine-backend-nproduction --to-revision3# 监控回滚状态kubectl rollout status deployment/vending-machine-backend-nproductionK8s 回滚的原理每次 Deployment 更新都会创建一个 ReplicaSetrollout undo就是把流量切回旧的 ReplicaSet。旧 Pod 依然在集群中只是没有流量进来而已。3.2 固件 OTA 回滚无人售货柜的安卓主板/瑞芯微固件也必须有回滚能力# 1. OTA 服务端下发回滚指令curl-XPOST http://ota-server/api/rollback\-d{device_id: VM-2024-0147, target_version: 2.3.0}# 2. 设备端收到指令后切换到备用分区# Android A/B 分区更新机制当前运行A分区OTA更新写B分区# 回滚时切换到A分区的旧系统固件回滚的核心在于 OTA 升级设计时就规划好双分区A/B Slot、保留最近3个版本的固件包、支持远程触发回滚。四、热修复后的测试验证热修复不是修完就完了必须有最小化但完整的验证流程本地验证开发人员修复后自测核心路径Code Review至少一名同事审查代码变更预发布环境验证在 staging 环境部署热修复版本执行回归测试用例灰度发布先灰度 5%-10% 的机器观察 30 分钟无异常再全量监控告警检查观察错误率、响应时间、成功率等核心指标五、实战案例售货柜吞货事故热修复全过程场景还原某天凌晨 2 点运维告警群里炸了——5 台售货柜连续出现支付成功但不出货的问题用户投诉电话打爆了客服。问题定位查看日志发现出货指令下发后电机驱动的 SPI 通信超时。进一步分析发现前一天发布的新版本中SPI 通信超时时间从 500ms 改为了 300ms为了优化出货速度但部分电机响应较慢导致超时失败。热修复流程分级判定为 P0立即响应创建 hotfix 分支hotfix/20240610-fix-spi-timeout修复将超时时间恢复为 500ms并增加自适应重试合并--no-ff合并到 master 和 developK8s 回滚部分已经部署了新版本的机器先用kubectl rollout undo回到旧版灰度验证先在 2 台柜子上热更验证确认出货正常全量部署剩余机器全量推送客服电话消停了耗时总计从接到告警到问题修复全量上线共计 47 分钟。六、热修复流程的三大铁律最后总结三条经验请刻在工位上不要跳过 Code Review——再紧急的 Bug也值得花 5 分钟让另一个人看一眼双向合并别忘了 develop——很多团队修完 master 就完事了结果下个版本又把 Bug 带回来了回滚方案前置设计——不是万一出问题怎么办的心态而是出问题时怎么最快恢复的设计线上 Bug 不可怕可怕的是没有流程。建立标准化的热修复机制团队才能在紧急时刻保持冷静、快速响应。