背景
做過不少公司的咨詢畸悬，發(fā)現(xiàn)有些公司對于線上事故沒有規(guī)范化的認(rèn)知，沒有預(yù)防措施奋姿，發(fā)生之后也沒有一個規(guī)范的流程去響應(yīng)锄开。甚至有的公司發(fā)生線上事故之后素标，沒有監(jiān)控沒有預(yù)警称诗，只有開發(fā)或運維知道，然后他們就悄悄的把線上事故修復(fù)了头遭，神不知鬼不覺寓免。
那么接下來我就從下面這幾個方面來談一談線上事故的故事。
線上事故預(yù)防
線上事故預(yù)防分為3個方面
- 預(yù)發(fā)環(huán)境
- 上線checklist
- 日志與運維監(jiān)控
預(yù)發(fā)環(huán)境
預(yù)發(fā)環(huán)境也叫UAT環(huán)境计维，或者預(yù)生產(chǎn)環(huán)境等袜香。
非生產(chǎn)環(huán)境中應(yīng)該有一個預(yù)發(fā)環(huán)境，此環(huán)境理論上應(yīng)該和生產(chǎn)環(huán)境一模一樣鲫惶，包括一樣的配置來保證性能一致蜈首，一樣的數(shù)據(jù)來保證行為一致。
這樣才能最大限度的模擬生產(chǎn)環(huán)境欠母，并提前發(fā)現(xiàn)問題解決問題欢策，起到沙盤演練的作用。
預(yù)發(fā)環(huán)境的位置如下圖：
預(yù)發(fā)環(huán)境搭建好了之后赏淌，應(yīng)該定期的同步生產(chǎn)環(huán)境的數(shù)據(jù)到預(yù)發(fā)環(huán)境做測試踩寇。
注意：同步數(shù)據(jù)時得有一定的脫敏策略，不然會有安全風(fēng)險六水。
影子流量
由于預(yù)發(fā)環(huán)境畢竟不是生產(chǎn)環(huán)境俺孙，所有的請求都是由測試人員模擬的，并不是真實的情況掷贾。
而影子流量(shadow traffic)就是將發(fā)給生產(chǎn)環(huán)境的請求復(fù)制一份轉(zhuǎn)發(fā)到類生產(chǎn)環(huán)境上去睛榄，以此來達到壓力測試和正確性測試的目的。
影子流量的實現(xiàn)有多種方式想帅，常見的比如在統(tǒng)一的入口處API Gateway等地方復(fù)制一份流量轉(zhuǎn)發(fā)到預(yù)發(fā)環(huán)境场靴，由此來監(jiān)測預(yù)發(fā)環(huán)境有沒有異常情況發(fā)生。
影子流量的過程如下圖所示博脑。
由于影子流量來自真實的生產(chǎn)環(huán)境憎乙，過程中一定要注意安全防范票罐，以及流量轉(zhuǎn)發(fā)給生產(chǎn)環(huán)境性能帶來的性能影響。
影子庫
同理影子流量泞边，理論上預(yù)發(fā)環(huán)境應(yīng)該有一份和生產(chǎn)環(huán)境一模一樣的數(shù)據(jù)庫该押，才能更真實的模擬生產(chǎn)環(huán)境的情況。影子庫就是把生產(chǎn)環(huán)境的數(shù)據(jù)庫復(fù)制了一份阵谚，有相同的數(shù)據(jù)量和相同的數(shù)據(jù)庫配置蚕礼。
當(dāng)然，理論上梢什，影子庫的數(shù)據(jù)應(yīng)該是經(jīng)過脫敏處理之后的奠蹬。
上線checklist
上線前應(yīng)該有一份不斷累計不斷更新的checklist，用于上線前的檢查嗡午，每項檢查都通過之后囤躁，方能上線。
有任何一項檢查不通過荔睹，則不能上線狸演。直到問題解決之后，才能上線僻他。另外宵距，應(yīng)該避免在業(yè)務(wù)高峰期進行上線操作。
下面是一些常見的checklist項吨拗，不同的項目會根據(jù)需要有不同的checklist：
- 測試報告是否已通過
- 業(yè)務(wù)驗收報告是否已通過
- 是否有其他版本正在上線
- 是否有線上問題未解決
- 是否有回滾方案
雖然它是checklist满哪，但很多公司在實踐的時候都把它做成了上線報告。
更推薦的做法是把checklist做得越輕量級越好劝篷，就像checklist哨鸭，輕量級的檢查就能上線。
不然就會讓上線變得越來越困難携龟、越來越花時間兔跌，違背了持續(xù)交付的理念。
日志與運維監(jiān)控
如果有非常完備的日志系統(tǒng)峡蟋，比如常見的ELK坟桅，splunk等，則可以在預(yù)發(fā)環(huán)境的影子流量中和生產(chǎn)環(huán)境中蕊蝗，監(jiān)測到異常日志仅乓，提前發(fā)現(xiàn)問題，提前解決問題蓬戚。
日志監(jiān)控是一個挺大的話題夸楣，這里就不展開講了。
但日志是我們定位問題和追溯問題中不可或缺的一環(huán)。
線上事故修復(fù)
線上報警
線上環(huán)境應(yīng)該有監(jiān)控預(yù)警豫喧，一旦發(fā)生任何事故石洗，都應(yīng)該及時報警。
這些事故可能發(fā)生的情況包括但不限于：
- 服務(wù)不可用
- 數(shù)據(jù)庫不可用
- 服務(wù)器不可用
- 高級別日志警告
- 流量異常
發(fā)生了事故紧显，應(yīng)該第一時間自動通知開發(fā)團隊讲衫，并抄送相關(guān)負責(zé)人或領(lǐng)導(dǎo)。收到郵件或通知的開發(fā)團隊則應(yīng)該第一時間修復(fù)該線上問題孵班。
郵件中應(yīng)該包含事故的現(xiàn)象描述涉兽，原因，日志等信息篙程，以方便開發(fā)團隊分析和修復(fù)枷畏。
最重要的是，上述過程都應(yīng)該是全自動化的虱饿，才能保證開發(fā)人員或者運維人員第一時間響應(yīng)拥诡。
通常一個團隊中會建立某種機制來保證發(fā)生線上事故的時候有人能及時響應(yīng)事故。
我見過有的公司是運維人員24小時待命的郭厌。
也見過做的比較好的公司是袋倔，團隊成員輪流做那個站崗的人，系統(tǒng)通知自動綁定站崗人的電話和郵件折柠，發(fā)生線上事故之后，第一時間自動逐級通知站崗人批狐，負責(zé)人扇售，領(lǐng)導(dǎo)等。由站崗人作為線上事故的owner嚣艇，他不一定能修承冰，但他要保證問題被修復(fù)。如果事故發(fā)生在工作時間以外食零，則根據(jù)響應(yīng)的時間來調(diào)休困乒。
回滾機制
優(yōu)秀的團隊都是使用CI/CD的pipeline來進行上線部署，一旦失敗了贰谣，pipeline都是支持回滾到上一個版本的娜搂。
如果是使用的Kubernetes，則只需要回滾到上一個版本的鏡像則可以了吱抚。
這就要求百宇，我們每次構(gòu)建的包或者鏡像都應(yīng)該帶上版本號，才方便我們追蹤每個版本的狀態(tài)秘豹，以及根據(jù)版本來進行回滾操作携御。
災(zāi)備恢復(fù)
線上事故如果是災(zāi)難性的，則應(yīng)該啟動災(zāi)備恢復(fù)程序。 我了解的大部分公司其實都沒有災(zāi)備恢復(fù)的相關(guān)流程啄刹。理論上涮坐，一個意識比較好的公司，通常都會有嚴(yán)格的災(zāi)備恢復(fù)流程誓军。
災(zāi)備恢復(fù)可以是一個操作手冊膊升，指導(dǎo)員工如何一步一步的從0恢復(fù)服務(wù)。通常銀行業(yè)是一定有這樣的災(zāi)備恢復(fù)的谭企。
同時廓译，每次發(fā)生了大的基礎(chǔ)設(shè)施架構(gòu)變更的時候，比如服務(wù)器配置變化债查，數(shù)據(jù)庫變化等非区，都需要及時更新災(zāi)備恢復(fù)手冊。
線上事故復(fù)盤
線上事故修復(fù)之后盹廷，需要對此事故做一次復(fù)盤征绸，目的是為了避免下次再發(fā)生，以及發(fā)生了之后能更快的應(yīng)對俄占。
這個復(fù)盤有很多種形式管怠。其中一種形式叫無過錯驗尸報告。
具體的介紹可以看我的另外一篇文章：
無過錯驗尸報告 - Blameless Postmortem
總結(jié)
這里簡單列舉了一些關(guān)于線上事故我能想到的幾個點缸榄，如果大家對于這個話題還有其他感興趣的部分渤弛，歡迎給我留言，我們下回接著探討甚带。
