[[414693]]

本文轉載自微信公眾號「董澤潤的技術筆記」，作者董澤潤 。轉載本文請聯系董澤潤的技術筆記公眾號。

換換口味今天不寫純技術文章，分享一個 high level 的話題。假如公司或部門的微服務頻繁出現故障，Boss 讓你去負責穩定性建設，俗稱救火隊長，你會怎么做???

這個問題可以當做面試題，考驗候選者是否有全局的視野，以及對整個技術棧的掌握情況。同時需要多維度思考，產品，工程師，服務，基礎機構等等。

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

短期故障處理

1.滅明火

火燒眉毛了，正在發生的問題要及時處理，至少要先 mitigate 減輕影響面。不能影響核心的訂單創建流程，稍慢一點都沒關系，能降級的優先降級，保證核心鏈路

如果是因為上線導致的故障，要及時回滾，在線找原因不可取。

2.功能凍結

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

3.它山之石

復盤所有短期內的故障，我們叫做 postmortem 驗尸報告。把故障發生的原因，處理過程，后續 Todo Actions 全部總結分析一遍，并且跟蹤后續的落實情況

最重要的是推廣到其它服務，比如基本上每個公司都出過域名過期、沒有限流接口被打爆，真的非常夸張

4.服務

對于服務來講，短期需要檢查所有內容：

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

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

中期構建穩定性

中期能做的事情情非常多，由于不緊急，需要慢慢來最考驗細節

1.產品優化

這一點是很多 enginner 不具備的素質，需要產品經理一起來梳理業務流程。很多時候，一個業務形態上的優化，遠遠超過工程師做的很多努力，而恰恰這個產品功能可能是最臟的

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

2.服務架構優化

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

對于具體服務能做的非常多:

• 比如 ut 覆蓋率要到一定指標，就算有全鏈路壓測，也不代表代碼所有邏輯分支都是正確的。
• 另外一個重要的就是服務要劃分等級，比如 p0, p1, p2 等等，當出故障時要優先保證 critical 服務的 QOS，舍棄低等級服務
• 服務也要做好 fallback 邏輯，比如 eta 請求地圖服務，假如地圖服務不可用，那么要用路面距離做 fallback 等等
• 可觀察測性 observerbility，dashboard 是否足夠，metrics 指標是否全面
• 排查隱患，墨菲定律無處不在，你能想像到會出故障的點，比如 SPOF, 只要時間足夠長，一定會爆

3.上線流程

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

可以想像下，一個服務有 100 臺機器，灰度沒問題，就代表真的沒問題嘛?不可能的，所以全量上線也要分組，把控制權交給工程師

對于 enginner 來講，要培養風險意識，上線要觀察日志，查看 dashboard. 要全面觀察服務的健康狀態，cpu, latency 正常服務沒問題了嘛?肯定不是的，同時要注意新功能是否會 flood 下游服務，做好評估

4.技術評審

很多公司都有技術委員會，別的不說，至少 58 有的。公司級別的一般負責晉升多一些，所以需要每個部門也有同樣的人員

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

長期演練壓測

關于長期要做的工作也非常多，由于涉及所有開發部門，基礎架構，以及運維團隊，所以需要專職 team 長期負責，定期復盤總結

1.全鏈路壓測

目前來看 alibaba 是做的最好的，我接觸過最多的是在滴滴，涉及的細節特別多。通過壓測能提前發現很多業務的瓶頸

壓測工具的開發也是個大工程，我記得當時說要演練每次工具都出故障，大家干等幾小時

滴滴以前的做法，是在太平洋小島 mock 假的打車需求，各個服務都需要做相應的改造，包括 mysql 要創建影子表 shadow table, 服務針對壓測請求要做區分等等

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

2.冒煙 chaos

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

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

3.服務 runbook 定期演練

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

[[414694]]

我們的服務依賴 etcd, 大家也知道機器掛掉概率雖然低，但是預期之中的。所以我們編寫了 runbook, 滾動升級 etcd, 移除添加故障節點等等，非常好用，新手按照流程走就可以

4.人員素質

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

人員素質建設，方方面面太多的，軟素質硬素質。最直觀的就是代碼能力，防御編程應該深入每個 enginner 的骨髓

5.Infra建設

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

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

小結 

穩定性建設話題非常大，需要視野看得遠一些，但也不能太虛，要有可執行性，每一步都要細化到文檔，總結成流程與制度。