我們先來復習一下上一講的內容，總結下來就是，SRE? 是個體系化工程，我們通過構建SRE 這樣一套體系來保證系統穩定性，具體來說就是“提升 MTBF，降低 MTTR”。有了這樣一個激動人心的目標，你是不是想著那咱還等什么，趕快、立馬就入手建設 SRE 體系吧！

嗯，好想法，我也很想咱就直接“擼起袖子加油干”。不過今天我們要先緩一緩，在正式進入 SRE 落地細節之前，我們得先討論一下目前業界常用的“系統可用性(Availability)”這個概念，也就是我們常常聽到的“3 個 9”(99.9% 或99.95%)、“4 個 9”(99.99% 或 99.995%)。

為什么要先來討論“系統可用性”這個大家已經很熟悉的概念呢？

一方面，系統可用性和我們建設 SRE 的目標強相關，SRE 的穩定性目標其實就是盡量減少系統故障或異常運行狀態的發生，提升系統可用的運行時間占比。很明顯，這個可用時長就非常關鍵了。

另一方面，系統可用性這個概念看似簡單，但我發現真的深入進去，大家的理解其實有很多不一致的地方，比如到底怎樣才算是可用時長，怎樣算是不可用時長呢？這個標準是怎么定義的？除了從時間維度來衡量可用性，還有其它的衡量方式嗎？“3 個 9”、“4 個 9”聽起來都很好，那具體來說我們的系統要達到“幾個 9”才算是穩定的呢？

所以，今天我們先慢下來，花時間把上面這些問題都徹底搞清楚，達成共識，打好基礎，咱后面的 SRE 學習才能事半功倍。

衡量系統可用性的 2 種方式

那我就直接給答案了，目前業界有兩種衡量系統可用性的方式，一個是時間維度，一個是請求維度，我們先來看這兩個維度的計算公式。

• 時間維度 ：Availability = Uptime / (Uptime + Downtime)
• 請求維度：Availability = Successful request / Total request

這兩個公式很簡單，我們得深入進去，一一來看。

我們先來看時間維度的系統可用性。用一句話來概括：時長維度，是從故障角度出發對系統穩定性進行評估。

這類計算方式我們最常見，畢竟你的系統在一段時間里不出現故障，就說明它很穩定嘛！不過，在真實的使用場景中，怎么樣才算是可用時長，什么情況下又是不可用時長，這個是怎么定義的呢？

細想一下這個問題，你會發現還真有點復雜，那我就舉個發燒生病的例子來說明一下。

我們知道，一個人如果發燒了，體溫一般會超過 37.5 度，那如果這個人的體溫正好達到這個溫度，是不是代表他一定是生病了呢？依據生活經驗，我們知道不一定。為什么呢？因為我們判斷一個人是否發燒生病，不是只看這一次、一時的體溫，還要看他體溫是不是持續超過 37.5 度。

所以，這里就涉及到一個測量方法和判定方法的問題，包含三個要素：一個是衡量指標，比如體溫就是衡量指標；第二個是衡量目標，達到什么目標是正常，達不到就是異常，低于37.5 度算正常，超過 37.5 度就是異常，但是單次測量不能說明問題，我們可以多次測量， 比如 6 次中有至少 4 次低于 37.5 度才算正常，轉化成比例的話就是 67%；第三個是影響時長，比如持續超過 12 小時。

對應到系統上，我們也會用一系列的標準和判定邏輯來說明系統是否正常。比如，系統請求狀態碼為非 5xx 的比例，也就是請求成功率低于 95%，已經連續超過 10 分鐘，這時就要算作故障，那么 10 分鐘就要納入 Downtime(宕機時間)，如果達不到這個標準，就不算作故障，只是算作一般或偶然的異常問題。

這里同樣有三個要素：衡量指標，系統請求狀態碼；衡量目標，非 5xx 占比，也就是成功率達到 95%；影響時長，持續 10 分鐘。

因此，只有當問題達到一定影響程度才會算作故障，這時才會計算不可用時長，也就是上面公式中的 Downtime。同時，我們還要求一個周期內，允許的 Downtime，或者說是系統的“生病時間”是有限的，用這個有限時間來約束系統穩定性。

下面是我們常見的按時長維度統計的可用性對照表，也就是我們前面提到的幾個 9：

講到這里，針對時長維度的穩定性計算方式就比較清楚了，但是從這種計算方式中，你有沒有看出一些問題呢？

我想你肯定看出來了，這里最顯著的問題就是，穩定性只與故障發生掛鉤。

我們來想一想，這樣做會帶來哪些問題？比如有一個系統，因為網絡抖動，有短暫的幾秒、十幾秒，或者幾分鐘異常，但是后來系統自己恢復了，業務并沒有中斷，這時我們按照時長維度來判斷，這肯定不會算作系統故障。但是如果這種短暫的影響頻度非常高，一天來個5、6? 次，持續一兩周，我們應該可以判定系統運行狀況也是不正常的，可能不是故障，但肯定是不穩定了。

所以這種用時長維度來衡量系統穩定性的方式，其主要缺點就是粒度不夠精細。這些小的異常問題和它們的影響，如果從更長的周期來看，也是有一定參考價值的。那怎樣才能衡量得更精細些呢？

這就需要第二種衡量方式了，也就是從請求維度來衡量系統可用性。

用一句話來說，請求維度，是從成功請求占比的角度出發，對系統的穩定性進行評估。

假定我們的系統一天內有 100,000 次請求，我們期望的成功率至少是 95%，如果有 5001次請求失敗了，也就是成功率低于 95% 了，我們就認為系統運行狀態是不正常的。

請求維度的系統可用性同樣包含三個關鍵要素，第一個衡量指標，請求成功率；第二個衡量目標，成功率達到 95% 才算系統運行正常；第三個是統計周期，比如一天、一周、一個月等等，我們是在一個統計周期內計算整體狀況，而不是看單次的。

你看，這種方式對系統運行狀況是否穩定監管得更為嚴格，不會漏掉任何一次問題的影響， 因為它對系統整體運行的穩定性判定，不僅僅會通過單次的異常影響進行評估，還會累計疊加進行周期性的評估。

到這里，我們就總結出一條至關重要的經驗了：故障一定意味著不穩定，但是不穩定，并不意味著一定有故障發生。

到這里，我們掌握了衡量系統可用性的兩個維度、兩種算法，它們都包含三個關鍵要素：衡量指標、衡量目標、影響時長 / 統計周期。這兩種算法最后都會落腳到“幾個 9”上，那系統到底定“幾個 9”才算是穩定的呢？接下來，我們就來回答這個問題。

設定系統穩定性目標要考慮的 3 個因素

這個問題其實并沒有標準答案，從我的經驗來看，到底定“幾個 9”主要取決于以下三個因素。

第一個，成本因素

從理論上來說，肯定是? 9? 越多穩定性越好，但是相應付出的成本和代價也會更高。比如為了更高的可用性，要有更多的冗余資源投入，甚至要做主備、雙活甚至是多活。如果一家公司的業務量和影響力都發展到一定程度，那這個成本不管多高都是必須要付出的。但是，肯定不是所有的公司都需要付出這么高的成本，而是要先考慮?? ROI(回報率)。這時候就要看企業自身對成本壓力的承擔情況了。

第二個，業務容忍度

穩定性怎么設定，很大程度上還要取決于業務上的容忍度。對于核心業務或核心應用，比如電商的交易和支付系統，我們當然是希望成功率越高越好，一般對系統穩定性要求是“3 個9”或“4 個 9”。因為這些系統一旦出問題，就會直接影響整個網站和公司的收益，這些都是錢，所以對穩定性要求必然就會提高。

但是，對于非核心業務或應用，比如商品評論，商品評分等，或許“2 個 9”也能容忍。因為短時間的評論看不到，并不會對業務收入和用戶體驗造成太大的影響。

第三個，系統當前的穩定性狀況

結合系統的實際情況，定一個合理的標準比定一個更高的標準會更重要。這個合理的值應該怎么來定呢？

我個人的建議是從系統現狀入手，比如，如果系統可用性是低于 99% 的，那首先第一步是不是可以做到? 99%，然后再爭取做到? 99.5%，再到? 99.9%，一步一步朝著更高的標準邁進。同時，這樣做也會更容易落地，因為你如果定一個太高的目標，又始終達不成，反而會打擊到團隊的自信心和積極性。

結合上面這三個因素，對于到底應該定“幾個 9”這個問題，你應該有了一個更清晰的認識了。

總結

好了，到這里，今天我們要討論的系統可用性就講完了。關于系統可用性，業界有兩種計算方式，一種是時長維度，另一種是請求維度，這兩種方式各有優劣。在 SRE 的實踐中，應該選擇哪一個呢？很明顯，SRE 會更多采用請求維度的統計方式，因為 SRE 關注的穩定性是系統的整體運行狀態，而不僅僅只關注故障狀態下的穩定性，在系統運行過程中的任何異常，都會被納入穩定性的評估范疇中。

這個知識點要拿一整節課來講，是因為接下來我們就要討論 SRE 的穩定性指標和目標了， 理解了今天的內容，你才能更好地理解 SRE 體系中的指標(SLI)和目標(SLO)。今天我先把 SLI 和 SLO 這兩個概念拋出來，如果你覺得有點陌生，沒有關系，準備好下節課和我一起掌握它們。

思考題

對于系統可用性的描述，今天我們僅用了“狀態碼”這一個指標來示例，但是在實際情況下，我們還會有其它多個指標來同時標識一個系統的穩定性，你能想到還有哪些指標？歡迎你在留言區寫下自己的思考。

考慮這些指標的時候，不妨想想你是怎么選擇的，你的判斷標準是什么？這些也將是我們下節課程的重點內容。

如果今天的內容對你有幫助，也歡迎你分享給身邊的朋友，和他一起精進。

從業務部門的視角來看，狀態碼是多少他們是不關心的，他們關心的是業務是否真正的可用。比如，極端一點，狀態碼正常，但返回的內容不是預期的。另外，如果業務不是需要7*24的，可用性指標應該是僅限定在業務開展期間。有點扯遠了…… 作者回復: 很好的問題。從兩個方面來看：1、返回的業務內容不是預期的，這一點應該更多的是要QA來解決，這個本質是是功能問題，其實SRE是不需要關注這樣的異常的。2、如果可以做到內容不同，返回碼不同，也可以做到穩定性的監控。比如對于一個用戶登錄應用，如果登錄成功是200ok，驗證碼錯誤是1001，密碼錯誤是1002，如果總是提示驗證碼錯誤，這種也是可以納入到穩定性的監控指標中的。關于第二個問題，7*24小時值守，這個看業務特點，比如對于證券類的應用，每天就是幾個固定時段，所以沒必要7*24小時。 從業務部門的視角來看， “標識系統穩定性指標” 我將這里的系統理解為一個服務，例如order這個服務，用于標識它穩定行指標有如下基礎設施層：物理設備，操作系統應用層：全鏈路監控針對服務功能埋點監控服務層：服務提供的rpc，http服務的表現用戶層：APM將從外部因素(用戶視角)檢測業務功能，收集各個區域/設備對業務的穩定性的表現說到這里，我又感覺有點像立體化監控似的。選擇這些指標的判斷標準是： 為什么我不能只關注http的狀態呢？ 舉個我自己例子，公司order.xx.com出現了問題，5xx超過2000次，這樣的告警其實只是將故障的表象層告出來，業務不可用，一定會有5xx，但哪里引起的5xx？哪些告警是故障的表象層，哪些是故障點的告警，一時間難以區分，如果有一個自上而下的匯聚指標供我查看，我也許就能及時的定位到原因。在上面幾個層級的指標中，經常是相互作用的，例如基礎設施層宕機，會引起上面多個層級指標波動；用戶層的流量激增又會帶來下層的指標波動；APM中的外部因素——區域網絡波動又會引起內部服務層指標499波動等。所以我個人覺得穩定性講的是一整條請求鏈(從用戶設備到IDC)的事，要解決穩定性就必須清楚的看到整個鏈路的情況，所以“標識系統穩定性指標”我選擇這樣幾個層級。這是我的觀點，希望老師指正。 作者回復: 感謝你的非常詳細地分析，你這里其實是針對我們可用性的內容又向下深入了一層，已經深入到了定位系統不問題的根因是什么。關注系統可用性，我們通過幾個關鍵指標就可以，但是深入定位根因，就像你說的，我們需要更加立體化的監控，甚至是AIOps的手段。非常棒的分享。 “標識系統穩定性指標” 可用性指標，我覺得還需要區分下 1. 業務可用性，可以稱之為“源站””，這里的統計指標最好給業務提供最大的靈活性，授權rd自身配置uei，請求方法，以及正常狀態碼。這里需要注意一個問題，有時候301/302/499也是錯誤碼(比如為了友好提示5xx內部跳轉，觸發請求限流503)，所以最好將body自定義內容作為判斷指標。 2. 網絡(用戶)可用性。源站可用，不意味著用戶也可用。可以通過監控班類的APM統計可用行指標和響應延遲(比如大于5s以上且5個節點，某某運營商線路丟包或者抖動等等) 作者回復: 感謝你提供了用戶可用性這個維度，從SRE角度，離用戶越近的指標，越有價值。 可用性指標 請教一下，老師怎么看AIOPS，AIOPS對線上的業務來說，真的有(真實的)價值嗎？ 作者回復: 要清楚，AIOps對業務本身是沒有價值的，它是為運維服務的，所以它的價值更多的體現在運維層面。體現在運維層面的哪里呢？就是問題發生前的預判、以及根因分析這些，因為在大規模分布式系統下，沒有這個手段就沒法處理問題。但是AI要有兩個要素，一個是算法，一個是數據，算法是靠數據訓練的，這里算法不是問題，但是數據量是不是足夠大就是問題，所以一定要業務體量足夠大，資源規模足夠大，產生的日志信息足夠豐富，這時AIOps才有意義，如果只有幾十幾百臺服務器的規模，業務體量也沒有那么大的情況下，AIOps的作用是不大的。 請教一下，老師怎么看AIOPS 一般情況，是根據不可用時長來定義故障，還是根據故障的定義來計算不可用時長呢？ 比如，你這里舉得例子，就是先定義好什么是故障，比如持續10min。然后再看有沒有超過10min，如果超過了，就算是一個故障，然后計算出實際的不可用時長。如果沒有超過10min，就不算是故障，相應的，也就不計算不可用時長。--所以，這種不可用時長的計算方式才在某些情況下體現不出穩定性？而且我發現，很多公司都很難明確定義一個故障？比如，怎么樣的表現就算是一個故障？ 作者回復: 所以，怎么樣才算一個故障，這個是根本問題。不可用時長的計算也是基于對故障的定義來計算的。 一般情況，是根據不可用時長來定義故障，還是根據故障的定義來計算不可用時長呢？

總結

以上是生活随笔為你收集整理的02 | 系统可用性：没有故障，系统就一定是稳定的吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。