[[414693]]

本文轉(zhuǎn)載自微信公眾號(hào)「董澤潤的技術(shù)筆記」，作者董澤潤 。轉(zhuǎn)載本文請(qǐng)聯(lián)系董澤潤的技術(shù)筆記公眾號(hào)。

換換口味今天不寫純技術(shù)文章，分享一個(gè) high level 的話題。假如公司或部門的微服務(wù)頻繁出現(xiàn)故障，Boss 讓你去負(fù)責(zé)穩(wěn)定性建設(shè)，俗稱救火隊(duì)長，你會(huì)怎么做???

這個(gè)問題可以當(dāng)做面試題，考驗(yàn)候選者是否有全局的視野，以及對(duì)整個(gè)技術(shù)棧的掌握情況。同時(shí)需要多維度思考，產(chǎn)品，工程師，服務(wù)，基礎(chǔ)機(jī)構(gòu)等等。

整體來講和上圖的滅火原理是一樣，滅明火、定期檢查設(shè)備、防火演練。穩(wěn)定性建設(shè)也分為三步：短期故障處理、中期構(gòu)建穩(wěn)定性、長期演練壓測。

短期故障處理

1.滅明火

火燒眉毛了，正在發(fā)生的問題要及時(shí)處理，至少要先 mitigate 減輕影響面。不能影響核心的訂單創(chuàng)建流程，稍慢一點(diǎn)都沒關(guān)系，能降級(jí)的優(yōu)先降級(jí)，保證核心鏈路

如果是因?yàn)樯暇€導(dǎo)致的故障，要及時(shí)回滾，在線找原因不可取。

2.功能凍結(jié)

由于這是特殊時(shí)期，從產(chǎn)品角度考慮：凍結(jié) freeze 一切開發(fā)功能上線，除了 bug fix 以及非常重要的變更，需要 boss 審批。同時(shí)每次上線至少征得 leader 及穩(wěn)定性負(fù)責(zé)人的審批

3.它山之石

復(fù)盤所有短期內(nèi)的故障，我們叫做 postmortem 驗(yàn)尸報(bào)告。把故障發(fā)生的原因，處理過程，后續(xù) Todo Actions 全部總結(jié)分析一遍，并且跟蹤后續(xù)的落實(shí)情況

最重要的是推廣到其它服務(wù)，比如基本上每個(gè)公司都出過域名過期、沒有限流接口被打爆，真的非?？鋸?/p>

4.服務(wù)

對(duì)于服務(wù)來講，短期需要檢查所有內(nèi)容：

• 設(shè)置合理的超時(shí)時(shí)間，比如好多用 python requests 庫不設(shè)超時(shí)
• 每個(gè)接口設(shè)置合理的限流，保護(hù)自己
• 調(diào)用第三方設(shè)置熔斷 circuit breaker, 保護(hù)別人
• 檢查重試邏輯，你要做的是重試，不是 flood 下游
• 增加報(bào)警，很多時(shí)候有報(bào)警就能提前發(fā)現(xiàn)問題

毫不夸張的說，做到以上步驟，能杜絕 90% 的故障。尤其是 ratelimiter/circuit breaker, 就能很好的避免大部份的級(jí)聯(lián)故障

中期構(gòu)建穩(wěn)定性

中期能做的事情情非常多，由于不緊急，需要慢慢來最考驗(yàn)細(xì)節(jié)

1.產(chǎn)品優(yōu)化

這一點(diǎn)是很多 enginner 不具備的素質(zhì)，需要產(chǎn)品經(jīng)理一起來梳理業(yè)務(wù)流程。很多時(shí)候，一個(gè)業(yè)務(wù)形態(tài)上的優(yōu)化，遠(yuǎn)遠(yuǎn)超過工程師做的很多努力，而恰恰這個(gè)產(chǎn)品功能可能是最臟的

廣義來看，我們又是自己服務(wù)的產(chǎn)品經(jīng)理。比如原來雙寫的邏輯，是否可以用第三方同步工具來完成?這樣就能做到服務(wù)的 clean

2.服務(wù)架構(gòu)優(yōu)化

隨著功能的不斷迭代，原有的架構(gòu)設(shè)計(jì)己經(jīng)不再適用。簡單的說，服務(wù)于 10w 訂單的架構(gòu)，再怎么加機(jī)器，也無法適用 1000w 訂單的場景，有幸接觸了走過這一步的滴滴分單架構(gòu)

對(duì)于具體服務(wù)能做的非常多:

• 比如 ut 覆蓋率要到一定指標(biāo)，就算有全鏈路壓測，也不代表代碼所有邏輯分支都是正確的。
• 另外一個(gè)重要的就是服務(wù)要?jiǎng)澐值燃?jí)，比如 p0, p1, p2 等等，當(dāng)出故障時(shí)要優(yōu)先保證 critical 服務(wù)的 QOS，舍棄低等級(jí)服務(wù)
• 服務(wù)也要做好 fallback 邏輯，比如 eta 請(qǐng)求地圖服務(wù)，假如地圖服務(wù)不可用，那么要用路面距離做 fallback 等等
• 可觀察測性 observerbility，dashboard 是否足夠，metrics 指標(biāo)是否全面
• 排查隱患，墨菲定律無處不在，你能想像到會(huì)出故障的點(diǎn)，比如 SPOF, 只要時(shí)間足夠長，一定會(huì)爆

3.上線流程

這里涉及到公司的 CI/CD, 工具是否好用，健壯，穩(wěn)定。上線要有 canary 灰度，全量上線也要有分組，給工程師留足夠的觀察期，而不是一把梭哈。同時(shí)定期使用 rollback, 確?；貪L功能可用(都是淚，別問我為什么)

可以想像下，一個(gè)服務(wù)有 100 臺(tái)機(jī)器，灰度沒問題，就代表真的沒問題嘛?不可能的，所以全量上線也要分組，把控制權(quán)交給工程師

對(duì)于 enginner 來講，要培養(yǎng)風(fēng)險(xiǎn)意識(shí)，上線要觀察日志，查看 dashboard. 要全面觀察服務(wù)的健康狀態(tài)，cpu, latency 正常服務(wù)沒問題了嘛?肯定不是的，同時(shí)要注意新功能是否會(huì) flood 下游服務(wù)，做好評(píng)估

4.技術(shù)評(píng)審

很多公司都有技術(shù)委員會(huì)，別的不說，至少 58 有的。公司級(jí)別的一般負(fù)責(zé)晉升多一些，所以需要每個(gè)部門也有同樣的人員

最重要的就是評(píng)審方案，是否設(shè)計(jì)的不夠，過度設(shè)計(jì)，選型太過于激進(jìn)。舉個(gè)例子，100年前，mongodb 剛出的時(shí)候，公司就用 mongodb 替換掉了 mysql, 那時(shí)的 mongodb db 級(jí)別鎖，沒有事務(wù)...

長期演練壓測

關(guān)于長期要做的工作也非常多，由于涉及所有開發(fā)部門，基礎(chǔ)架構(gòu)，以及運(yùn)維團(tuán)隊(duì)，所以需要專職 team 長期負(fù)責(zé)，定期復(fù)盤總結(jié)

1.全鏈路壓測

目前來看 alibaba 是做的最好的，我接觸過最多的是在滴滴，涉及的細(xì)節(jié)特別多。通過壓測能提前發(fā)現(xiàn)很多業(yè)務(wù)的瓶頸

壓測工具的開發(fā)也是個(gè)大工程，我記得當(dāng)時(shí)說要演練每次工具都出故障，大家干等幾小時(shí)

滴滴以前的做法，是在太平洋小島 mock 假的打車需求，各個(gè)服務(wù)都需要做相應(yīng)的改造，包括 mysql 要?jiǎng)?chuàng)建影子表 shadow table, 服務(wù)針對(duì)壓測請(qǐng)求要做區(qū)分等等

前幾天曹大分享了文章，為什么有的公司不寫 UT 線上也比較穩(wěn)定，一個(gè)原因就在于入口處有全鏈路壓測

2.冒煙 chaos

冒煙測試，混沌測試目的就是在線上搞破壞，找到彈性不好的服務(wù)及模塊。比如磁盤 IO 不穩(wěn)定，機(jī)器突然宕機(jī)，時(shí)間突然回卷等等

之前 pingcap 分享過 chaos 注入結(jié)束后，服務(wù) QPS 沒有回到正常水平的問題。感興趣的可以去看看

3.服務(wù) runbook 定期演練

這一點(diǎn)我體會(huì)非常深，就像消防員定期檢查裝備，然后測試滅火一樣。服務(wù)要針對(duì)特定的問題，定制好 runbook, 畢竟維護(hù)服務(wù)的工程師是流動(dòng)的，今天是 owner, 明天就移交給 tom 了

[[414694]]

我們的服務(wù)依賴 etcd, 大家也知道機(jī)器掛掉概率雖然低，但是預(yù)期之中的。所以我們編寫了 runbook, 滾動(dòng)升級(jí) etcd, 移除添加故障節(jié)點(diǎn)等等，非常好用，新手按照流程走就可以

4.人員素質(zhì)

長期建設(shè)里最重要的就是人員素質(zhì)建設(shè)，有的人上線完成后，不看日志，不檢查 grafana, 我們不是 blame 這個(gè)人，可能工程 sense 就是差了一點(diǎn)

人員素質(zhì)建設(shè)，方方面面太多的，軟素質(zhì)硬素質(zhì)。最直觀的就是代碼能力，防御編程應(yīng)該深入每個(gè) enginner 的骨髓

5.Infra建設(shè)

跳出 engineer 的視野，從公司的角度來看，一個(gè) idc 或是云廠商是不夠的。國內(nèi)提的最多的是兩地三中心, 多活設(shè)計(jì)。其實(shí)這個(gè)很難，大部份公司的都是假多活，主機(jī)房掛了全部完蛋

但是水災(zāi)，火災(zāi)這個(gè)事誰能保證就不發(fā)生呢?至少數(shù)據(jù)要做到多地備份，服務(wù)可以掛，數(shù)據(jù)沒了公司一定會(huì)倒閉。當(dāng)年天津港的事印象特別深，微信 IDC 的負(fù)責(zé)人做的非常漂亮，這事不能多說，感興趣的可以去搜

小結(jié) 

穩(wěn)定性建設(shè)話題非常大，需要視野看得遠(yuǎn)一些，但也不能太虛，要有可執(zhí)行性，每一步都要細(xì)化到文檔，總結(jié)成流程與制度。