線上技術故障處理三板斧
“ 是軟體就有bug， 第一個bug是一蟲子 ”，軟體工程的老師是這樣講的。
當bug突破層層檢查站，被釋放到線上生產環境時， 比如文案錯誤，xx交易系統不可使用等，根據 其嚴重性不同，會引發線上的問題，甚至是線上故障。
而在大型軟體工程中， 講究預期一致性 ， 非預期內的線上表現，往往伴隨著bug的產生：
-
可能影響 不大 ，引發線上問題
-
比如運營圖片沒有更新，顯示成了昨天的了，且今天無重大活動
-
可能影響巨 大， 引 發線上故障
-
比如運營圖片沒有生效，原因是服務端 最近一次 釋出，程式碼本身有bug，某些行為下會觸發生效，導致全平臺配置失效，App內所有圖片坑位白屏
今天我們討論的是後面一種場景。
線上故障帶來的不僅僅是bugFix這麼簡單， 對於有一定規模量的產品， 尤其是toB或付費類產品更甚，引發的可能是公關甚至品牌。
讓我們重新review一下，這種線上影響較大的技術故障處理的注意事項，當真的發生了線上故障：
處理故障三板斧
-
1- 止血，止血，止血
-
先“ 止血 ”，再看為什麼 。線上故障就像是系統的破損，當發現並確認問題確實存在，第一件事情就是“ 止血 ”， 讓問題第一時間得到遏制，解法可以不是最優，但一定要最快。
-
2- 覆盤
-
趁熱打鐵，在1-3天內，重新推演問題的發生的原因， 找到根本原因和觸發原因 ，分析影響面，是否要主動安撫客戶。在每個關鍵節點， 當時 為什麼關鍵“卡點”處，沒有發現該隱患，還是發現了，誰決策了“帶傷上線”。
-
3- 改進
-
如果有類似的場景， 怎麼 保證不會再次發生 ，那麼需要接下來做哪些Action？ 落實到具體負責人， 確定落地的時間點。
避免故障三板斧
這裡，簡單分享下，目前業內比較常見的共識方法論
1. 釋出前， 確保有效的數字化監控
-
近些年，在一線工程團隊裡的一種思潮是， 重視有效的監控大盤 ，減少對個人操作經驗依賴，重視 流程資訊化 審批，減少“釋出核按鈕”掌握在單個人手裡。
2. 釋出時， 逐步灰度
-
每一次新功能及新產品的釋出，都 不要一把梭，要逐步放量 。可以從使用者比例、uid分桶、服務端機房分批、非核心使用者、VIP使用者等逐步放到止100%流量。
3. 釋出後， 一鍵回滾的能力
-
只有 每次釋出都具備一鍵回滾的技術能力 ，才能在真的發生問題時，瞬間做到問題止血。對軟體工程中featrue更有控制力，上線還是下線，從容應對，靈活控制。
理解產品週期與線上故障
技術故障，在產品的初期，到發展期，到成熟期，到半衰期，是有著不一樣的影響效力和重視程度。
產品初期
-
一切為了快速 試錯+反饋
-
所有的功能和技術實現圍繞的是，商業核心問題的是否被市場驗證。這時想的是，解決方案是否有效，是YY的，還是擊中了使用者核心訴求。使用者願意花錢買你的服務嗎？願意花多少錢買？追求的更快的是錯誤反饋。
產品發展期
-
故障的快速處理 開始被要求
-
核心功能看似已得到市場驗證，至少有部分人群，真的願意“掏腰包”買你的服務，這時團隊追求轉變喂新使用者拉新。運營力量開始介入，進一步提高新使用者湧入，刺激體量上一個新臺階。產品服務的穩定性、一致性開始被重視，技術側的工程能力逐步搭建，要求可用性比例， 故障可以有，但同樣的故障決不允許出現第二次 。
產品成熟期
-
線上故障 幾乎是0容忍態度
-
產品在細分領域佔據了一定份額，很多時候沒有可參照競品。技術所維護的業務形態，變得越來越複雜，程式碼量越來越多。技術架構升級與產品橫縱向整合同時推進， 故障等級也在不斷被細化， 線上故障開始有了問題追責 。
產品半衰期
-
既要 業務創新， 又要 技術穩定
-
技術上既要 維護前人的老程式碼，又要實現YY的新業務需求和老系統嫁接。對於組織來說， 沒有企業喜歡衰退期，要麼 盡力延長成熟期，擴大市場規模；要麼 尋求變革突破，寧可赴死也不等死。
現實的意義
在當下 敏捷/精益 迭代 + 狼性創業文化 的大行情下，不論是一線技術主管還是一線扭螺絲的，其實大家每天都是在高強度+高併發的工作中度過。很多時候， 人每天的精力是有限的 ， 扯皮、需求變更、開會等都會壓縮工期，最可恨的是Deadline幾乎很難延後。
質量和上線速度，落到實際工作中，有時候真的很難兩全 。 這時候故障的被發現，有時候反倒是 梳理這些事情的一個抓手 ，讓類似的故障不再發生，就需要技術側的架構更合理，監控更完善，流程更規範，這反倒是給技術同學爭取了一些時間buffer和價值意義實踐的視窗。產品側不能只顧提新需求，不考慮整體可靠性及由於業務越來越複雜，必須要進行的基礎技術能力升級。
未來還能做什麼？
對線上故障的重視，短期內可能會增加一線技術同學的心裡負擔與工作，但長期來看， 倒逼各角色對線上質量的重視程度 ，使用者的體驗，功能的穩定，對團隊及核心服務可靠性的支援意義重大。
敬畏每一次線上操作變更的風險 ，落實發布能夠灰度、資料大盤監控、業務資料指標是否符合預期。
加強有效報警，從對敬畏故障的思想做起，在基礎能力建設完善的基礎基礎上，未來實現“無人盯守，發現問題，自動告警，風險預測，自動回滾”，讓devOps從經常要搞到凌晨釋出，無法安心入睡的困境中解救出來， 減少一線擰螺絲人員的背鍋次數，減少系統釋放處來的背鍋HC機會，最終實現已知領域內的線上功能服務的高可用 。
歡迎關注微信公眾號：土豆他爸爸
堅持每週寫一篇 生活|技術|時事 的原創總結
