本文整理自快貓星云COO秦曉輝在WOT2023大會(huì)上的主題分享，更多精彩內(nèi)容及現(xiàn)場(chǎng)PPT，請(qǐng)關(guān)注《51CTO技術(shù)?！饭娞?hào)，發(fā)消息【W(wǎng)OT2023PPT】即可直接領(lǐng)取。

本文主要內(nèi)容包括：

• 可觀測(cè)性在整個(gè)商業(yè)體系中的位置和價(jià)值
• 如何快速發(fā)現(xiàn)故障，使用哪類指標(biāo)告警
• SRE 在談?wù)摴收隙ㄎ坏臅r(shí)候，談的是什么
• 如何找到故障直接原因，找到止損依據(jù)
• 如何讓可觀測(cè)性系統(tǒng)呈現(xiàn)觀點(diǎn)，輔助洞察，定位故障

可觀測(cè)性在整個(gè)商業(yè)體系中的位置和價(jià)值

做一個(gè)事，首先得有價(jià)值，如果價(jià)值太小不值得投入?？捎^測(cè)性也不例外，我們首先分析一下可觀測(cè)性在整個(gè)商業(yè)體系中的位置和價(jià)值。思考第一個(gè)問(wèn)題：作為在線類產(chǎn)品，我們希望客戶/用戶有一個(gè)好的產(chǎn)品體驗(yàn)，那怎么算一個(gè)好的產(chǎn)品體驗(yàn)？

很明顯，產(chǎn)品體驗(yàn)包括功能體驗(yàn)和可靠性體驗(yàn)。功能體驗(yàn)依賴產(chǎn)品設(shè)計(jì)和迭代速度，跟今天的話題關(guān)系不大暫且按下不表。可靠性體驗(yàn)?zāi)兀靠煽啃泽w驗(yàn)核心就是追求高可用、低延遲，通俗講就是每次打開(kāi)站點(diǎn)或app，都不報(bào)錯(cuò)，速度嗖嗖的。那如何才能具有好的可靠性體驗(yàn)?zāi)兀?/p>

其實(shí)如果一切正常，就應(yīng)該是可用且速度快的，除非哪里出了問(wèn)題，也就是發(fā)生了故障，才會(huì)報(bào)錯(cuò)或者延遲大增。那技術(shù)團(tuán)隊(duì)要做的，除了持續(xù)優(yōu)化架構(gòu)和性能，就是不斷和故障做斗爭(zhēng)了。降低故障發(fā)生的頻率，降低故障的影響范圍，降低故障的恢復(fù)時(shí)間。歸納為 6 個(gè)字：降發(fā)生、降影響！

怎么做？有沒(méi)有方法論來(lái)指導(dǎo)？我們可以從故障的生命周期著手，來(lái)優(yōu)化生命周期的各個(gè)環(huán)節(jié)，每個(gè)環(huán)節(jié)都做好了，理論上結(jié)果就是好的。故障生命周期的梗概圖如下：

從大面上，可以分成事前、事中、事后三個(gè)大的階段：

• 事前：及時(shí)發(fā)現(xiàn)風(fēng)險(xiǎn)，做好架構(gòu)、預(yù)案、演練
• 事中：及時(shí)發(fā)現(xiàn)故障，及時(shí)定位，及時(shí)止損
• 事后：排查根因，落實(shí)復(fù)盤改進(jìn)項(xiàng)

看起來(lái)寥寥數(shù)語(yǔ)，沒(méi)有特殊的東西，但實(shí)際上每個(gè)環(huán)節(jié)要做好，都不容易。那可觀測(cè)性，在這整個(gè)過(guò)程的職能是什么？在哪個(gè)環(huán)節(jié)發(fā)揮價(jià)值？

顯然，可觀測(cè)性，是在故障發(fā)現(xiàn)、定位環(huán)節(jié)發(fā)揮作用的，核心價(jià)值就是幫我們快速發(fā)現(xiàn)故障、快速定位故障，進(jìn)而降低故障的影響。如此，可觀測(cè)性的位置和價(jià)值就很明確了，用一張圖概括：

客戶/用戶需要好的產(chǎn)品體驗(yàn)，好的產(chǎn)品體驗(yàn)包括可靠性體驗(yàn)，要想有好的可靠性體驗(yàn)，就得減少故障，所謂的降發(fā)生、降影響，而這，又依賴了可觀測(cè)性的能力。所以：可觀測(cè)性最終是服務(wù)于產(chǎn)品體驗(yàn)、服務(wù)于商業(yè)成功的（想不想取得商業(yè)成功？根據(jù)剛才的分析可觀測(cè)性可是重點(diǎn)因素哦），核心目標(biāo)是快速發(fā)現(xiàn)、定位故障。

那么，如何快速發(fā)現(xiàn)故障？

如何快速發(fā)現(xiàn)故障，使用哪類指標(biāo)告警

要想能夠快速發(fā)現(xiàn)故障，得先定義什么是故障！簡(jiǎn)單來(lái)看，產(chǎn)品體驗(yàn)受損，就是故障！比如：

• 電商產(chǎn)品：用戶無(wú)法下單、無(wú)法支付、無(wú)法查看商品、無(wú)法查看歷史訂單
• 存儲(chǔ)系統(tǒng)：用戶無(wú)法讀、無(wú)法寫、或者讀寫延遲過(guò)高
• 流媒體產(chǎn)品：無(wú)法開(kāi)啟播放、無(wú)法拉流、無(wú)法瀏覽視頻信息

既然能夠定義如何算是產(chǎn)品體驗(yàn)受損，那就可以梳理出相關(guān)的監(jiān)控指標(biāo)，比如：

• 電商產(chǎn)品：訂單量、支付量、商品/訂單訪問(wèn)成功率/延遲
• 存儲(chǔ)系統(tǒng)：讀/寫成功率、讀/寫延遲
• 流媒體產(chǎn)品：播放量和成功率、拉流延遲、視頻瀏覽成功率/延遲等

大家有沒(méi)有發(fā)現(xiàn)這類指標(biāo)的特點(diǎn)？顯然，都是可以量化客戶體驗(yàn)的指標(biāo)，這類指標(biāo)我們稱為結(jié)果類指標(biāo)（后面會(huì)介紹原因類指標(biāo)），大面上可以分為兩類，一類是業(yè)務(wù)指標(biāo)，另一類是 SLO 指標(biāo)。

一般公司做監(jiān)控的時(shí)候，可能會(huì)意識(shí)到要做 SLO 指標(biāo)的監(jiān)控，容易忽略業(yè)務(wù)類指標(biāo)的監(jiān)控。其實(shí)，業(yè)務(wù)類指標(biāo)才是老板更為關(guān)注的指標(biāo)，而且，SLO 指標(biāo)正常的時(shí)候，業(yè)務(wù)指標(biāo)未必正常。比如客戶到服務(wù)端的網(wǎng)絡(luò)出問(wèn)題了，服務(wù)端的成功率、延遲指標(biāo)都是正常的，但是客戶無(wú)法下單，訂單量會(huì)下跌。所以，一定要重視業(yè)務(wù)指標(biāo)體系的構(gòu)建和監(jiān)控。

聽(tīng)起來(lái)，業(yè)務(wù)指標(biāo)和 BI 數(shù)據(jù)很像有沒(méi)有？確實(shí)，最大的相同點(diǎn)是：都是老板關(guān)注的，哈哈。不同點(diǎn)呢？BI 數(shù)據(jù)對(duì)準(zhǔn)確性要求很高，對(duì)實(shí)時(shí)性要求沒(méi)有那么高，而業(yè)務(wù)指標(biāo)監(jiān)控，對(duì)準(zhǔn)確性要求沒(méi)有那么高（只要能發(fā)現(xiàn)數(shù)據(jù)趨勢(shì)出問(wèn)題了就可以了），對(duì)實(shí)時(shí)性要求很高，畢竟是用來(lái)發(fā)現(xiàn)故障的，如果實(shí)時(shí)性太差，黃花菜都涼了。

指標(biāo)體系的構(gòu)建，除了結(jié)果類指標(biāo)，與之對(duì)應(yīng)的還有原因類指標(biāo)。都需要，但是我們配置告警的時(shí)候，一般是針對(duì)結(jié)果類指標(biāo)來(lái)配置。因?yàn)?strong>產(chǎn)品的核心業(yè)務(wù)功能是可枚舉的，每個(gè)功能對(duì)應(yīng)的結(jié)果類指標(biāo)就是可枚舉的，做好結(jié)果類指標(biāo)的告警，就可以保證告警是全的，做到有故障必有告警！舉個(gè)例子：實(shí)時(shí)交易類系統(tǒng)，交易量突然下跌。

如果，面向原因類指標(biāo)配置告警，則永遠(yuǎn)無(wú)法配全，無(wú)法做到有故障必有告警！實(shí)際上，原因類指標(biāo)不必一定要配置告警，出故障的時(shí)候可觀測(cè)，其實(shí)也基本夠了。

如上，要構(gòu)建可觀測(cè)性體系，首先要建立完備的指標(biāo)體系，其中非常關(guān)鍵的是結(jié)果類指標(biāo)，即業(yè)務(wù)指標(biāo)和 SLO 指標(biāo)，結(jié)果類指標(biāo)配合告警系統(tǒng)可以快速發(fā)現(xiàn)故障！從這里也可以看出，監(jiān)控（monitoring）和可觀測(cè)性（observability）是相輔相成的，非替代關(guān)系。

OK，既然可以發(fā)現(xiàn)故障了，下一步就是定位故障了。

SRE 在談?wù)摴收隙ㄎ坏臅r(shí)候，談的是什么

在討論這個(gè)問(wèn)題之前。先分享一個(gè)信息層級(jí)的概念。說(shuō)：信息分4個(gè)層級(jí)，最底下是數(shù)據(jù)，雜亂無(wú)章，比如海量的指標(biāo)、日志、鏈路追蹤的數(shù)據(jù)；數(shù)據(jù)上面是特征，比如最大值、最小值、同環(huán)比等，比如5個(gè)服務(wù)實(shí)例，延遲的最大的是哪個(gè)，這叫數(shù)據(jù)特征；特征上面是觀點(diǎn)，從故障定位場(chǎng)景來(lái)舉例，比如根據(jù)特征數(shù)據(jù)分析之后發(fā)現(xiàn)，數(shù)據(jù)庫(kù)沒(méi)有問(wèn)題，依賴的第三方服務(wù)也沒(méi)問(wèn)題，這就是觀點(diǎn)；觀點(diǎn)之上就是洞察，或稱洞見(jiàn)，綜合所有觀點(diǎn)，得出故障定位結(jié)論，得知具體是哪個(gè)模塊的什么原因?qū)е铝吮敬喂收?，就是最終洞察。畫個(gè)圖示例一下：

要想得到最終的洞察（定位到故障），首先要依賴底層的數(shù)據(jù)完備性，否則就是巧婦難為無(wú)米之炊！但是故障原因五花八門，數(shù)據(jù)能全么？做過(guò) SRE 或者運(yùn)維的朋友肯定感觸頗深，故障可能是電源模塊壞了、機(jī)房空調(diào)壞了、機(jī)柜壓住網(wǎng)線了、供電不穩(wěn)、某個(gè)盤故障了、中間件配置錯(cuò)了、被黑客攻擊了、分布式中間件腦裂了、寫日志hang住了、程序配置錯(cuò)了、程序連接第三方的地址錯(cuò)配成線下地址了、DNS配錯(cuò)了、證書過(guò)期了、代碼Bug了、疏漏了某個(gè)罕見(jiàn)用戶流程…等等等等。

這么多可能的故障原因，要通過(guò)可觀測(cè)性數(shù)據(jù)分析出來(lái)，這數(shù)據(jù)能全么？比如代碼 Bug，要想能根據(jù)可觀測(cè)性數(shù)據(jù)分析出是哪一行代碼的問(wèn)題，豈不是要像在 IDE 里調(diào)試那樣，每一行代碼的輸入輸出都得拿到啊，這成本誰(shuí)扛得住啊，性能損耗誰(shuí)扛得住啊…

如果我們的目標(biāo)只是定位直接原因，找到止損依據(jù)盡快止損，這個(gè)底層數(shù)據(jù)需求就少多了。比如我們不需要知道是哪行代碼出了問(wèn)題，我們只要知道是某個(gè)模塊做了變更導(dǎo)致了故障，就可以去止損（這個(gè)場(chǎng)景的止損動(dòng)作就是回滾）了。再比如，多活的服務(wù)，有時(shí)僅僅知道是 A 機(jī)房的問(wèn)題就可以了，把流量切到 B 機(jī)房就可以解決。

綜上，個(gè)人觀點(diǎn)：使用可觀測(cè)性數(shù)據(jù)定位根因，幾無(wú)可能100%覆蓋全部場(chǎng)景！因?yàn)閿?shù)據(jù)就不可能全！但如果只是用可觀測(cè)性數(shù)據(jù)定位直接原因，找到止損依據(jù)，則100%是可以做到的，而這，才是我們應(yīng)該努力的方向。

當(dāng) SRE 在談?wù)摴收隙ㄎ坏臅r(shí)候，其實(shí)談?wù)摰臅r(shí)是如何找到直接原因，盡快止損。而根因，可以留在復(fù)盤階段慢慢找的。

如何找到故障的直接原因

回答這個(gè)問(wèn)題之前，我們先來(lái)看看一個(gè)服務(wù)要想正常運(yùn)行，依賴了哪些內(nèi)容，或者說(shuō)一個(gè)服務(wù)如果出故障，可能會(huì)是哪里的問(wèn)題。如果我們能夠枚舉故障類別，那么我們就可以針對(duì)每個(gè)類別去分析，找到故障的直接原因。

首先，依賴的基礎(chǔ)設(shè)施（基礎(chǔ)網(wǎng)絡(luò)、硬件、Runtime環(huán)境）不能出問(wèn)題，依賴的第三方其他服務(wù)不能出問(wèn)題，這兩個(gè)方面大家比較容易理解，不多說(shuō)了。還有就是服務(wù)本身的變更，比如二進(jìn)制變更、配置的變更、部署方式的變更、流量接入方式的變更，等等，也可能引發(fā)問(wèn)題。最后就是上游訪問(wèn)的方式，比如流量突增，顯然也可能會(huì)帶來(lái)故障。

那針對(duì)這些故障場(chǎng)景，我們應(yīng)該去看哪些數(shù)據(jù)呢？這其實(shí)就是可觀測(cè)性數(shù)據(jù)底座的建設(shè)方向。

咦？說(shuō)來(lái)說(shuō)去，還是要建立 metrics、logs、traces、events？是的，但不僅是，只有數(shù)據(jù)還遠(yuǎn)遠(yuǎn)不夠，我們需要通過(guò)平臺(tái)工具，通過(guò)數(shù)據(jù)運(yùn)營(yíng)整理，幫助用戶找到數(shù)據(jù)特征，建立初步觀點(diǎn)，最終形成洞察定位故障直接原因。還記得那張信息層級(jí)的圖吧：

網(wǎng)上有人批評(píng)可觀測(cè)性三支柱的說(shuō)法，核心要點(diǎn)是：不能只關(guān)注 raw data，就像一道菜，只有原料還不能稱之為一道菜，沒(méi)有炊具、菜譜、廚師，無(wú)法最終產(chǎn)出那道菜（客人要的是那道菜，那道菜才是結(jié)果，應(yīng)該沒(méi)有哪個(gè)餐廳說(shuō)，你看我原料都有，完活了，讓客人吃吧，應(yīng)該沒(méi)有這樣的餐廳…）。

Martin Mao 曾經(jīng)也寫過(guò)一篇文章《Beyond the 3 Pillars of Observability》來(lái)論述這個(gè)事情。

他的核心觀點(diǎn)是：只關(guān)注三支柱raw data，認(rèn)為有了三支柱數(shù)據(jù)就建立了可觀測(cè)性，是不對(duì)的，我們更應(yīng)該面向結(jié)果來(lái)思考如何構(gòu)建整個(gè)體系，Martin Mao 認(rèn)為，所謂的結(jié)果，就是 Remediate，就是止損！英雄所見(jiàn)略同。

可觀測(cè)性體系具體要如何做才能輔助技術(shù)團(tuán)隊(duì)止損

還是參考剛才信息層級(jí)的圖，有了 raw data 數(shù)據(jù)底座之后，可觀測(cè)性體系還需要利用平臺(tái)能力、通過(guò)數(shù)據(jù)運(yùn)營(yíng)整理，呈現(xiàn)數(shù)據(jù)特征、幫用戶建立初步觀點(diǎn)，最終形成洞察，定位故障直接原因。

可觀測(cè)性體系要告訴我故障模塊

這應(yīng)該是可觀測(cè)性體系提供給客戶/用戶的第一個(gè)觀點(diǎn)，故障發(fā)生了，現(xiàn)在都是微服務(wù)的，你得一目了然的告訴我具體是哪個(gè)模塊故障了不是?？偛荒茏屛覍懸粭l有一條的 promql，看一個(gè)又一個(gè)監(jiān)控大盤，才能找到故障模塊吧。故障處理可是要爭(zhēng)分奪秒的，一個(gè)一個(gè)查看太浪費(fèi)時(shí)間了。

既然要一目了然，初始頁(yè)面上的內(nèi)容不能太多，從技術(shù)角度來(lái)看，一般模塊都是有層級(jí)關(guān)系的，首先是系統(tǒng)，然后是子系統(tǒng)，然后是模塊。所以，初始頁(yè)面應(yīng)該展示系統(tǒng)的健康狀況，如果某個(gè)系統(tǒng)有問(wèn)題，應(yīng)該可以點(diǎn)擊進(jìn)去查看詳情（這個(gè)過(guò)程稱為下鉆），下鉆到子系統(tǒng)，再下鉆到模塊，最終找到故障模塊。

那如何衡量一個(gè)模塊是否健康呢？這其實(shí)就可以使用 SLO/SLI 這套體系，每個(gè)模塊都有幾個(gè) SLI，每個(gè) SLI 異常，這個(gè)模塊就可以定義為異常，進(jìn)而定義子系統(tǒng)異常、系統(tǒng)異常，這個(gè)過(guò)程也有種故障冒泡上浮的感覺(jué)。

我以我們的產(chǎn)品來(lái)舉例這種效果圖：

這樣的系統(tǒng)我們稱為滅火圖，最上層是一個(gè)個(gè)的系統(tǒng)卡片，如果有問(wèn)題就會(huì)有個(gè)飄紅的小火苗，點(diǎn)擊詳情進(jìn)入，可以看到相關(guān)子系統(tǒng)，點(diǎn)擊故障子系統(tǒng)，可以看到模塊以及核心接口的列表，進(jìn)而可以定位到故障模塊或核心接口。產(chǎn)品通過(guò)顏色做引導(dǎo)，而且具備層級(jí)關(guān)系，即可做到一目了然。

可觀測(cè)性體系要告訴我故障模塊的各項(xiàng)依賴是否健康

模塊依賴的數(shù)據(jù)庫(kù)、中間件、基礎(chǔ)網(wǎng)絡(luò)、機(jī)器硬件、第三方服務(wù)等等，都會(huì)影響模塊的健康狀況。所以，當(dāng)模塊異常的時(shí)候，我們需要知道各項(xiàng)依賴是否健康，如果依賴也異常，那么模塊異常的直接原因基本可以斷定是異常的依賴項(xiàng)導(dǎo)致的。

要用可觀測(cè)性產(chǎn)品建立這樣的視圖，核心有兩點(diǎn)，一個(gè)是依賴的關(guān)聯(lián)關(guān)系，一個(gè)是依賴項(xiàng)的 SLO 視圖（通常體現(xiàn)為 metrics 儀表盤）。下圖是一個(gè)邏輯示意圖：

可觀測(cè)性體系要告訴我是否是變更導(dǎo)致的

線上故障，大概 70% 都是變更導(dǎo)致的，所以運(yùn)維行業(yè)中流傳一句話叫：“變更是萬(wàn)惡之源”。所以，當(dāng)故障發(fā)生的時(shí)候，我們需要知道是否是變更導(dǎo)致的，如果是變更導(dǎo)致的，就要盡快止損。

如果迭代比較快，每周的變更數(shù)量會(huì)很多，那么如何快速定位到是哪個(gè)變更導(dǎo)致的故障呢？這需要可觀測(cè)性產(chǎn)品提供一些數(shù)據(jù)特征給用戶，用戶才能方便分析。典型的是在時(shí)間維度上做文章。把故障和變更放到一張圖上，在時(shí)間維度上做對(duì)比，比如從故障時(shí)刻往前看 1 小時(shí)，看看有沒(méi)有變更，如果有，那個(gè)變更很可能就是罪魁禍?zhǔn)?。示意圖如下：

注意，這里的變更不僅僅是代碼變更，還包括配置變更、機(jī)器變更、網(wǎng)絡(luò)變更等等，變更事件收集得越全，越有價(jià)值。

上面，我舉例了三個(gè)可觀測(cè)性產(chǎn)品需要為用戶輸出的觀點(diǎn)：

• 可觀測(cè)性體系要告訴我故障模塊
• 可觀測(cè)性體系要告訴我故障模塊的各項(xiàng)依賴是否健康
• 可觀測(cè)性體系要告訴我是否是變更導(dǎo)致的

當(dāng)然，還有其他觀點(diǎn)可以輸出，比如是否是容量不足導(dǎo)致的故障，大家可以自行思考看看還可以讓可觀測(cè)體系輸出哪些觀點(diǎn)。但是，羅馬不是一天建成的，在某個(gè)階段，可觀測(cè)性體系輸出的觀點(diǎn)有限，不足以幫我們定位故障，此時(shí)，可觀測(cè)性體系還可以做什么呢？

至少，還需要提供工具幫我們分析數(shù)據(jù)特征，別讓用戶陷入海量散亂的可觀測(cè)性 raw data 中。這需要多維分析引導(dǎo)能力、數(shù)據(jù)串聯(lián)打通能力。舉一個(gè)數(shù)據(jù)串聯(lián)的例子：

總結(jié)

可觀測(cè)性體系不能僅僅只有散亂的數(shù)據(jù)，而應(yīng)讓數(shù)據(jù)呈現(xiàn)特征，讓特征呈現(xiàn)觀點(diǎn)，讓特征和觀點(diǎn)輔助洞察：洞悉故障直接原因，完成止損！這才是建設(shè)可觀測(cè)性體系的核心目標(biāo)。諸君共勉。