為什麼你的大多數監控政策都失敗了

作者 | Abdul Fattah Popoola

譯者 | Sambodhi

策劃 | 褚杏娟

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

• 未檢測到的降級導緻使用者感到痛苦。
• 無休止的、海嘯般的嘈雜警報。
• 24 小時待命壓力，難以承受，不可持續。

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

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

1. 脫節（Disconnect）：組織對使用者體驗的感覺與實際使用者體驗之間存在鴻溝。感覺與現實脫節的一些典型症狀包括：

• 盡管監控系統報告的狀态為“健康”，但使用者的投訴仍源源不斷。
• 缺乏主動的故障檢測，隻有在使用者投訴時才能檢測到中斷。
• 工程師試圖解釋頁面如何影響使用者。
• 一位工程師意外地發現了殘缺的功能。

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

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

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

監控政策是怎樣令使用者失望的

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

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

使用者需要的是什麼？舉個例子，在使用文字處理軟體時，我需要的是把東西寫好并完成工作，我不關心記憶體使用情況或處理器速度。是以，偶爾的當機或者崩潰是可以忍受的——我抱怨着重新開機程式，然後恢複工作。然而，如果我丢失了我的工作檔案，或者如果重新開機或重新整理或後仍然存在問題，我就會感到沮喪。

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

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

讓使用者滿意的要素：

• 産品團隊，性能、可靠性、持久性。有關更多資訊，請參見 No Surprises 文章。
• 平台團隊，不要止步于使用您服務的直接團隊，還要嘗試了解這些合作夥伴團隊的使用者。

一些使用者不滿意的代理名額的要素：

• 可靠性，由于内部系統錯誤而導緻的故障和不可靠的結果（例如，錯誤對話框）。
• 延遲性，操作花費的時間比預期的要長（例如，一個請求需要 10 秒鐘而不是 2 秒鐘）。
• 可用性，不應向使用者顯示的内部錯誤（例如，隐晦的通用消息或對使用者不友好的調試日志）。
• 持久性，任務關鍵型系統中的資料丢失（例如，無法儲存）。
• 可用性，當需要處理請求時，系統不可用（例如，無法通路伺服器）。

為什麼需要一個好的可觀察性名額？

以使用者為中心的可觀察性名額有兩個目标：

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

1. 主動警報。它們高度準确，可以提供回歸的早期警報。健康名額的任何突然和持續下降都與真正的使用者影響直接相關。在這些名額上設定警報将彌補生産上的可觀察性差距。

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

CAR 架構

CAR 架構的三個實體：使用者、應用程式和資源

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

它像測試金字塔一樣確定了重疊的監視覆寫，進而確定了測試覆寫。

CAR 金字塔展示了使用者、應用程式和資源之間的關系

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

1. 使用者：想要完成一些事情（如撰寫文檔、看 YouTube）。滿意度取決于應用程式是否按預期工作。
2. 應用程式：用于解決問題。應用程式可能出現崩潰或錯誤，完備的應用程式如果資源匮乏也會出現問題。
3. 資源：為應用程式提供合适的主機，例如 CPU、記憶體和 I/O，這些是應用程式順利運作所必需的。

大多數政策都假定健康的應用程式和資源能夠保證優秀的使用者體驗，但這種假設并不總是正确。

下圖中的紅色箭頭顯示了聚焦于單個層如何會導緻螢幕産生噪音。單一的綠線是穿過可觀察性并将其與使用者聯系起來的一種方式——以使用者為中心的名額是成功監控政策的關鍵。

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

使用 CAR 的結果

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

• 識别盲點：檢測以前不會被注意到的中斷，揭露系統中長期隐藏和存在的缺陷，進而進行适當的架構修複。
• 減少工作量：事故的數量級下降（主要是由于消除了噪音螢幕）。
• 信任：警報意味着真正的使用者問題，工程師有動力去找出根本原因。這比表面處理嘈雜的螢幕要好得多。
• 主動執行：減少事件量和暴露架構缺陷的工作量有助于團隊從反應性救火轉向主動、集中解決問題。

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

結束語

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

希望你從這篇文章中學到一件事——那就是確定你的監控政策與使用者滿意度直接挂鈎，即如果你的使用者不能使用你的應用程式，那 10 個 9 就不重要。

作者簡介：

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

原文連結：

https://abdulapopoola.com/2022/11/16/why-most-monitoring-strategies-fail/

本文轉載來源：

https://www.infoq.cn/article/5pOpTB9cLDwxfGuNrbIh