一、前言
做业务研发，难免碰到线上问题。从异常出现，到问题解决，需要紧绷神经，争分夺秒，是对程序员专业技能的硬核考验。特别是在面向亿万用户的大促场景，上下游几十号同事同时盯着，负责问题解决的几个关键同学必须抗住巨大压力，极限编码，在最短时间解决战斗。可谓台上一分钟，台下十年功，平常理论讲得一套套，这时候是真有实力还是绣花枕头，一试便知。
支付宝卡包团队昨晚刚刚经历了一次实战考验，从晚上10点发现问题，到第二天上午9点发布修复，期间体现了卡包工程师的专业实力，作为卡包后端研发技术负责人，我感到非常振奋和自豪，为卡包的两位同学点赞！
这篇文章简单分享一下我对于做好线上紧急hotfix的几点经验。
二、过程
整体分为事中和事后两阶段。
事中：线上问题发现到解决，最是紧张刺激。我认为可分为以下7步。
1. 明确异常现象
2. 业务影响和紧急度评估
3. 原因初步分析和业务止血
4. 原因详细分析和方案拆解
5. 编码和测试验证
6. 发布上线
7. 业务恢复
事后：主要是覆盘，避免类似问题别在发生，包括4个方面。
1. 持续观察
2. 后续action
3. 责任划分
4. 经验总结
三、要点
先讲事中几步里的要点。
事中第2步，之所以要做业务影响和紧急度评估，是因为hotfix的目的就是消除业务影响。这个过程，需要工程师有业务意识和用户视角，有经验的同学很快能够嗅到其中的风险，进而决策是深夜加班紧急修复，还是可以等到第二天白天上班后再搞。程序员是一份辛苦的工作，我们尽量避免非必要的熬夜加班。
事中第3和4步，把原因分析分成初步分析和详细分析两步。初步分析的目的是考虑快速止血的办法，这是消除业务影响，避免持续恶化的关键。虽然这一步很重要，但往往做不好，因为很多工程师容易陷入到问题中，撸代码、查日志，一头扎进去出不来。
第5步编码和测试，是程序员的老本行，本来是得心应手的，但放到紧急hotfix的上下文中，特别容易引入二次故障。再熟练的程序员，在应急情况下，也容易写出平常绝不可能写出的bug，所以一要平常心，二要交叉review。平常不怎么参与cr的架构同学，这时候必须要站出来镇场子。要注意代码修改的范围，非必要的代码一律不要写；争取一次到位，因为每提交一次，服务器部署准备就是十来分钟，在应急情况下，容易让人感到焦虑。
接着是事后步骤的要点。
先说事后第3条，责任划分，相信不少程序员碰到过类似难题。说白了，这个锅是谁的？我们要避免先入为主，不是说改了代码的一方，就是该背锅的一方。紧急hotfix的方案，很可能只是全链路评估下来，改造成本最低、最快消除业务影响的方案而已。在紧急hotfix中，我们往往会把方案合理性暂时放一放。
正因为应急方案可能放弃了一定合理性，所以事后需要更正的过程，避免临时方案带来新的坑，所以才有事后第2条。
以上是我的一些经验分享，希望对同行有所启发。
四、招人
支付宝卡包新的一年，大量HC，欢迎人才加入，base杭州，有机会参与面向亿万支付宝用户的大项目，我们Z空间等你。
支付宝hotfix合理性阶段
我们在日常项目中，市场遇到线上bug紧急修复，这个时候，需要基于某个tag拉出一个热修复的分支修复好bug,测试一下，再合并回主线。
例如，线上生产环境版本v1.1.3，开发环境正在开发1.2.0，我们需要临时对线上版本修复bug，版本升级到v1.1.4（需要基于分支起名字v1.1.3_hotfix）.
再比如：线上生产环境版本v2.1.0，开发环境正在开发v2.1.1，客户本地版本还是v1.1.3,并且不愿意升级，这时需要基于稳定版v1.1.3进行热修复，基于tag拉出v1.1.3_hotfix。
步骤如下：
1.回到tag v1.1.0（不论你是否有新改动合进去了，基于线上稳定版）
git checkout v1.1.0(tag稳定版)
2.拉出创建分支v1.1.0_hotfix
git checkout -b v1.1.0_hotfix3.然后在推到远程去
git push origin v1.1.0_hotfix以上就可以了。