1. 背景

京東的期中考試：618即將到來(lái)，各個(gè)團(tuán)隊(duì)都在進(jìn)行期中考試前的模擬考試：軍演壓測(cè)，故障演練，系統(tǒng)的梳理以檢測(cè)系統(tǒng)的穩(wěn)定性以應(yīng)對(duì)高可用，高性能，高并發(fā)。我們知道系統(tǒng)的穩(wěn)定性建設(shè)是貫穿整個(gè)研發(fā)流程：需求階段，研發(fā)階段，測(cè)試階段，上線階段，運(yùn)維階段；整個(gè)流程中的所有參與人員：產(chǎn)品，研發(fā)，測(cè)試，運(yùn)維人員都應(yīng)關(guān)注系統(tǒng)的穩(wěn)定性。業(yè)務(wù)的發(fā)展及系統(tǒng)建設(shè)過(guò)程中，穩(wěn)定性就是那個(gè)1，其他的是1后面的0，沒(méi)有穩(wěn)定性，就好比將萬(wàn)丈高樓建于土沙之上。本篇文章主要從后端研發(fā)的視角針對(duì)研發(fā)階段和上線階段談下穩(wěn)定性建設(shè)，希望起到拋磚引玉的作用，由于本人的水平有限，文中難免有理解不到位或者不全面的地方，歡迎批評(píng)指正。

2. 研發(fā)階段

研發(fā)階段主要參與人員是研發(fā)，主要產(chǎn)出物是技術(shù)方案設(shè)計(jì)文檔和代碼，一個(gè)是研發(fā)階段的開始，一個(gè)是研發(fā)階段的結(jié)束，我們要把控好技術(shù)文檔和代碼質(zhì)量，從而減少線下bug率及線上的故障；

2.1 技術(shù)方案

2.1.1 技術(shù)方案評(píng)審

技術(shù)文檔的評(píng)審需要有本團(tuán)隊(duì)的架構(gòu)師和相關(guān)研發(fā)，測(cè)試，產(chǎn)品，上下游系統(tǒng)的研發(fā)同學(xué)參與，這樣能夠最大限度的保證技術(shù)方案的實(shí)現(xiàn)和產(chǎn)品需求對(duì)齊，上下游系統(tǒng)同學(xué)也知道我們的實(shí)現(xiàn)，采取更加合理的交互方式，測(cè)試同學(xué)也可以從測(cè)試視角給出一些風(fēng)險(xiǎn)點(diǎn)建議，架構(gòu)師可以確保我們的實(shí)現(xiàn)和業(yè)界最佳實(shí)踐的差異，確保合理性，避免過(guò)度設(shè)計(jì)；我們所要做的是開放心態(tài)采取大家的意見(jiàn)，嚴(yán)控技術(shù)文檔的質(zhì)量；

技術(shù)文檔的評(píng)審可以采用提問(wèn)的方式，會(huì)議開始前可以將技術(shù)文檔分享給大家，讓大家先閱讀10分鐘，所有同學(xué)開始提問(wèn)，技術(shù)文檔設(shè)計(jì)人其實(shí)不用讀自己的技術(shù)文檔給大家介紹，只要將大家的問(wèn)題回答完，并能夠思考下大家的建議，合理的采納后，其實(shí)技術(shù)文檔的質(zhì)量就有了很大的保證，有的同學(xué)在技術(shù)文檔評(píng)審時(shí)，比較反感大家的提問(wèn)，總感覺(jué)在挑戰(zhàn)自己，有些問(wèn)題回答不上來(lái)，其實(shí)可以換種思路：有些問(wèn)題回答不上來(lái)是正常的，可以先將大家的建議采納了，會(huì)后再思考下合理性；大家對(duì)自己技術(shù)方案是建言獻(xiàn)策，是保證自己技術(shù)方案的質(zhì)量，避免在技術(shù)方案階段就存在重大的線上隱患。

2.1.2 技術(shù)方案關(guān)注點(diǎn)

當(dāng)我們遇到一個(gè)問(wèn)題的時(shí)候，首先要思考的這是一個(gè)新問(wèn)題還是老問(wèn)題，99.99%遇到的都是老問(wèn)題，因?yàn)槲覀兯鶑氖碌氖枪こ碳夹g(shù)，不是科學(xué)探索；我們所要做的就是看下國(guó)內(nèi)外同行針對(duì)這個(gè)問(wèn)題的解法，learn from best practices；所以技術(shù)方案的第一步是對(duì)標(biāo)，學(xué)習(xí)最佳實(shí)踐，這樣能讓我們避免走彎路；

同時(shí)根據(jù)奧卡姆剃刀原理，我們力求技術(shù)方案簡(jiǎn)單，避免過(guò)度設(shè)計(jì)，針對(duì)一個(gè)復(fù)雜的問(wèn)題，我們的技術(shù)方案相對(duì)復(fù)雜些，簡(jiǎn)單的問(wèn)題技術(shù)方案相對(duì)簡(jiǎn)單些，我們所要追求的是復(fù)雜的問(wèn)題通過(guò)拆解劃分，用一個(gè)個(gè)簡(jiǎn)單的技術(shù)方案解決掉。同時(shí)技術(shù)文檔不僅關(guān)注功能的實(shí)現(xiàn)，更重要的是關(guān)注架構(gòu)，性能，質(zhì)量，安全；即如何打造一個(gè)高可用系統(tǒng)。打造一個(gè)高可用的系統(tǒng)是進(jìn)行系統(tǒng)穩(wěn)定性建設(shè)的前提，如果我們的系統(tǒng)都不能保證高可用，又談何系統(tǒng)穩(wěn)定系建設(shè)那，下面介紹下進(jìn)行系統(tǒng)穩(wěn)定性建設(shè)我們?cè)诩夹g(shù)方案中常用的方法及關(guān)注點(diǎn)。

2.1.2.1 限流

限流一般是從服務(wù)提供者provider的視角提供的針對(duì)自我保護(hù)的能力，對(duì)于流量負(fù)載超過(guò)我們系統(tǒng)的處理能力，限流策略可以防止我們的系統(tǒng)被激增的流量打垮。京東內(nèi)部無(wú)論是同步交互的JSF, 還是異步交互的JMQ都提供了限流的能力，大家可以根據(jù)自己系統(tǒng)的情況進(jìn)行設(shè)置；我們知道常見(jiàn)的限流算法包括：計(jì)數(shù)器算法，滑動(dòng)時(shí)間窗口算法，漏斗算法，令牌桶算法，具體算法可以網(wǎng)上google下，下面是這些算法的優(yōu)缺點(diǎn)對(duì)比。

2.1.2.2 熔斷降級(jí)

熔斷和降級(jí)是兩件事情，但是他們一般是結(jié)合在一起使用的。熔斷是防止我們的系統(tǒng)被下游系統(tǒng)拖垮，比如下游系統(tǒng)接口性能嚴(yán)重變差，甚至下游系統(tǒng)掛了；這個(gè)時(shí)候會(huì)導(dǎo)致大量的線程堆積，不能釋放占用的CPU，內(nèi)存等資源，這種情況下不僅影響該接口的性能，還會(huì)影響其他接口的性能，嚴(yán)重的情況會(huì)將我們的系統(tǒng)拖垮，造成雪崩效應(yīng)，通過(guò)打開熔斷器，流量不再請(qǐng)求到有問(wèn)題的系統(tǒng)，可以保護(hù)我們的系統(tǒng)不被拖垮。降級(jí)是一種有損操作，我們作為服務(wù)提供者，需要將這種損失盡可能降到最低，無(wú)論是返回友好的提示，還是返回可接受的降級(jí)數(shù)據(jù)。降級(jí)細(xì)分的話又分為人工降級(jí)，自動(dòng)降級(jí)。

人工降級(jí)：人工降級(jí)一般采用降級(jí)開關(guān)來(lái)控制，公司內(nèi)部一般采用配置中心Ducc來(lái)做開關(guān)降級(jí)，開關(guān)的修改也是線上操作，這塊也需要做好監(jiān)控

自動(dòng)降級(jí)：自動(dòng)降級(jí)是采用自動(dòng)化的中間件例如Hystrix，公司的小盾龍等；如果采用自動(dòng)降級(jí)的話；我們必須要對(duì)降級(jí)的條件非常的明確，比如失敗的調(diào)用次數(shù)等；

2.1.2.3 超時(shí)

分布式系統(tǒng)中的難點(diǎn)之一：不可靠的網(wǎng)絡(luò)，京東物流現(xiàn)有的微服務(wù)架構(gòu)下，服務(wù)之間都是通過(guò)JSF網(wǎng)絡(luò)交互進(jìn)行同步通信，我們探測(cè)下游依賴服務(wù)是否可用的最快捷的方式是設(shè)置超時(shí)時(shí)間。超時(shí)的設(shè)置可以讓系統(tǒng)快速失敗，進(jìn)行自我保護(hù)，避免無(wú)限等待下游依賴系統(tǒng)，將系統(tǒng)的線程耗盡，系統(tǒng)拖垮。

超時(shí)時(shí)間如何設(shè)置也是一門學(xué)問(wèn)，如何設(shè)置一個(gè)合理的超時(shí)時(shí)間也是一個(gè)逐步迭代的過(guò)程，比如下游新開發(fā)的接口，一般會(huì)基于壓測(cè)提供一個(gè)TP99的耗時(shí)，我們會(huì)基于此配置超時(shí)時(shí)間；老接口的話，會(huì)基于線上的TP99耗時(shí)來(lái)配置超時(shí)時(shí)間。

超時(shí)時(shí)間在設(shè)置的時(shí)候需要遵循漏斗原則，從上游系統(tǒng)到下游系統(tǒng)設(shè)置的超時(shí)時(shí)間要逐漸減少，如下圖所示。為什么要滿足漏斗原則，假設(shè)不滿足漏斗原則，比如服務(wù)A調(diào)取服務(wù)B的超時(shí)時(shí)間設(shè)置成500ms，而服務(wù)B調(diào)取服務(wù)C的超時(shí)時(shí)間設(shè)置成800ms，這個(gè)時(shí)候回導(dǎo)致服務(wù)A調(diào)取服務(wù)B大量的超時(shí)從而導(dǎo)致可用率降低，而此時(shí)服務(wù)B從自身角度看是可用的；

2.1.2.4 重試

分布式系統(tǒng)中性能的影響主要是通信，無(wú)論是在分布式系統(tǒng)中還是垮團(tuán)隊(duì)溝通，communication是最昂貴的；比如我們研發(fā)都知道需求的交付有一半以上甚至更多的時(shí)間花在跨團(tuán)隊(duì)的溝通上，真正寫代碼的時(shí)間是很少的；分布式系統(tǒng)中我們查看調(diào)用鏈路，其實(shí)我們系統(tǒng)本身計(jì)算的耗時(shí)是很少的，主要來(lái)自于外部系統(tǒng)的網(wǎng)絡(luò)交互，無(wú)論是下游的業(yè)務(wù)系統(tǒng)，還是中間件：Mysql, redis, es等等；

所以在和外部系統(tǒng)的一次請(qǐng)求交互中，我們系統(tǒng)是希望盡最大努力得到想要的結(jié)果，但往往事與愿違，由于不可靠網(wǎng)絡(luò)的原因，我們?cè)诤拖掠蜗到y(tǒng)交互時(shí)，都會(huì)配置超時(shí)重試次數(shù)，希望在可接受的SLA范圍內(nèi)一次請(qǐng)求拿到結(jié)果，但重試不是無(wú)限的重試，我們一般都是配置重試次數(shù)的限制，偶爾抖動(dòng)的重試可以提高我們系統(tǒng)的可用率，如果下游服務(wù)故障掛掉，重試反而會(huì)增加下游系統(tǒng)的負(fù)載，從而增加故障的嚴(yán)重程度。在一次請(qǐng)求調(diào)用中，我們要知道對(duì)外提供的API，后面是有多少個(gè)service在提供服務(wù)，如果調(diào)用鏈路比較長(zhǎng)，服務(wù)之間rpc交互都設(shè)置了重試次數(shù)，這個(gè)時(shí)候我們需要警惕重試風(fēng)暴。如下圖service D 出現(xiàn)問(wèn)題，重試風(fēng)暴會(huì)加重service D的故障嚴(yán)重程度。對(duì)于API的重試，我們還要區(qū)分該接口是讀接口還是寫接口，如果是讀接口重試一般沒(méi)什么影響，寫接口重試一定要做好接口的冪等性。

2.1.2.5 兼容

我們?cè)趯?duì)老系統(tǒng)，老功能進(jìn)行重構(gòu)迭代的時(shí)候，一定要做好兼容，否則上線后會(huì)出現(xiàn)重大的線上問(wèn)題，公司內(nèi)外有大量因?yàn)闆](méi)有做好兼容性，而導(dǎo)致資損的情況。兼容分為：向前兼容性和向后兼容性，需要好好的區(qū)分他們，如下是他們的定義:

向前兼容性：向前兼容性指的是舊版本的軟件或硬件能夠與將來(lái)推出的新版本兼容的特性，簡(jiǎn)而言之舊版本軟件或系統(tǒng)兼容新的數(shù)據(jù)和流量。

向后兼容性：向后兼容性則是指新版本的軟件或硬件能夠與之前版本的系統(tǒng)或組件兼容的特性，簡(jiǎn)而言之新版本軟件或系統(tǒng)兼容老的數(shù)據(jù)和流量。

根據(jù)新老系統(tǒng)和新老數(shù)據(jù)我們可以將系統(tǒng)劃分為四個(gè)象限：第一象限：新系統(tǒng)和新數(shù)據(jù)是我們系統(tǒng)改造上線后的狀態(tài)，第三象限：老系統(tǒng)和老數(shù)據(jù)是我們系統(tǒng)改造上線前的狀態(tài)，第一象限和第三象限的問(wèn)題我們?cè)谘邪l(fā)和測(cè)試階段一般都能發(fā)現(xiàn)排除掉，線上故障的高發(fā)期往往出現(xiàn)在第二和第四象限，第二象限是因?yàn)闆](méi)有做好向前兼容性，例如上線過(guò)程中，發(fā)現(xiàn)問(wèn)題進(jìn)行了代碼回滾，但是在上線過(guò)程中產(chǎn)生了新數(shù)據(jù)，回滾后的老系統(tǒng)不能處理上線過(guò)程中新產(chǎn)生的數(shù)據(jù)，導(dǎo)致線上故障。第四象限是因?yàn)闆](méi)有做好向后兼容性，上線后新系統(tǒng)影響了老流程。針對(duì)第二象限的問(wèn)題，我們可以構(gòu)造新的數(shù)據(jù)去驗(yàn)證老的系統(tǒng)，針對(duì)第四象限的問(wèn)題，我們可以通過(guò)流量的錄制回放解決，錄制線上的老流量，對(duì)新功能進(jìn)行驗(yàn)證。

2.1.2.6 隔離

隔離是將故障爆炸半徑最小化的有效手段，在技術(shù)方案設(shè)計(jì)中，我們通過(guò)不同層面的隔離來(lái)控制影響范圍：

2.1.2.6.1 系統(tǒng)層面隔離

我們知道系統(tǒng)的分類可以分為：在線的系統(tǒng)，離線系統(tǒng)（批處理系統(tǒng)），近實(shí)時(shí)系統(tǒng)（流處理系統(tǒng)），如下是這些系統(tǒng)的定義：

在線系統(tǒng)：服務(wù)端等待請(qǐng)求的到達(dá)，接收到請(qǐng)求后，服務(wù)盡可能快的處理，然后返回給客戶端一個(gè)響應(yīng)，響應(yīng)時(shí)間通常是在線服務(wù)性能的主要衡量指標(biāo)。我們生活中在手機(jī)使用的APP大部分都是在線系統(tǒng)；

離線系統(tǒng)：或稱批處理系統(tǒng)，接收大量的輸入數(shù)據(jù)，運(yùn)行一個(gè)作業(yè)來(lái)處理數(shù)據(jù)，并產(chǎn)出輸出數(shù)據(jù)，作業(yè)往往需要定時(shí)，定期運(yùn)行一段時(shí)間，比如從幾分鐘到幾天，所以用戶通常不會(huì)等待作業(yè)完成，吞吐量是離線系統(tǒng)的主要衡量指標(biāo)。例如我們看到的報(bào)表數(shù)據(jù)：日訂單量，月訂單量，日活躍用戶數(shù)，月活躍用戶數(shù)都是批處理系統(tǒng)運(yùn)算一段時(shí)間得到的；

近實(shí)時(shí)系統(tǒng)：或者稱流處理系統(tǒng)，其介于在線系統(tǒng)和離線系統(tǒng)之間，流處理系統(tǒng)一般會(huì)有觸發(fā)源：用戶的行為操作，數(shù)據(jù)庫(kù)的寫操作，傳感器等，觸發(fā)源作為消息會(huì)通過(guò)消息代理中間件：JMQ, KAFKA等進(jìn)行傳遞，消費(fèi)者消費(fèi)到消息后再做其他的操作，例如構(gòu)建緩存，索引，通知用戶等；

以上三種系統(tǒng)是需要進(jìn)行隔離建設(shè)的，因?yàn)樗麄兊暮饬恐笜?biāo)及對(duì)資源的使用情況完全不一樣的，比如我們小組會(huì)將在線系統(tǒng)作為一個(gè)服務(wù)單獨(dú)部署：jdl-uep-main, 離線系統(tǒng)和近實(shí)時(shí)系統(tǒng)作為一個(gè)服務(wù)單獨(dú)部署：jdl-uep-worker；

2.1.2.6.2 環(huán)境的隔離

從研發(fā)到上線階段我們會(huì)使用不同的環(huán)境，比如業(yè)界常見(jiàn)的環(huán)境分為：開發(fā)，測(cè)試，預(yù)發(fā)和線上環(huán)境；研發(fā)人員在開發(fā)環(huán)境進(jìn)行開發(fā)和聯(lián)調(diào)，測(cè)試人員在測(cè)試環(huán)境進(jìn)行測(cè)試，運(yùn)營(yíng)和產(chǎn)品在預(yù)發(fā)環(huán)境進(jìn)行UAT，最終交付的產(chǎn)品部署到線上環(huán)境提供給用戶使用。在研發(fā)流程中，我們部署時(shí)要遵循從應(yīng)用層到中間件層再到存儲(chǔ)層，都要在一個(gè)環(huán)境，嚴(yán)禁垮環(huán)境的調(diào)用，比如測(cè)試環(huán)境調(diào)用線上，預(yù)發(fā)環(huán)境調(diào)用線上等。

2.1.2.6.3 數(shù)據(jù)的隔離

隨著業(yè)務(wù)的發(fā)展，我們對(duì)外提供的服務(wù)往往會(huì)支撐多業(yè)務(wù)，多租戶，所以這個(gè)時(shí)候我們會(huì)按照業(yè)務(wù)進(jìn)行數(shù)據(jù)隔離；比如我們組產(chǎn)生的物流訂單數(shù)據(jù)業(yè)務(wù)方就包含京東零售，其他電商平臺(tái)，ISV等，為了避免彼此的影響我們需要在存儲(chǔ)層對(duì)數(shù)據(jù)進(jìn)行隔離，數(shù)據(jù)的隔離可以按照不同粒度，第一種是通過(guò)租戶id字段進(jìn)行區(qū)分，所有的數(shù)據(jù)存儲(chǔ)在一張表中，另外一個(gè)是庫(kù)粒度的區(qū)分，不同的租戶單獨(dú)分配對(duì)應(yīng)的數(shù)據(jù)庫(kù)。

數(shù)據(jù)的隔離除了按照業(yè)務(wù)進(jìn)行隔離外，還有按照環(huán)境進(jìn)行隔離的，比如我們的數(shù)據(jù)庫(kù)分為測(cè)試庫(kù)，預(yù)發(fā)庫(kù)，線上庫(kù)，全鏈路壓測(cè)時(shí)，我們?yōu)榱四M線上的環(huán)境，同時(shí)避免污染線上的數(shù)據(jù)，往往會(huì)創(chuàng)建影子庫(kù)，影子表等。根據(jù)數(shù)據(jù)的訪問(wèn)頻次進(jìn)行隔離，我們將經(jīng)常訪問(wèn)的數(shù)據(jù)稱為熱數(shù)據(jù)，不經(jīng)常訪問(wèn)的數(shù)據(jù)稱為冷數(shù)據(jù)；將經(jīng)常訪問(wèn)的數(shù)據(jù)緩存到緩存，提高系統(tǒng)的性能。不經(jīng)常訪問(wèn)的數(shù)據(jù)持久化到數(shù)據(jù)庫(kù)或者將不使用的數(shù)據(jù)結(jié)轉(zhuǎn)歸檔到

2.1.2.6.4 核心，非核心隔離

我們知道應(yīng)用是分級(jí)的，京東內(nèi)部針對(duì)應(yīng)用的重要程度會(huì)將應(yīng)用分為0，1，2，3級(jí)應(yīng)用。業(yè)務(wù)的流程也分為黃金流程和非黃金流程。在業(yè)務(wù)流程中，針對(duì)不同級(jí)別的應(yīng)用交互，需要將核心和非核心的流程進(jìn)行隔離。例如在交易業(yè)務(wù)過(guò)程中，會(huì)涉及到訂單系統(tǒng)，支付系統(tǒng)，通知系統(tǒng)，那這個(gè)過(guò)程中核心系統(tǒng)是訂單系統(tǒng)和支付系統(tǒng)，而通知相對(duì)來(lái)說(shuō)重要性不是那么高，所以我們會(huì)投入更多的資源到訂單系統(tǒng)和支付系統(tǒng)，優(yōu)先保證這兩個(gè)系統(tǒng)的穩(wěn)定性，通知系統(tǒng)可以采用異步的方式與其他兩個(gè)系統(tǒng)解耦隔離，避免對(duì)其他另外兩個(gè)系統(tǒng)的影響。

2.1.2.6.5 讀寫隔離

應(yīng)用層面，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）中最著名的CQRS（Command Query Responsibility Segregation）將寫服務(wù)和讀服務(wù)進(jìn)行隔離。寫服務(wù)主要處理來(lái)自客戶端的command寫命令，而讀服務(wù)處理來(lái)自客戶端的query讀請(qǐng)求，這樣從應(yīng)用層面進(jìn)行讀寫隔離，不僅可以提高系統(tǒng)的可擴(kuò)展性，同時(shí)也會(huì)提高系統(tǒng)的可維護(hù)性，應(yīng)用層面我們都采用微服務(wù)架構(gòu)，應(yīng)用層都是無(wú)狀態(tài)服務(wù)，可以擴(kuò)容加機(jī)器隨意擴(kuò)展，存儲(chǔ)層需要持久化，擴(kuò)展就比較費(fèi)勁。除了應(yīng)用層面的CQRS，在存儲(chǔ)層面，我們也會(huì)進(jìn)行讀寫隔離，例如數(shù)據(jù)庫(kù)都會(huì)采用一主多從的架構(gòu)，讀請(qǐng)求可以路由到從庫(kù)從而分擔(dān)主庫(kù)的壓力，提高系統(tǒng)的性能和吞吐量。所以應(yīng)用層面通過(guò)讀寫隔離主要解決可擴(kuò)展問(wèn)題，存儲(chǔ)層面主要解決性能和吞吐量的問(wèn)題。

?

2.1.2.6.6 線程池隔離

線程是昂貴的資源，為了提高線程的使用效率，避免創(chuàng)建和銷毀的消耗，我們采用了池化技術(shù)，線程池來(lái)復(fù)用線程，但是在使用線程池的過(guò)程中，我們也做好線程池的隔離，避免多個(gè)API接口復(fù)用同一個(gè)線程。

2.2 代碼Review

codeReview是研發(fā)階段的最后一個(gè)流程，對(duì)線下的bug率和線上質(zhì)量及穩(wěn)定性有著重要的作用，針對(duì)于代碼如何review，談一些自己的看法：

?形成團(tuán)隊(duì)代碼風(fēng)格：首先一個(gè)團(tuán)隊(duì)的代碼應(yīng)該形成該團(tuán)隊(duì)的代碼風(fēng)格，這樣能夠提高codeReview的效率及協(xié)作的效率，作為新加入的成員，應(yīng)該遵循團(tuán)隊(duì)的代碼風(fēng)格規(guī)范。

?Review的關(guān)注點(diǎn)：代碼review切記不要陷入細(xì)節(jié)，主要以review代碼風(fēng)格為主，如果一個(gè)團(tuán)隊(duì)形成統(tǒng)一的代碼風(fēng)格，我們通過(guò)review風(fēng)格就能將大部分問(wèn)題發(fā)現(xiàn)，在關(guān)注功能的同時(shí)，再關(guān)注下性能，安全。

?結(jié)對(duì)編程：在代碼編寫過(guò)程中，我們要培養(yǎng)結(jié)對(duì)編程的習(xí)慣，這樣針對(duì)某次需求，codeReview時(shí)，熟悉該模塊的同事把控下細(xì)節(jié)，架構(gòu)師把控風(fēng)格。

?控制每次review代碼量：每次提交代碼進(jìn)行review時(shí)，不要一次性提交review大量的代碼，要將review的內(nèi)容細(xì)分，比如一個(gè)方法的實(shí)現(xiàn)，一個(gè)類等。

?開放心態(tài)：review的過(guò)程其實(shí)是學(xué)習(xí)提升的過(guò)程，通過(guò)代碼review，虛心接收別人的意見(jiàn)，學(xué)習(xí)優(yōu)雅代碼的編寫方式，提高自己的代碼水平。

3 上線階段

我們可以看下公司的故障管理平臺(tái)白虎所記錄的故障：發(fā)生系統(tǒng)故障一般都是外部對(duì)系統(tǒng)做了改變，往往發(fā)生在上線階段：代碼的部署，數(shù)據(jù)庫(kù)的更改，配置中心的變動(dòng)等；上線階段是故障的高發(fā)期；一個(gè)系統(tǒng)不可能不出線上問(wèn)題，我們所要追求的是，降低線上的故障頻率，縮短故障恢復(fù)時(shí)間。針對(duì)上線過(guò)程出現(xiàn)問(wèn)題，我們知道業(yè)界有著名的上線過(guò)程三板斧：可監(jiān)控，可灰度，可回滾。

3.1 上線三板斧

3.1.1 可監(jiān)控

上線的過(guò)程中，我們的系統(tǒng)要做到可監(jiān)控，如果沒(méi)有監(jiān)控，上線過(guò)程中我們對(duì)系統(tǒng)的狀態(tài)是一無(wú)所知，是很可怕的。監(jiān)控什么東西那，其實(shí)監(jiān)控的就是指標(biāo)。這就涉及到指標(biāo)的定義，指標(biāo)我們分為業(yè)務(wù)指標(biāo)和技術(shù)指標(biāo)，技術(shù)指標(biāo)又分為軟件和硬件。業(yè)務(wù)指標(biāo)一般是我們定義的觀測(cè)業(yè)務(wù)變化情況的度量，例如訂單量，支付量等。技術(shù)層面的軟件指標(biāo)：可用率，TP99, 調(diào)用量，技術(shù)層面的硬件指標(biāo)：cpu 內(nèi)存 磁盤 網(wǎng)絡(luò)IO。目前我們二級(jí)部門在做OpsReview，主要review的是可用率，TP99，調(diào)用量這幾個(gè)指標(biāo)，分別對(duì)應(yīng)系統(tǒng)的可用性，性能，并發(fā)。

做好這些指標(biāo)的監(jiān)控后，我們接下來(lái)需要做的是針對(duì)這些指標(biāo)做好告警，如果某個(gè)指標(biāo)突破設(shè)定的閾值后，需要進(jìn)行告警通知給我們，針對(duì)監(jiān)控告警指標(biāo)閾值的設(shè)置，建議先嚴(yán)后松，即系統(tǒng)建設(shè)初始階段設(shè)置的嚴(yán)格些，避免遺漏告警，出現(xiàn)線上問(wèn)題，后續(xù)隨著系統(tǒng)建設(shè)的迭代需要設(shè)置更合理的告警閾值，避免告警泛濫，造成狼來(lái)了的效應(yīng)。總之上線發(fā)布過(guò)程的一段時(shí)間是事故和問(wèn)題發(fā)生的高峰，這塊一定做好指標(biāo)監(jiān)控，日志監(jiān)控，對(duì)報(bào)警要敏感。

3.1.2 可灰度

上線過(guò)程中，我們要做到可灰度，通過(guò)灰度執(zhí)行變更以限制爆炸半徑，降低影響范圍，同時(shí)灰度過(guò)程要做好兼容?；叶确譃椴煌S度的灰度：機(jī)器維度，機(jī)房維度，地域維度，業(yè)務(wù)維度：用戶，商家，倉(cāng)，承運(yùn)商等。

機(jī)器維度：我們用行云部署時(shí)，可以每個(gè)分組先部署一部分機(jī)器進(jìn)行灰度，灰度一段時(shí)間比如：24小時(shí)沒(méi)什么問(wèn)題后，再部署剩余的機(jī)器。

機(jī)房維度：微服務(wù)架構(gòu)下，我們的應(yīng)用會(huì)部署在不同的機(jī)房中，可以按照機(jī)房維度灰度，比如先部署發(fā)布代碼在某個(gè)機(jī)房分組下，觀察一段時(shí)間再按照比例擴(kuò)大灰度機(jī)房范圍直至全量。例如先部署中云信的機(jī)房，灰度一段時(shí)間后，再逐步灰度有孚的機(jī)房。

地域維度：現(xiàn)在的部署架構(gòu)都是多機(jī)房互為災(zāi)備，異地多活，單元化部署，例如業(yè)界美團(tuán)的外賣業(yè)務(wù)非常適合做異地多活，單元化部署，因?yàn)橥赓u業(yè)務(wù)的商戶，用戶，騎手天然具有聚合性，北京的用戶大概率不會(huì)在上海點(diǎn)外賣，這樣根據(jù)業(yè)務(wù)的屬性，在系統(tǒng)建設(shè)的時(shí)候，從應(yīng)用層到中間件層，再到存儲(chǔ)層可以單元化部署在上海地域的機(jī)房和北京地域的機(jī)房，功能發(fā)布的時(shí)候可以灰度某個(gè)地域，做到地域級(jí)別的容災(zāi)。

業(yè)務(wù)維度：在上線過(guò)程中，我們也可以根據(jù)業(yè)務(wù)屬性進(jìn)行灰度，例如上線了某個(gè)功能或者產(chǎn)品，根據(jù)用戶維度灰度，某些用戶或者某些商戶才能使用該功能，產(chǎn)品。

3.1.3 可回滾

線上出現(xiàn)問(wèn)題時(shí)，我們應(yīng)該優(yōu)先止損，其次才是分析根因。止損的最快方式就是回滾，回滾分為代碼回滾和數(shù)據(jù)回滾，代碼回滾即將我們代碼恢復(fù)到原有的邏輯，代碼回滾有兩種方式：開關(guān)控制和部署回滾。最快捷的方式是開關(guān)控制，一鍵開關(guān)打開或者關(guān)閉就可以實(shí)現(xiàn)回滾到原有的邏輯，操作成本最低，止損最快速。第二種方式就是部署回滾，通過(guò)發(fā)布平臺(tái)，例如行云將代碼回滾到上個(gè)穩(wěn)定運(yùn)行的版本。有時(shí)候我們代碼回滾完，如果沒(méi)有做好向前兼容性，系統(tǒng)應(yīng)用依然有問(wèn)題，例如上線過(guò)程中產(chǎn)生了新數(shù)據(jù)，回滾完后，代碼不能處理新的數(shù)據(jù)。所以這個(gè)時(shí)候又涉及到數(shù)據(jù)的回滾，數(shù)據(jù)的回滾涉及到修數(shù)：將產(chǎn)生的新數(shù)據(jù)無(wú)效掉，或者修改為正確的數(shù)據(jù)等，當(dāng)數(shù)據(jù)量比較大時(shí)，數(shù)據(jù)的回滾一般耗時(shí)費(fèi)力，所以建議做好向前兼容性，直接代碼回滾。

3.2 線上問(wèn)題應(yīng)對(duì)

3.2.1 常見(jiàn)問(wèn)題分類

針對(duì)線上的問(wèn)題，我們第一步是識(shí)別出是什么問(wèn)題，然后才能解決問(wèn)題，針對(duì)線上各種各樣的問(wèn)題我們可以進(jìn)行聚合，歸并分類下，針對(duì)每種問(wèn)題去參考業(yè)界的處理方法和團(tuán)隊(duì)的內(nèi)的緊急預(yù)案，做到臨陣不亂。

3.2.2 問(wèn)題生命周期

當(dāng)出現(xiàn)問(wèn)題時(shí)，我們也需要清楚一個(gè)線上問(wèn)題的生命周期：從問(wèn)題發(fā)生，到我們發(fā)現(xiàn)問(wèn)題，進(jìn)而進(jìn)行響應(yīng)處理，觀測(cè)問(wèn)題是否修復(fù)，服務(wù)是否恢復(fù)正常，到最終針對(duì)該問(wèn)題進(jìn)行復(fù)盤，當(dāng)發(fā)生系統(tǒng)發(fā)生問(wèn)題時(shí)，我們?cè)皆绨l(fā)現(xiàn)問(wèn)題，對(duì)業(yè)務(wù)的影響越小，整個(gè)流程如下圖所示。

3.2.3 如何預(yù)防問(wèn)題

就像人的身體生病一樣，當(dāng)問(wèn)題發(fā)生已經(jīng)晚了，我們要投入更多時(shí)間和精力到如何預(yù)防中，就像扁鵲的大哥一樣治未病，防患于未然。根據(jù)破窗原理，一個(gè)問(wèn)題出現(xiàn)了，如果放任不管，問(wèn)題的嚴(yán)重性會(huì)越來(lái)越大，直到不可挽回。我們可以從研發(fā)的規(guī)范，研發(fā)的流程，變更流程這幾個(gè)方面進(jìn)行預(yù)防。

3.2.4 如何發(fā)現(xiàn)問(wèn)題

對(duì)于一個(gè)系統(tǒng)，如果外界不對(duì)其做功，根據(jù)熵增原理，其會(huì)越來(lái)越混亂，直到出現(xiàn)問(wèn)題，外界對(duì)其做功，就涉及到改變，因?yàn)楦淖兪侨嗽诓僮?，由于各種不可控的因素，也會(huì)導(dǎo)致各種線上問(wèn)題，所以我們可以看到對(duì)于一個(gè)系統(tǒng)上線后不出現(xiàn)問(wèn)題是不可能的，當(dāng)出現(xiàn)問(wèn)題時(shí)，我們第一步是如何快速的發(fā)現(xiàn)問(wèn)題？對(duì)于問(wèn)題發(fā)現(xiàn)的渠道，工作中接觸到的有如下幾種：自我意識(shí)，監(jiān)控告警，業(yè)務(wù)反饋；

自我意識(shí)：我們C2部門每周有一個(gè)重要會(huì)議OpsReview，各個(gè)C3團(tuán)隊(duì)會(huì)對(duì)個(gè)團(tuán)隊(duì)的核心接口的不規(guī)律跳點(diǎn)，毛刺進(jìn)行可用率，性能，調(diào)用量的review，以通過(guò)這種主動(dòng)的，自我意識(shí)行為發(fā)現(xiàn)潛在的線上問(wèn)題。同時(shí)我們組每天早會(huì)的重要一項(xiàng)：UMP監(jiān)控全域看板的review，我們會(huì)對(duì)昨天核心接口的可用率，TP99，調(diào)用量，進(jìn)行分析的，對(duì)于可用率降低，TP99有毛刺，不規(guī)范的流量調(diào)用會(huì)進(jìn)行排查原因，盡早自我發(fā)現(xiàn)問(wèn)題，同時(shí)也會(huì)對(duì)機(jī)器的CPU, 內(nèi)存使用率，Mysql, redis , es各種存儲(chǔ)進(jìn)行review。

監(jiān)控告警：這是我們發(fā)現(xiàn)問(wèn)題最常用的渠道，通過(guò)主動(dòng)的監(jiān)控指標(biāo)，被動(dòng)的接收告警來(lái)發(fā)現(xiàn)問(wèn)題，告警指標(biāo)我們分為業(yè)務(wù)指標(biāo)和技術(shù)指標(biāo)，具體分類可詳見(jiàn)3.1.1可監(jiān)控部分

業(yè)務(wù)反饋：這種發(fā)現(xiàn)問(wèn)題的方式是我們最不愿意看到的，如果等到業(yè)務(wù)反饋，說(shuō)明線上問(wèn)題已經(jīng)影響到用戶，我們常常因?yàn)楸O(jiān)控告警的缺失，漏報(bào)而導(dǎo)致落后于業(yè)務(wù)發(fā)現(xiàn)問(wèn)題，所以我們最希望每個(gè)人，團(tuán)隊(duì)都有這種自我意識(shí)，將線上問(wèn)題提早發(fā)現(xiàn)，防患于未然。

3.2.5 如何響應(yīng)問(wèn)題

出現(xiàn)線上問(wèn)題后，我們個(gè)人對(duì)問(wèn)題的認(rèn)知是非常有限的，并且這個(gè)時(shí)候人處于一種高度緊張的狀態(tài)，所以這個(gè)時(shí)候一定要群里周知自己的leader，將情況如實(shí)表達(dá)，不要夸大和縮小問(wèn)題的范圍和影響，同時(shí)將問(wèn)題進(jìn)行通告。整個(gè)問(wèn)題的響應(yīng)過(guò)程包含以下幾步：

1.保留現(xiàn)場(chǎng)：問(wèn)題發(fā)生的現(xiàn)場(chǎng)是我們排查問(wèn)題的依據(jù)，所以要將現(xiàn)場(chǎng)的日志，數(shù)據(jù)等信息保存好，比如內(nèi)存dump, 線程dump，避免機(jī)器重啟后這些信息的丟失。

2.提供信息：提供自己所知道的信息，協(xié)助排查，不要擴(kuò)大和縮小問(wèn)題

3.恢復(fù)服務(wù)：當(dāng)出現(xiàn)線上問(wèn)題是，我們追求的是以最快的速度恢復(fù)服務(wù)，快速止損，業(yè)界有快速止血，恢復(fù)服務(wù)的幾板斧：回滾：服務(wù)回滾，數(shù)據(jù)回滾，重啟，擴(kuò)容，禁用節(jié)點(diǎn)，功能降級(jí)

4.雙重確認(rèn)：服務(wù)恢復(fù)后，我們需要確認(rèn)是否恢復(fù)了，可以通過(guò)觀察：業(yè)務(wù)指標(biāo)是否正常，技術(shù)指標(biāo)是否正常，數(shù)據(jù)是否正常，日志是否正常等來(lái)觀測(cè)問(wèn)題的恢復(fù)情況

5.故障通告：確認(rèn)問(wèn)題沒(méi)有什么問(wèn)題后，需要再應(yīng)急群中周知大家：業(yè)務(wù)人員，產(chǎn)品經(jīng)理，系統(tǒng)的上下游，測(cè)試人員，SRE等。并讓產(chǎn)品和業(yè)務(wù)進(jìn)行確認(rèn)，然后周知用戶。

3.2.6 如何定位問(wèn)題

服務(wù)恢復(fù)后，我們可以回過(guò)頭來(lái)細(xì)致的分析下到底是什么原因?qū)е铝司€上的問(wèn)題。定位問(wèn)題也要講究方法論，這就涉及到定位問(wèn)題三要素：知識(shí)，工具，方法。

知識(shí)：相對(duì)其他行業(yè)，計(jì)算機(jī)行業(yè)應(yīng)該是知識(shí)更新迭代最快的行業(yè)，所以我們需要不斷的去學(xué)習(xí)，更新自己的知識(shí)庫(kù)，不給自己設(shè)限。例如你想解決FullGC問(wèn)題，你必須對(duì)JVM進(jìn)行系統(tǒng)的學(xué)習(xí)，想解決慢sql，必須對(duì)Mysql進(jìn)行系統(tǒng)的學(xué)習(xí)，現(xiàn)在AI大模型這么火，我們也需要對(duì)prompt engineering， RAG ， Agent, 多模態(tài)等進(jìn)行學(xué)習(xí)了解。有了知識(shí)我們才能遇到問(wèn)題時(shí)，知道是什么，為什么？

工具：工欲善其事，必先利其器，工程師要善于借助公司工具來(lái)提高解決問(wèn)題的效率，熟練使用公司各種中間件工具，公司已經(jīng)有的中間件，優(yōu)先使用公司的中間件，公司內(nèi)一個(gè)中間件團(tuán)隊(duì)維護(hù)的中間件工具要優(yōu)于業(yè)務(wù)研發(fā)小組內(nèi)維護(hù)的中間件工具，不要小組內(nèi)部，或者團(tuán)隊(duì)內(nèi)部重復(fù)造輪子，并且小組內(nèi)人員的流動(dòng)變更，容易造成中間件沒(méi)人維護(hù)。下圖是公司常用的中間件工具：

方法：解決問(wèn)題我們要講究方法，選擇正確的方法可以事半功倍，提高我們定位問(wèn)題及解決問(wèn)題的效率，下面是我們研發(fā)人員常見(jiàn)的排查問(wèn)題的方法

3.2.7 如何修復(fù)問(wèn)題

有了知識(shí)，工具和方法后，其實(shí)我們很快的就定位到問(wèn)題了，定位到問(wèn)題后，我們就要想辦法如何去把問(wèn)題修復(fù)了，以下是問(wèn)題修復(fù)的流程：

3.2.8 如何復(fù)盤問(wèn)題

問(wèn)題發(fā)生后，我們需要從此次問(wèn)題中分析根因，并汲取教訓(xùn)和經(jīng)驗(yàn)，避免犯同樣的錯(cuò)誤。這就涉及到問(wèn)題的復(fù)盤，如何進(jìn)行問(wèn)題的復(fù)盤那，一般會(huì)經(jīng)過(guò)如下幾個(gè)步驟：回顧目標(biāo)，評(píng)價(jià)結(jié)果，分析原因，總結(jié)經(jīng)驗(yàn)。例如我們C2部門每周的opsReview會(huì)議上都會(huì)有線上問(wèn)題的復(fù)盤：coe，如何進(jìn)行coe復(fù)盤談一些自己的思考。

?參考業(yè)界的5WHY分析法剖析問(wèn)題的根因

?5WHY分析法：5代表的是問(wèn)題的深度，而不是問(wèn)題的數(shù)量

?基于問(wèn)題的答案繼續(xù)進(jìn)行提問(wèn)，5個(gè)問(wèn)題是有關(guān)聯(lián)的，層層遞進(jìn)的，找到問(wèn)題的根因

4 參考資料

??https://itrevolution.com/articles/20-years-of-google-sre-10-key-lessons-for-reliability/?

??https://learn.microsoft.com/en-us/previous-versions/msp-n-p/jj591573(v=pandp.10)?redirectedfrom=MSDN?

??https://sre.google/books/

審核編輯 黃宇