筆者從 12 年開始入行，從事 DevOps 研發(fā)工作，做過部署系統(tǒng)、監(jiān)控系統(tǒng)、可觀測性相關產品，也做過 SRE 一線和管理工作，對于可觀測性的理解和實踐，有一些小小的見解，利用本文和大家做一個探討分享。本文主要內容包括：

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

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

• SRE 在談論故障定位的時候，談的是什么

• 如何找到故障直接原因，找到止損依據

• 如何讓可觀測性系統(tǒng)呈現(xiàn)觀點，輔助洞察，定位故障

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

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

很明顯，產品體驗包括功能體驗和可靠性體驗。功能體驗依賴產品設計和迭代速度，跟今天的話題關系不大暫且按下不表?？煽啃泽w驗呢？可靠性體驗核心就是追求高可用、低延遲，通俗講就是每次打開站點或app，都不報錯，速度嗖嗖的。那如何才能具有好的可靠性體驗呢？

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

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

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

• 事前：及時發(fā)現(xiàn)風險，做好架構、預案、演練

• 事中：及時發(fā)現(xiàn)故障，及時定位，及時止損

• 事后：排查根因，落實復盤改進項

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

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

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

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

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

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

• 電商產品：用戶無法下單、無法支付、無法查看商品、無法查看歷史訂單

• 存儲系統(tǒng)：用戶無法讀、無法寫、或者讀寫延遲過高

• 流媒體產品：無法開啟播放、無法拉流、無法瀏覽視頻信息

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

• 電商產品：訂單量、支付量、商品/訂單訪問成功率/延遲

• 存儲系統(tǒng)：讀/寫成功率、讀/寫延遲

• 流媒體產品：播放量和成功率、拉流延遲、視頻瀏覽成功率/延遲等

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

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

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

指標體系的構建，除了結果類指標，與之對應的還有原因類指標。都需要，但是我們配置告警的時候，一般是針對結果類指標來配置。因為產品的核心業(yè)務功能是可枚舉的，每個功能對應的結果類指標就是可枚舉的，做好結果類指標的告警，就可以保證告警是全的，做到有故障必有告警！舉個例子：實時交易類系統(tǒng)，交易量突然下跌。

如果，面向原因類指標配置告警，則永遠無法配全，無法做到有故障必有告警！實際上，原因類指標不必一定要配置告警，出故障的時候可觀測，其實也基本夠了。

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

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

SRE 在談論故障定位的時候，談的是什么

在討論這個問題之前。先分享一個信息層級的概念。說：信息分4個層級，最底下是數(shù)據，雜亂無章，比如海量的指標、日志、鏈路追蹤的數(shù)據；數(shù)據上面是特征，比如最大值、最小值、同環(huán)比等，比如5個服務實例，延遲的最大的是哪個，這叫數(shù)據特征；特征上面是觀點，從故障定位場景來舉例，比如根據特征數(shù)據分析之后發(fā)現(xiàn)，數(shù)據庫沒有問題，依賴的第三方服務也沒問題，這就是觀點；觀點之上就是洞察，或稱洞見，綜合所有觀點，得出故障定位結論，得知具體是哪個模塊的什么原因導致了本次故障，就是最終洞察。畫個圖示例一下：

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

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

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

綜上，個人觀點：使用可觀測性數(shù)據定位根因，幾無可能100%覆蓋全部場景！因為數(shù)據就不可能全！但如果只是用可觀測性數(shù)據定位直接原因，找到止損依據，則100%是可以做到的，而這，才是我們應該努力的方向。

當 SRE 在談論故障定位的時候，其實談論的時是如何找到直接原因，盡快止損。而根因，可以留在復盤階段慢慢找的。

如何找到故障的直接原因

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

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

那針對這些故障場景，我們應該去看哪些數(shù)據呢？這其實就是可觀測性數(shù)據底座的建設方向。

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

網上有人批評可觀測性三支柱的說法，核心要點是：不能只關注 raw data，就像一道菜，只有原料還不能稱之為一道菜，沒有炊具、菜譜、廚師，無法最終產出那道菜（客人要的是那道菜，那道菜才是結果，應該沒有哪個餐廳說，你看我原料都有，完活了，讓客人吃吧，應該沒有這樣的餐廳…）。

Martin Mao 曾經也寫過一篇文章《Beyond the 3 Pillars of Observability》來論述這個事情。

他的核心觀點是：只關注三支柱raw data，認為有了三支柱數(shù)據就建立了可觀測性，是不對的，我們更應該面向結果來思考如何構建整個體系，Martin Mao 認為，所謂的結果，就是 Remediate，就是止損！英雄所見略同。

可觀測性體系具體要如何做才能輔助技術團隊止損

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

可觀測性體系要告訴我故障模塊

這應該是可觀測性體系提供給客戶/用戶的第一個觀點，故障發(fā)生了，現(xiàn)在都是微服務的，你得一目了然的告訴我具體是哪個模塊故障了不是。總不能讓我寫一條有一條的 promql，看一個又一個監(jiān)控大盤，才能找到故障模塊吧。故障處理可是要爭分奪秒的，一個一個查看太浪費時間了。

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

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

我以我們的產品來舉例這種效果圖：

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

可觀測性體系要告訴我故障模塊的各項依賴是否健康

模塊依賴的數(shù)據庫、中間件、基礎網絡、機器硬件、第三方服務等等，都會影響模塊的健康狀況。所以，當模塊異常的時候，我們需要知道各項依賴是否健康，如果依賴也異常，那么模塊異常的直接原因基本可以斷定是異常的依賴項導致的。

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

可觀測性體系要告訴我是否是變更導致的

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

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

注意，這里的變更不僅僅是代碼變更，還包括配置變更、機器變更、網絡變更等等，變更事件收集得越全，越有價值。

上面，我舉例了三個可觀測性產品需要為用戶輸出的觀點：

• 可觀測性體系要告訴我故障模塊

• 可觀測性體系要告訴我故障模塊的各項依賴是否健康

• 可觀測性體系要告訴我是否是變更導致的

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

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

總結

可觀測性體系不能僅僅只有散亂的數(shù)據，而應讓數(shù)據呈現(xiàn)特征，讓特征呈現(xiàn)觀點，讓特征和觀點輔助洞察：洞悉故障直接原因，完成止損！這才是建設可觀測性體系的核心目標。諸君共勉。如果您認同我們的建設思路和價值主張，也歡迎關注我們的產品：https://flashcat.cloud/，我們愿意成為您向上的臺階，讓您的可觀測性體系更加完善，讓技術體系底氣更足?？靵砹牧陌桑?/p>