背景
做過不少公司的咨詢，發(fā)現(xiàn)有些公司對(duì)于線上事故沒有規(guī)范化的認(rèn)知，沒有預(yù)防措施，發(fā)生之后也沒有一個(gè)規(guī)范的流程去響應(yīng)。甚至有的公司發(fā)生線上事故之后，沒有監(jiān)控沒有預(yù)警，只有開發(fā)或運(yùn)維知道，然后他們就悄悄的把線上事故修復(fù)了，神不知鬼不覺。
那么接下來我就從下面這幾個(gè)方面來談一談線上事故的故事。
線上事故預(yù)防
線上事故預(yù)防分為3個(gè)方面
- 預(yù)發(fā)環(huán)境
- 上線checklist
- 日志與運(yùn)維監(jiān)控
預(yù)發(fā)環(huán)境
預(yù)發(fā)環(huán)境也叫UAT環(huán)境，或者預(yù)生產(chǎn)環(huán)境等。
非生產(chǎn)環(huán)境中應(yīng)該有一個(gè)預(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)境做測(cè)試。
注意：同步數(shù)據(jù)時(shí)得有一定的脫敏策略，不然會(huì)有安全風(fēng)險(xiǎn)。
影子流量
由于預(yù)發(fā)環(huán)境畢竟不是生產(chǎn)環(huán)境，所有的請(qǐng)求都是由測(cè)試人員模擬的，并不是真實(shí)的情況。
而影子流量(shadow traffic)就是將發(fā)給生產(chǎn)環(huán)境的請(qǐng)求復(fù)制一份轉(zhuǎn)發(fā)到類生產(chǎn)環(huán)境上去，以此來達(dá)到壓力測(cè)試和正確性測(cè)試的目的。
影子流量的實(shí)現(xiàn)有多種方式，常見的比如在統(tǒng)一的入口處API Gateway等地方復(fù)制一份流量轉(zhuǎn)發(fā)到預(yù)發(fā)環(huán)境，由此來監(jiān)測(cè)預(yù)發(fā)環(huán)境有沒有異常情況發(fā)生。
影子流量的過程如下圖所示。
由于影子流量來自真實(shí)的生產(chǎn)環(huán)境，過程中一定要注意安全防范，以及流量轉(zhuǎn)發(fā)給生產(chǎn)環(huán)境性能帶來的性能影響。
影子庫
同理影子流量，理論上預(yù)發(fā)環(huán)境應(yīng)該有一份和生產(chǎn)環(huán)境一模一樣的數(shù)據(jù)庫，才能更真實(shí)的模擬生產(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)該有一份不斷累計(jì)不斷更新的checklist，用于上線前的檢查，每項(xiàng)檢查都通過之后，方能上線。
有任何一項(xiàng)檢查不通過，則不能上線。直到問題解決之后，才能上線。另外，應(yīng)該避免在業(yè)務(wù)高峰期進(jìn)行上線操作。
下面是一些常見的checklist項(xiàng)，不同的項(xiàng)目會(huì)根據(jù)需要有不同的checklist：
- 測(cè)試報(bào)告是否已通過
- 業(yè)務(wù)驗(yàn)收?qǐng)?bào)告是否已通過
- 是否有其他版本正在上線
- 是否有線上問題未解決
- 是否有回滾方案
雖然它是checklist，但很多公司在實(shí)踐的時(shí)候都把它做成了上線報(bào)告。
更推薦的做法是把checklist做得越輕量級(jí)越好，就像checklist，輕量級(jí)的檢查就能上線。
不然就會(huì)讓上線變得越來越困難、越來越花時(shí)間，違背了持續(xù)交付的理念。
日志與運(yùn)維監(jiān)控
如果有非常完備的日志系統(tǒng)，比如常見的ELK，splunk等，則可以在預(yù)發(fā)環(huán)境的影子流量中和生產(chǎn)環(huán)境中，監(jiān)測(cè)到異常日志，提前發(fā)現(xiàn)問題，提前解決問題。
日志監(jiān)控是一個(gè)挺大的話題，這里就不展開講了。
但日志是我們定位問題和追溯問題中不可或缺的一環(huán)。
線上事故修復(fù)
線上報(bào)警
線上環(huán)境應(yīng)該有監(jiān)控預(yù)警，一旦發(fā)生任何事故，都應(yīng)該及時(shí)報(bào)警。
這些事故可能發(fā)生的情況包括但不限于：
- 服務(wù)不可用
- 數(shù)據(jù)庫不可用
- 服務(wù)器不可用
- 高級(jí)別日志警告
- 流量異常
發(fā)生了事故，應(yīng)該第一時(shí)間自動(dòng)通知開發(fā)團(tuán)隊(duì)，并抄送相關(guān)負(fù)責(zé)人或領(lǐng)導(dǎo)。收到郵件或通知的開發(fā)團(tuán)隊(duì)則應(yīng)該第一時(shí)間修復(fù)該線上問題。
郵件中應(yīng)該包含事故的現(xiàn)象描述，原因，日志等信息，以方便開發(fā)團(tuán)隊(duì)分析和修復(fù)。
最重要的是，上述過程都應(yīng)該是全自動(dòng)化的，才能保證開發(fā)人員或者運(yùn)維人員第一時(shí)間響應(yīng)。
通常一個(gè)團(tuán)隊(duì)中會(huì)建立某種機(jī)制來保證發(fā)生線上事故的時(shí)候有人能及時(shí)響應(yīng)事故。
我見過有的公司是運(yùn)維人員24小時(shí)待命的。
也見過做的比較好的公司是，團(tuán)隊(duì)成員輪流做那個(gè)站崗的人，系統(tǒng)通知自動(dòng)綁定站崗人的電話和郵件，發(fā)生線上事故之后，第一時(shí)間自動(dòng)逐級(jí)通知站崗人，負(fù)責(zé)人，領(lǐng)導(dǎo)等。由站崗人作為線上事故的owner，他不一定能修，但他要保證問題被修復(fù)。如果事故發(fā)生在工作時(shí)間以外，則根據(jù)響應(yīng)的時(shí)間來調(diào)休。
回滾機(jī)制
優(yōu)秀的團(tuán)隊(duì)都是使用CI/CD的pipeline來進(jìn)行上線部署，一旦失敗了，pipeline都是支持回滾到上一個(gè)版本的。
如果是使用的Kubernetes，則只需要回滾到上一個(gè)版本的鏡像則可以了。
這就要求，我們每次構(gòu)建的包或者鏡像都應(yīng)該帶上版本號(hào)，才方便我們追蹤每個(gè)版本的狀態(tài)，以及根據(jù)版本來進(jìn)行回滾操作。
災(zāi)備恢復(fù)
線上事故如果是災(zāi)難性的，則應(yīng)該啟動(dòng)災(zāi)備恢復(fù)程序。 我了解的大部分公司其實(shí)都沒有災(zāi)備恢復(fù)的相關(guān)流程。理論上，一個(gè)意識(shí)比較好的公司，通常都會(huì)有嚴(yán)格的災(zāi)備恢復(fù)流程。
災(zāi)備恢復(fù)可以是一個(gè)操作手冊(cè)，指導(dǎo)員工如何一步一步的從0恢復(fù)服務(wù)。通常銀行業(yè)是一定有這樣的災(zāi)備恢復(fù)的。
同時(shí)，每次發(fā)生了大的基礎(chǔ)設(shè)施架構(gòu)變更的時(shí)候，比如服務(wù)器配置變化，數(shù)據(jù)庫變化等，都需要及時(shí)更新災(zāi)備恢復(fù)手冊(cè)。
線上事故復(fù)盤
線上事故修復(fù)之后，需要對(duì)此事故做一次復(fù)盤，目的是為了避免下次再發(fā)生，以及發(fā)生了之后能更快的應(yīng)對(duì)。
這個(gè)復(fù)盤有很多種形式。其中一種形式叫無過錯(cuò)驗(yàn)尸報(bào)告。
具體的介紹可以看我的另外一篇文章：
無過錯(cuò)驗(yàn)尸報(bào)告 - Blameless Postmortem
總結(jié)
這里簡(jiǎn)單列舉了一些關(guān)于線上事故我能想到的幾個(gè)點(diǎn)，如果大家對(duì)于這個(gè)話題還有其他感興趣的部分，歡迎給我留言，我們下回接著探討。
