我們先來復(fù)習(xí)一下上一講的內(nèi)容，總結(jié)下來就是，SRE? 是個體系化工程，我們通過構(gòu)建SRE 這樣一套體系來保證系統(tǒng)穩(wěn)定性，具體來說就是“提升 MTBF，降低 MTTR”。有了這樣一個激動人心的目標(biāo)，你是不是想著那咱還等什么，趕快、立馬就入手建設(shè) SRE 體系吧！

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

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

一方面，系統(tǒng)可用性和我們建設(shè) SRE 的目標(biāo)強(qiáng)相關(guān)，SRE 的穩(wěn)定性目標(biāo)其實(shí)就是盡量減少系統(tǒng)故障或異常運(yùn)行狀態(tài)的發(fā)生，提升系統(tǒng)可用的運(yùn)行時間占比。很明顯，這個可用時長就非常關(guān)鍵了。

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

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

衡量系統(tǒng)可用性的 2 種方式

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

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

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

我們先來看時間維度的系統(tǒng)可用性。用一句話來概括：時長維度，是從故障角度出發(fā)對系統(tǒng)穩(wěn)定性進(jìn)行評估。

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

細(xì)想一下這個問題，你會發(fā)現(xiàn)還真有點(diǎn)復(fù)雜，那我就舉個發(fā)燒生病的例子來說明一下。

我們知道，一個人如果發(fā)燒了，體溫一般會超過 37.5 度，那如果這個人的體溫正好達(dá)到這個溫度，是不是代表他一定是生病了呢？依據(jù)生活經(jīng)驗(yàn)，我們知道不一定。為什么呢？因?yàn)槲覀兣袛嘁粋€人是否發(fā)燒生病，不是只看這一次、一時的體溫，還要看他體溫是不是持續(xù)超過 37.5 度。

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

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

這里同樣有三個要素：衡量指標(biāo)，系統(tǒng)請求狀態(tài)碼；衡量目標(biāo)，非 5xx 占比，也就是成功率達(dá)到 95%；影響時長，持續(xù) 10 分鐘。

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

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

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

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

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

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

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

用一句話來說，請求維度，是從成功請求占比的角度出發(fā)，對系統(tǒng)的穩(wěn)定性進(jìn)行評估。

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

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

你看，這種方式對系統(tǒng)運(yùn)行狀況是否穩(wěn)定監(jiān)管得更為嚴(yán)格，不會漏掉任何一次問題的影響， 因?yàn)樗鼘ο到y(tǒng)整體運(yùn)行的穩(wěn)定性判定，不僅僅會通過單次的異常影響進(jìn)行評估，還會累計疊加進(jìn)行周期性的評估。

到這里，我們就總結(jié)出一條至關(guān)重要的經(jīng)驗(yàn)了：故障一定意味著不穩(wěn)定，但是不穩(wěn)定，并不意味著一定有故障發(fā)生。

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

設(shè)定系統(tǒng)穩(wěn)定性目標(biāo)要考慮的 3 個因素

這個問題其實(shí)并沒有標(biāo)準(zhǔn)答案，從我的經(jīng)驗(yàn)來看，到底定“幾個 9”主要取決于以下三個因素。

第一個，成本因素

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

第二個，業(yè)務(wù)容忍度

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

但是，對于非核心業(yè)務(wù)或應(yīng)用，比如商品評論，商品評分等，或許“2 個 9”也能容忍。因?yàn)槎虝r間的評論看不到，并不會對業(yè)務(wù)收入和用戶體驗(yàn)造成太大的影響。

第三個，系統(tǒng)當(dāng)前的穩(wěn)定性狀況

結(jié)合系統(tǒng)的實(shí)際情況，定一個合理的標(biāo)準(zhǔn)比定一個更高的標(biāo)準(zhǔn)會更重要。這個合理的值應(yīng)該怎么來定呢？

我個人的建議是從系統(tǒng)現(xiàn)狀入手，比如，如果系統(tǒng)可用性是低于 99% 的，那首先第一步是不是可以做到? 99%，然后再爭取做到? 99.5%，再到? 99.9%，一步一步朝著更高的標(biāo)準(zhǔn)邁進(jìn)。同時，這樣做也會更容易落地，因?yàn)槟闳绻ㄒ粋€太高的目標(biāo)，又始終達(dá)不成，反而會打擊到團(tuán)隊的自信心和積極性。

結(jié)合上面這三個因素，對于到底應(yīng)該定“幾個 9”這個問題，你應(yīng)該有了一個更清晰的認(rèn)識了。

總結(jié)

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

這個知識點(diǎn)要拿一整節(jié)課來講，是因?yàn)榻酉聛砦覀兙鸵懻?SRE 的穩(wěn)定性指標(biāo)和目標(biāo)了， 理解了今天的內(nèi)容，你才能更好地理解 SRE 體系中的指標(biāo)(SLI)和目標(biāo)(SLO)。今天我先把 SLI 和 SLO 這兩個概念拋出來，如果你覺得有點(diǎn)陌生，沒有關(guān)系，準(zhǔn)備好下節(jié)課和我一起掌握它們。

思考題

對于系統(tǒng)可用性的描述，今天我們僅用了“狀態(tài)碼”這一個指標(biāo)來示例，但是在實(shí)際情況下，我們還會有其它多個指標(biāo)來同時標(biāo)識一個系統(tǒng)的穩(wěn)定性，你能想到還有哪些指標(biāo)？歡迎你在留言區(qū)寫下自己的思考。

考慮這些指標(biāo)的時候，不妨想想你是怎么選擇的，你的判斷標(biāo)準(zhǔn)是什么？這些也將是我們下節(jié)課程的重點(diǎn)內(nèi)容。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。