大多數(shù)監(jiān)控策略失敗的原因分析

作者：Abdul Fattah Popoola

未經(jīng)驗證的可觀察性和隨時待命的團隊總會不可避免地遇到反應(yīng)中斷，而要想減少中斷是很痛苦的，因為這就像蒙住雙眼在大海撈針。我之所以知道這些，是因為我曾穩(wěn)定了經(jīng)歷過混亂的團隊。

未檢測到的降級導(dǎo)致用戶感到痛苦。

無休止的、海嘯般的嘈雜警報。

24 小時待命壓力，難以承受，不可持續(xù)。

這篇文章是針對那些因為一直救火而精疲力竭的工程師們，對想要將一項成熟技術(shù)加入到工具箱中的管理者來說，也有所幫助。畢竟有誰會不喜歡一支高效的團隊呢？

1影響團隊永久反應(yīng)的四個原因

脫節(jié)（Disconnect）：組織對用戶體驗的感知與實際用戶體驗之間存在鴻溝。感知與現(xiàn)實脫節(jié)的一些典型癥狀包括：

盡管監(jiān)控系統(tǒng)報告的狀態(tài)為“健康”，但用戶的投訴仍源源不斷。

缺乏主動的故障檢測，只有在用戶投訴時才能檢測到中斷。

工程師試圖解釋頁面如何影響用戶。

一位工程師意外地發(fā)現(xiàn)了殘缺的功能。

不信任（Distrust）：一個大的危險信號是對觸發(fā)警報缺乏信心。監(jiān)控系統(tǒng)發(fā)出的錯誤警報越多，工程師們就越不信任這個系統(tǒng)。不幸的是，這種低信噪比的狀態(tài)加速了失修周期；工程師們厭倦了不斷喊“狼來了”的監(jiān)視器，直到不再關(guān)注這個問題。在這個階段，你就應(yīng)該拿著爆米花，等待不可避免的大規(guī)模中斷。

組織混亂（Disorganization）：沒有特定的案例，給到的“建議方法”取決于你與誰合作。這種缺乏組織性和清晰指導(dǎo)的表現(xiàn)為監(jiān)控框架激增、缺乏實戰(zhàn)檢驗的工具以及臨時中斷補救措施。工程師們總是采取碰運氣的解決方案，例如重啟電腦，并希望“問題”消失）。

失修（Disrepair）：工具、系統(tǒng)和警報已經(jīng)失修。產(chǎn)生問題的原因各不相同，有的是服務(wù)處于維護模式，有的是由于損耗而缺乏專門知識，還有的則是半死不活的項目。

2監(jiān)控策略是怎樣令用戶失望的

監(jiān)控的目標就是要保證用戶的良好體驗，主動把問題扼殺在搖籃里，或者能夠迅速緩解沒有捕捉到的問題。事實上，大部分方案都未能達到這個目標，原因并非是存在工具方面的差距，而是因為工具使用不當，這意味著并沒有理解核心問題出在哪里。

這一問題的顯著特征之一就是，疲于救火的團隊數(shù)量與可觀察性工具的數(shù)量相當。事實上，如果僅僅是工具的問題，那么使用 Prometheus/Nagios/geneva/kusto/ 等等，就能解決這個問題。

用戶需要的是什么？舉個例子，在使用文字處理軟件時，我需要的是把東西寫好并完成工作，我不關(guān)心內(nèi)存使用情況或處理器速度。因此，偶爾的凍結(jié)或者崩潰是可以忍受的——我抱怨著重啟程序，然后恢復(fù)工作。然而，如果我丟失了我的工作文件，或者如果重啟或刷新或后仍然存在問題，我就會感到沮喪。

用戶只有在造成不可逆轉(zhuǎn)的損害時才會關(guān)心這個故障。偶爾出現(xiàn)的崩潰、YouTube 故障或 PC 凍結(jié)都是可以忍受的，因為它是暫時的。

可觀察性策略必須回答的關(guān)鍵問題就是：你的用戶是否滿意？要回答這個問題，就需要了解你的用戶，知道什么能讓他們滿意。對這個問題的回答將滲透到可觀測性棧中，并且會對連貫的操作實踐產(chǎn)生影響。

讓用戶滿意的要素：

產(chǎn)品團隊，性能、可靠性、持久性。有關(guān)更多信息，請參見 No Surprises 文章。

平臺團隊，不要止步于使用您服務(wù)的直接團隊，還要嘗試了解這些合作伙伴團隊的用戶。

一些用戶不滿意的代理指標的要素：

可靠性，由于內(nèi)部系統(tǒng)錯誤而導(dǎo)致的故障和不可靠的結(jié)果（例如，錯誤對話框）。

延遲性，操作花費的時間比預(yù)期的要長（例如，一個請求需要 10 秒鐘而不是 2 秒鐘）。

可用性，不應(yīng)向用戶顯示的內(nèi)部錯誤（例如，隱晦的通用消息或?qū)τ脩舨挥押玫恼{(diào)試日志）。

持久性，任務(wù)關(guān)鍵型系統(tǒng)中的數(shù)據(jù)丟失（例如，無法保存）。

可用性，當需要處理請求時，系統(tǒng)不可用（例如，無法訪問服務(wù)器）。

3為什么需要一個好的可觀察性指標？

以用戶為中心的可觀察性指標有兩個目標：

指導(dǎo)完成目標。它們用戶為改善服務(wù)提供了一個目標燈塔——幫助確定優(yōu)先次序、跟蹤修復(fù)工作，并將重點放在杠桿率最高的干預(yù)措施上。它們也可以被整合到組織實踐中（如服務(wù)審查、事后檢查等），以確保細微的偏差不會被忽視（如幾周內(nèi)健康趨勢下降了 0.05%）。

主動警報。它們高度準確，可以提供回歸的早期警報。健康指標的任何突然和持續(xù)下降都與真正的用戶影響直接相關(guān)。在這些指標上設(shè)置警報將彌補生產(chǎn)上的可觀察性差距。

下面，讓我們討論一個經(jīng)過實戰(zhàn)檢驗和驗證的成熟策略。

4CAR 框架 CAR 框架的三個實體：用戶、應(yīng)用程序和資源

CAR 代表“用戶”（Customer）、“應(yīng)用程序”（Application）和“資源”（Resource），它通過建立三個實體（用戶、應(yīng)用程序和底層資源）之間的交互，提供監(jiān)視脫節(jié)的解決方案。

它像測試金字塔一樣確保了重疊的監(jiān)視覆蓋，從而確保了測試覆蓋。

CAR 金字塔展示了用戶、應(yīng)用程序和資源之間的關(guān)系

資源（如虛擬機、緩存）構(gòu)成了構(gòu)建應(yīng)用程序的基礎(chǔ)；反過來，應(yīng)用程序是為了滿足用戶的需求而構(gòu)建的。

用戶：想要完成一些事情（如撰寫文檔、看 YouTube）。滿意度取決于應(yīng)用程序是否按預(yù)期工作。

應(yīng)用程序：用于解決問題。應(yīng)用程序可能出現(xiàn)崩潰或錯誤，完備的應(yīng)用程序如果資源匱乏也會出現(xiàn)問題。

資源：為應(yīng)用程序提供合適的主機，例如 CPU、內(nèi)存和 I/O，這些是應(yīng)用程序順利運行所必需的。

大多數(shù)策略都假定健康的應(yīng)用程序和資源能夠保證優(yōu)秀的用戶體驗，但這種假設(shè)并不總是正確。

下圖中的紅色箭頭顯示了聚焦于單個層如何會導(dǎo)致監(jiān)視器產(chǎn)生噪音。單一的綠線是穿過可觀察性并將其與用戶聯(lián)系起來的一種方式——以用戶為中心的指標是成功監(jiān)控策略的關(guān)鍵。

使用 CAR 金字塔突出顯示脫節(jié)的度量

使用 CAR 的結(jié)果

以下是跨團隊應(yīng)用該策略的一些成果：

識別盲點：檢測以前不會被注意到的中斷，揭露系統(tǒng)中長期隱藏和存在的缺陷，從而進行適當?shù)募軜?gòu)修復(fù)。

減少工作量：事故的數(shù)量級下降（主要是由于消除了噪音監(jiān)視器）。

信任：警報意味著真正的用戶問題，工程師有動力去找出根本原因。這比表面處理嘈雜的監(jiān)視器要好得多。

主動執(zhí)行：減少事件量和暴露架構(gòu)缺陷的工作量有助于團隊從反應(yīng)性救火轉(zhuǎn)向主動、集中解決問題。

每個人都感到高興：用戶的中斷次數(shù)減少，工程師接到的電話也減少了。

5結(jié)束語

大多數(shù)典型的監(jiān)控策略都是“只見樹木不見森林”——他們只關(guān)注資源或應(yīng)用程序的健康狀況，而忽略了最關(guān)鍵的問題：用戶是否滿意？

希望你從這篇文章中學到一件事——那就是確保你的監(jiān)控策略與用戶滿意度直接掛鉤，即如果你的用戶不能使用你的應(yīng)用程序，那 10 個 9 就不重要。

作者簡介：

阿卜杜勒·法塔赫·波普拉（Abdul Fattah Popoola），具有超過 15 年的跨多個業(yè)務(wù)域和技術(shù)棧的軟件開發(fā)經(jīng)驗的工程領(lǐng)導(dǎo)者。擁有馬斯達爾學院（Masdar Institute）的計算和信息科學碩士學位以及沃洛沃大學（Obafemi Awolowo University）的計算機工程學士學位。

編輯：黃飛

?