作者：Abdul Fattah Popoola

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

未檢測到的降級導致用戶感到痛苦。

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

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

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

1影響團隊永久反應的四個原因

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

盡管監控系統報告的狀態為“健康”，但用戶的投訴仍源源不斷。

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

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

一位工程師意外地發現了殘缺的功能。

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

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

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

2監控策略是怎樣令用戶失望的

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

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

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

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

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

讓用戶滿意的要素：

產品團隊，性能、可靠性、持久性。有關更多信息，請參見 No Surprises 文章。

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

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

可靠性，由于內部系統錯誤而導致的故障和不可靠的結果（例如，錯誤對話框）。

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

可用性，不應向用戶顯示的內部錯誤（例如，隱晦的通用消息或對用戶不友好的調試日志）。

持久性，任務關鍵型系統中的數據丟失（例如，無法保存）。

可用性，當需要處理請求時，系統不可用（例如，無法訪問服務器）。

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

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

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

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

下面，讓我們討論一個經過實戰檢驗和驗證的成熟策略。

4CAR 框架 CAR 框架的三個實體：用戶、應用程序和資源

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

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

CAR 金字塔展示了用戶、應用程序和資源之間的關系

資源（如虛擬機、緩存）構成了構建應用程序的基礎；反過來，應用程序是為了滿足用戶的需求而構建的。

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

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

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

大多數策略都假定健康的應用程序和資源能夠保證優秀的用戶體驗，但這種假設并不總是正確。

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

使用 CAR 金字塔突出顯示脫節的度量

使用 CAR 的結果

以下是跨團隊應用該策略的一些成果：

識別盲點：檢測以前不會被注意到的中斷，揭露系統中長期隱藏和存在的缺陷，從而進行適當的架構修復。

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

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

主動執行：減少事件量和暴露架構缺陷的工作量有助于團隊從反應性救火轉向主動、集中解決問題。

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

5結束語

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

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

作者簡介：

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

編輯：黃飛

?