?大家好，我是樹哥。

說到系統穩定性，不知道大家會想起什么？我想大多數人會覺得這個詞挺虛的，不知道系統穩定性指的是什么。

一年前的我看到這個詞，也是類似于這樣的感受，大概只知道要消除單點、做好監控報警，但卻并沒有一個體系化的方法論。

經過一段時間的摸索，我對系統穩定性有了較為體系化的認識，于是迫不及待地希望和大家一起分享。所以今天，就讓我跟大家簡單聊聊系統穩定性建設這個話題吧！

何謂穩定性？

系統穩定性，從字面上來看，就是讓系統盡可能穩定，不要出問題。 但業務是變化的，系統肯定也是一直變化的，有可能新加了個功能就把系統搞掛了，也有可能突然業務流量暴增把系統搞掛了。所以，要保障系統穩定性可謂非常之難。但即使再難，也還是得去做，但到底怎么做呢？

我們要保障系統穩定性，那就需要知道哪些因素可能會造成系統不穩定。我自己來了一個頭腦風暴，把所有可能造成系統不穩定的因素整理一下，下面是我梳理的會造成系統不穩定的部分因素：

• 未測試需求直接上線
• 上線的需求產品不知道
• 上線的新需求有 bug
• 頻繁發布需求
• 發布緊急需求
• 上線后沒有線上驗證
• 系統設計方案存在缺陷
• 系統代碼實現存在缺陷
• 漏測了某個功能
• 上線時操作失誤
• 下游服務掛了
• 網絡中斷導致調用失敗
• 上游調用流量突增，沖垮服務
• 應用服務器內存溢出 OOM
• 應用服務器 CPU 100%
• 數據庫主從延遲了
• 數據庫主庫掛了
• Kafka 消息擠壓了
• Redis 響應緩慢
• 第三方服務商掛了
• 潛在的黑客攻擊
• 潛在的系統漏洞

是不是感覺特別多，看起來有點暈了？別怕，其實我們可以將所有的不穩定因素根據時間維度，將其分為三大類：上線前、上線時、上線后。

• 上線前的不穩定因素。這塊指的是需求上線前的所有內容，包括需求評審、技術方案設計、代碼編寫、功能測試等等。
• 上線時的不穩定因素。這塊指的是上線時可能的不穩定因素，包括操作失誤、某個功能有問題導致線上出問題等等。
• 上線后的不穩定因素。這塊指的是需求上線后，有可能出現的各種各樣的問題，例如中間件掛了、網絡掛了等等。

我們現在已經知道哪個環節可能會出什么問題，那么接下來就是針對每個環境做一些特定的動作，從而提高系統穩定性了！

上線前

很多時候我們都以為系統穩定只是線上運行穩定就好了，但事實上需求研發流程是否規范，也會極大地影響到系統的穩定性。

試想一下，如果誰都可以隨便提需求、做的功能沒有做方案設計、誰都可以直接操作線上服務器，那么這樣的系統服務能夠穩定得了嗎？所以說，需求上線前的過程也是影響系統穩定性的重大因素。

在我看來，在上線前這個階段，主要有三大塊非常重要的穩定性建設內容，分別是：

• 開發流程規范
• 發布流程規范
• 高可用設計

上線前的穩定性建設

研發流程規范

研發流程規范，指的是一個需求從提出到完成的整個過程應該是怎樣流轉的。一般的需求研發流程包括：產品提出需求、技術預研、需求評審、技術方案設計、測試用例評審、技術方案評審、測試用例評審、需求開發、CodeReview、需求測試。不同公司根據情況會有所調整，但大差不差。

在這個流程中，與研發相關的幾個比較重要的節點是：技術方案設計及評審、測試用例評審及評審、需求開發、代碼測試覆蓋率、CodeReview。 我們上面提到的幾個影響穩定性的因素，就是因為沒有做好這幾個節點的工作導致的，包括：

• 未測試需求直接上線
• 上線的需求產品不知道
• 上線的新需求有 bug
• 上線后沒有線上驗證
• 系統設計方案存在缺陷
• 系統代碼實現存在缺陷

如果能夠處理好上述幾個節點，那么就能夠極大地降低研發流程導致的問題。這里每個節點都有很深的學問，這里就不展開講了，我們主要說個思路。

發布流程規范

發布流程規范主要是為了控制發布權限以及頻率的問題。

在項目初始，為了快速響應業務，一般權限控制都很松，很多人都可以進行線上服務的發布。但隨著業務越來越多、流量越來越大，相對應的故障也越來越多，到了某個時候就需要對權限做管控，并且需要對需求的發布頻率做控制。

對于需求發布流程來說，一般有幾種發布方式，分別是：Release Train 方式、零散發布方式。 Release Train 意思是固定時間窗口發布，例如每周四發布一次。如果無法趕上這次發布時間，那么就需要等到下次發布窗口。

零散發布方式，指的是有需要就發布，不做發布時間控制。但這種方式一般只在項目初期發揮作用，后期一般都會收緊。

除此之外，發布流程中都會設有緊急發布流程，即如果某個需求特別重要，或者有緊急漏洞需要修復，那么可以通過該流程來緊急修復，從而避免因未到時間窗口而對業務產生影響。

但一般來說，緊急發布流程都比較麻煩，除非迫不得已不然不要審批通過，不然 Release Train 方式可能會退化成零散發布方式。

高可用設計

高可用設計指的是為了讓系統在各種異常情況下都能正常工作，從而使得系統更加穩定。 其實這塊應該是屬于研發流程規范中的技術方案設計的，但研發流程規范更加注重于規范，高可用設計更加注重高可用。

另外，也由于高可用設計是非常重要，因此獨立拿出來作為一塊來說說。對于高可用設計來說，一般可分為兩大塊，分別是：服務治理和容災設計。

服務治理就包括了限流、降級、熔斷、兜底、隔離等，這一些考慮點都是為了讓系統在某些特殊情況下，都能穩定工作。 例如限流是為了在上游請求量太大的時候，系統不至于被巨大的流量擊垮，還可以正常提供服務。

容災設計應該說是更加高端點的設計了，指的是當下游系、第三方、中間件掛了，如何保證系統還能正常運行？ 可以說容災設計比起服務治理，其面臨的情況更加糟糕。

例如支付系統最終是通過 A 服務商進行支付的，如果 A 服務商突然掛了，那我們的支付系統是不是就掛了？那有什么辦法可以在這種情況（災難）發生的時候，讓我們的系統還能夠正常提供服務呢？這就是容災設計需要做的事情了。

上線時

上線時這個階段，主要是確保功能按照原先設計的方案進行部署，這個階段主要是確保規范操作，避免失誤，因此可以制定相關的 CheckList 以及變更審批。

其次，為了避免還可能存在未發現的功能缺陷，有時候還可以使用灰度發布降低風險。在這個階段能做的一些穩定性建設如下圖所示。

上線時的穩定性建設

上線后

當系統成功上線后，很多小伙伴以為工作就結束了，但實際上我們還有不少工作可以做。根據我的經驗，在上線后我們能做的穩定性建設包括：

• 監控報警
• 故障管理
• 緊急處理預案
• 容災演練
• 案例學習
• 全鏈路壓測

監控報警，指的是我們需要對應用做好運行數據的收集，監控好系統的運行狀態。當系統狀態異常時，我們需要及時地發現并報警，從而讓研發人員快速地解決問題。 

一般來說，監控報警分為系統級別的監控報警和業務級別的監控報警。系統級別的監控報警包括 CPU、內存、磁盤等服務器資源的監控，而業務級別的報警則需要根據業務情況自行定義。

故障管理，就是當發生故障時，我們需要遵循的整套處理規范。 團隊小的時候可能無所謂，但是當團隊大了的時候，我們就需要統一大家的故障處理流程，從而可以更快速地解決故障。此外，在故障解決完成之后還需要進行復盤，產出對應的故障報告。

Case Study 機制指的是定期學習其他團隊的高可用或者線上故障進行學習，從而提高團隊的系統設計能力，避免踩坑。

容災演練，其實就是模擬某些中間件或者服務故障，然后看看系統是否能按照之前設計的高可用方案實施。 

容災演練是提升系統穩定性的一把利器，很多時候即使我們設計得很完美，但實際上卻沒發揮作用，究其根本就是沒有實踐過。是驢是馬，得拉出來溜溜才知道。

緊急處理預案，簡單就是要想到各種可能發現的情況，然后做好預案。 之后結合容災演練不斷進行優化，從而形成一套很好的處理預案。這樣當線上發生類似故障時，就可以輕松應對了。

全鏈路壓測，指的是對整個鏈路進行壓測。 不同公司可能會采用不同的方案，有些會直接在線上進行壓測，然后用流量標記的方式識別測試流量。

有些則是進行流量錄制，之后重新搭建一套與線上非常類似的系統進行壓測。一般來說，第一種效果肯定會更好，成本也更低，但是對研發人員要求也更高，風險也更大。

總結

今天我們簡單地從上線前、上線時、上線后去探討了如何做穩定性建設，其中每一塊都可以展開來講很多內容。

例如監控報警這塊，那我們應該監控系統的哪些指標？其實這些都是有一些成熟的方案了，例如要監控 TP90、響應延遲、調用延時、消息處理延時等。

但出于篇幅原因，我們今天只是蜻蜓點水，點到為止，后續繼續再慢慢不斷完善，純當拋磚引玉吧。如果大家感興趣的話，可以關注下樹哥，后面我再慢慢一點點寫。最后，丟一個思維導圖，作為今天文章的結尾。

如何進行高可用建設？

好了，這就是今天分享的全部內容了。