一、前言
做業務研發，難免碰到線上問題。從異常出現，到問題解決，需要緊繃神經，爭分奪秒，是對程序員專業技能的硬核考驗。特別是在面向億萬用戶的大促場景，上下游幾十號同事同時盯着，負責問題解決的幾個關鍵同學必須抗住巨大壓力，極限編碼，在最短時間解決戰鬥。可謂臺上一分鐘，臺下十年功，平常理論講得一套套，這時候是真有實力還是繡花枕頭，一試便知。
支付寶卡包團隊昨晚剛剛經歷了一次實戰考驗，從晚上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以上就可以了。