?大家好，我是樹哥。

說到系統(tǒng)穩(wěn)定性，不知道大家會想起什么？我想大多數(shù)人會覺得這個詞挺虛的，不知道系統(tǒng)穩(wěn)定性指的是什么。

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

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

何謂穩(wěn)定性？

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

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

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

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

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

我們現(xiàn)在已經(jīng)知道哪個環(huán)節(jié)可能會出什么問題，那么接下來就是針對每個環(huán)境做一些特定的動作，從而提高系統(tǒng)穩(wěn)定性了！

上線前

很多時候我們都以為系統(tǒng)穩(wěn)定只是線上運行穩(wěn)定就好了，但事實上需求研發(fā)流程是否規(guī)范，也會極大地影響到系統(tǒng)的穩(wěn)定性。

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

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

• 開發(fā)流程規(guī)范
• 發(fā)布流程規(guī)范
• 高可用設計

上線前的穩(wěn)定性建設

研發(fā)流程規(guī)范

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

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

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

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

發(fā)布流程規(guī)范

發(fā)布流程規(guī)范主要是為了控制發(fā)布權限以及頻率的問題。

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

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

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

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

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

高可用設計

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

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

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

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

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

上線時

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

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

上線時的穩(wěn)定性建設

上線后

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

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

監(jiān)控報警，指的是我們需要對應用做好運行數(shù)據(jù)的收集，監(jiān)控好系統(tǒng)的運行狀態(tài)。當系統(tǒng)狀態(tài)異常時，我們需要及時地發(fā)現(xiàn)并報警，從而讓研發(fā)人員快速地解決問題。 

一般來說，監(jiān)控報警分為系統(tǒng)級別的監(jiān)控報警和業(yè)務級別的監(jiān)控報警。系統(tǒng)級別的監(jiān)控報警包括 CPU、內存、磁盤等服務器資源的監(jiān)控，而業(yè)務級別的報警則需要根據(jù)業(yè)務情況自行定義。

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

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

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

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

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

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

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

總結

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

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

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

如何進行高可用建設？

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