?一、深入理解穩定性與高可用性

穩定性與高可用性是老生常談的兩個詞。憑借經驗和感受我們知道，提高系統的這兩項指標，系統會更加健康，產品也會有更好的用戶體驗。但是如果要給穩定性和高可用性下一個定義該如何表述？穩定性和高可用性這二者又有何區別和聯系？我認為首先要理解好這兩個問題，才能夠設定清晰的目標，系統地制定完整可行的方案。

在維基百科上搜索穩定性，定義如下：

穩定性是數學或工程上的用語，判別一系統在有界的輸入是否也產生有界的輸出。若是，稱系統為穩定；若否，則稱系統為不穩定。

再看看高可用性的：

高可用性（英語：high availability，縮寫為 HA），IT術語，指系統無中斷地執行其功能的能力，代表系統的可用性程度。是進行系統設計時的準則之一。高可用性系統與構成該系統的各個組件相比可以更長時間運行。

首先從穩定性的定義中提煉出關鍵的詞語 -- 系統、輸入、輸出。在螞蟻當下的技術架構中，可以把一個應用當做系統，應用之間的服務請求為輸入，服務響應為輸出，當服務響應符合預期時認為應用系統是穩定的。當他們相互組合形成一個更大的系統，作為業務產品對用戶表達時，用戶的請求作為輸入，產品的表達作為輸出，當產品功能正常運行時可以認為產品系統是穩定的。綜上，關于穩定性的定義我們可以總結歸納為 -- 當系統接收輸入后，能夠產生正確的、符合預期的輸出，稱系統為穩定；否則，稱系統為不穩定。

再回到命題上，為什么叫穩定性保障？能不能換一個說法叫提高穩定性？通過上文的定義我們可以總結出，穩定性描述的是系統的行為。一個系統是否穩定，就像我們評價一個人是否健康一樣，很難用陳述的方式進行完整的描述，去量化。但是卻可以通過否定的方式進行快速地判斷。人們通過良好的飲食和生活習慣來減少疾病的發生，保持身體的健康。保障系統的穩定性或者說提高系統的穩定性也是如此，我們需要通過各種方法來避免那些不穩定的情況發生。所謂的更穩定，客觀上并不存在，是主觀上希望避免或者減少不穩定的情況發生。

與穩定性不同，可用性是一個可以量化的指標，計算的公式在維基百科中是這樣描述的：

根據系統損害、無法使用的時間，以及由無法運作恢復到可運作狀況的時間，與系統總運作時間的比較。

我們經常聽到的3個9（99.9%），4個9（99.99%）度量的就是系統的可用性，高可用就是要保證系統的這個指標維持在一個高水平。在公式的定義描述中，將系統的運行時間分成了三個部分：

• 系統正常運作的時間，即系統處于穩定狀態的時間。
• 系統損害、無法使用的時間，即系統處于非穩定狀態的時間。
• 系統由無法運作恢復到可運作狀況的時間，即系統由非穩定狀態恢復到穩定狀態的時間。

系統的可用性和系統的穩定性是成正相關的。不過在現實生活中，系統是不可能永遠處于穩定狀態。逆向思考，將上述的公式進行轉換，更有利于我們進行分析：

至此，本次命題的目標，KPI就清晰了。保障系統的穩定性和高可用的目標是使系統處于穩定的工作狀態，對用戶不產生負面的影響，避免線上問題和P級故障的發生。核心kpi是系統的可用性。為了提高系統的可用性，我們應該首先保障系統的穩定性，減少非穩定狀況的發生，其次當系統由于各個組成部分發生故障，出現非穩定狀態時，能夠快速發現并將其恢復到穩定可用的狀態。

二、穩定性與高可用保障的核心思路

通過上文的推演，針對提高系統可用性這一目標，我們能夠得到兩個基本的解題思路。按圖索驥，為了解決問題，首要的任務是發現和定義問題。因此為了提高系統的穩定性，我們先列舉應用系統中常見的非穩定的情況，再一一對癥下藥：

• 功能

應用程序執行的功能出現錯誤，不符合預期。

• 容量

當系統接收的請求數量增加時，應用程序無法正常處理，出現異常或超時，導致服務失效。

• 安全

當系統接收到的沒有授權的或者惡意攻擊的請求時，應用程序出現異常甚至服務失效。

• 容錯

對于用戶錯誤的使用方式, 應用程序無法合適地處理。

當上述情況發生時，就意味著系統處于不穩定的狀態，需要我們能夠及時發現并進行處理。而造成這些問題的原因，在軟件系統中通常可以歸結為以下三類：

• 人為故障

在開發軟件的各個環節中思考不充分，或者執行時粗心導致的各類問題。

• 硬件故障

網絡不通，硬盤空間不夠，內存崩潰等。

• 軟件故障

?線程池異常，JVM異常，中間件或其他依賴的應用服務異常。

對于一個動態演進的系統而言，我們沒有辦法將故障發生的概率降為0，只能通過在軟件生產的過程中，建立流程規范和機制來盡量減少其發生。其次對于一個運行的系統，我們需要建立并完善監控和預警機制來及時發現系統中的故障，并通過執行預案使系統快速恢復。基于上述結論，為了提高系統的可用性，需要從以下三個方面入手開展工作：故障預防，故障發現和故障恢復。

?

人犯錯的幾率是遠遠大于機器的，因此故障預防最重要的是建立一套機制，在團隊內達成共識并持續按照此流程開展研發工作，從而減少個人因素（思考、執行、狀態等方面）對系統穩定性的影響。而故障發現以及故障恢復，則是需要通過系統監控和應急方案來快速發現系統異常并恢復，從而盡量減輕故障的影響面。下面以螞蟻日常的產品研發流程為例，從功能、容量、安全、容錯這4個核心要素出發，給出一套方案僅供參考。

?1、研發規范

1）設計階段

• 團隊細分文檔模板
• 高可用設計規范

2）編碼階段

① 代碼規范

• 通用代碼規范
• 工程結構規范

② 單測覆蓋率

• 單測通過率
• 代碼覆蓋率

③ 日志規范

④ 安全漏洞修復規范

3）發布階段

• 變更規范：三板斧

?2、容量保障

1）容量評估

• 機器容量
• DB容量
• 緩存容量

2）壓測摸底

3）限流方案

4）降級方案

?3、監控告警

1）日志規范

2）監控梳理

• 應用基礎監控
• 網關監控
• 服務監控
• 業務監控
• 限流監控

3）告警規范

4）數據核對

?4、應急快反

1）日常預案

• 硬件異常預案
• 中間件異常預案
• 業務異常預案

2）大促預案

3）預案執行規范

三、總結

如何做好穩定性和高可用保障是一個很龐大的命題，其中的任一小部分內容在內網都可以搜到大量的文章。寫這篇文章的目的是總結一下自己對穩定性和高可用保障工作的理解，給大家分享一套系統的框架思路。希望大家在讀后能夠更全面地了解安全生產，不陷于細節。

• 彈性計算基礎知識

彈性計算是把計算力變成普惠的公共資源，讓不同體量的用戶任何時候都能用親民的價格享受到高可用、高性能、高效率的基礎IT計算服務，所以可以說彈性是云計算的核心能力。