作者 | Mickael Alliel
譯者 | 王強
策劃 | 丁曉昀
微服務和高度分散式的系統是非常複雜的。系統中有許多移動部件，包括應用程式本身、基礎設施、版本和配置。通常，這會導致運維人員難以跟蹤生產或其他開發環境（QA、開發、預生產）中的實際情況，而當你需要對系統進行排障時這又成了一個問題。
在這篇文章中，我將圍繞監控和可觀察性的不同用例澄清一些內容，講一下什麼時候用到這兩個概念，以及如何正確使用它們。然後我將專注於變更感知（Change Intelligence）這個主題，這種新方法能夠遙測可操作的指標、日誌和跟蹤等資訊，以便實時有效地對事件排障。到目前為止，可觀察性一直專注於集合與你係統相關的資料，而監控則是標準化的檢查，以驗證基於這些資料的一切工作是否正常。變更感知構成了對現有遙測技術的增強，在所有東西都是分散式、公司有幾十甚至幾百個服務都在相互通訊的當今世界裡提供了更多上下文。這樣運維人員就可以在最近的變更之間建立聯絡，並最終了解它們對整個系統的影響。
可觀察性和監控之謎
我們先來了解一下監控和可觀察性，以及今天在具有複雜的微服務運維活動的工程組織中一般是如何實現它們的。
你經常會聽到有人說，可觀察性是指標、日誌和跟蹤的總和，但事實上，這種遙測只是正確獲得可觀察性的前提。為了讓資料真正可用，你需要確保它與你的業務需求和應用程式的工作方式建立聯絡。
談到監控時，大多數人想到的是儀表板。它們可能非常漂亮，但大多數開發人員並不真的想花一整天的時間盯著它們。這些往往是靜態警報，需要開發人員預先確定什麼東西可能出錯。
我看到的一個有趣的趨勢是，運維人員實際上利用可觀察性工具來找到問題的根因，然後將這種學習成果納入監控工具，以監控在未來重複出現的問題。如果你有適當的文件和執行手冊，監控和可觀察性之間的結合可以為你的可靠性計劃創造奇蹟。
這些檢查可以是各種形式，簡單的例子是確保某個系統的延遲低於某個閾值，或更復雜的例子，檢查一個完整的業務流程是否符合預期（將物品新增到購物車，併成功結賬）。你可能認為你已經掌握了系統中發生的全部情況，因為你已經有了監控和可觀察性，但是你仍然需要一塊關鍵的拼圖才能夠看到完整的情況。
缺少的拼圖：變更感知
為了能夠在問題出現時從系統中真正獲得你所需要的洞察力，你需要在拼圖中加入另一塊內容，那就是變更感知。變更感知不僅包括瞭解某些東西何時發生了變更，還要了解它為什麼發生了變更，誰改變了它，以及變更對你的系統產生了什麼影響。
對於運維工程師來說，現有的資料衝擊往往讓人不知所措。因此，引入變更感知是為了提供關於遙測的更廣泛的上下文，以及你已經擁有的資訊。例如，如果你有三個服務在相互交流，而其中一個服務的錯誤率升高，根據你的遙測，這就是一個很好的指標，說明出了什麼問題。
這是懷疑你的系統出了問題的一個很好的依據，然而，下一步，也是更關鍵的一步，你總是要開始挖掘，找到這個異常遙測資料背後的根因。如果沒有變更感知，你需要分析無數的問題來了解根因，即使你是按照你之前所做的那樣一步步遵循某個指南也無濟於事，因為到頭來，每個事件都是獨一無二的。
那麼，變更感知包括哪些內容呢？
首先，如果你正確實現了變更感知，它應該包括與“哪個服務正在與哪個服務通訊”有關的所有上下文（如服務對映）、在服務 A 中做出的變更如何影響其他服務（由於依賴關係，包括下游和上游）的資訊、在應用程式層面做出的配置變更和在基礎設施層或雲環境中做出的配置變更、沒有被釘住導致你無法控制的雪球效應的版本、雲環境中斷，以及任何可能影響業務連續性的東西。
因此，把這三個概念聯絡在一起就會是：
可觀察性為你提供符合你業務需求的資料格式。
監控是一組檢查，以確保你的業務在正常執行。
變更感知將所有這些資訊聯絡起來，使你能夠了解系統中的變更內容 / 原因 / 物件 / 方式，從而更快找到事件根因。
實踐中的事件排障
在轉向微服務之前，我曾在單體環境中工作，所以對這些型別的環境之間的巨大差異有第一手經驗。在單體系統中，監控和可觀察性是很好的元素，而在微服務中它們是完全必要的。
試圖對系統中具有不同目的和執行不同任務的多個服務進行排障是非常複雜的任務。這些較小的服務通常被分割成較小的塊狀，並同時執行幾個操作，因此需要在它們之間不斷交流資訊。
所以舉個例子——當你收到一個警報（通常是以頁面或 Slack 上的訊息的形式），通知你業務的某個部分沒有正常工作——很多時候，在真正的大規模分散式環境中，這可以歸因於許多不同的服務。如果沒有適當的監控和可觀察性，你並不能馬上看出來哪個服務出現了故障。它們可以幫助你瞭解在這個微服務的管道中問題出在哪裡，以及具體是哪個元件出現了故障。
當你處於某個事件產生的漩渦中時，你將花大部分時間試圖瞭解問題的根因來排障。你首先要弄清楚問題發生在你的數百個應用程式或伺服器中的什麼地方，然後一旦你隔離掉出故障的服務或應用程式，你就會想了解到底發生了什麼。這假定了一些並不總是被滿足的先決條件：
你有所有相關係統的必要許可權
你瞭解整個堆疊和所有這些系統中的所有技術
你有足夠的經驗來充分理解問題，進而解決問題
作為一名 DevOps 工程師（今天在 Komodor，以前在 Rookout），我經常遇到這些型別的場景，所以這裡有一個來自前線的簡短故事。我記得有一次，我和我的團隊開始收到來自我們系統中一個關鍵服務的大量錯誤［劇透：我們收到了數字值，當試圖將它們插入我們的資料庫時，列型別不匹配］。
我們唯一可以使用的錯誤資訊是：無效值。然後我們不得不搜尋我們的系統和最近的變更，試圖瞭解我們正在處理的資料和錯誤——我們花了一整天的時間來研究這個錯誤，最終了解到這是七個月前實現的一個變更。資料庫中的列型別是整數，而我們試圖插入更大的數字，因此需要一個大整數資料 / 列型別。如果沒有任何平臺或系統來幫助我們將這些錯誤與相關的變更聯絡起來，對於七個多月前發生的配置來說，即使是像數字太大這樣簡單的事情，也會讓整個有經驗的團隊花上一整天的時間，因為我們沒有變更感知來幫助我們解決問題。
所以——記住這個例子，現在讓我們看看其他一些例子，我將展示在有和沒有變更感知參與的情況下，排障工作分別會是什麼樣子。
可觀察性例項
在這個例子中，你會看到一個顯示請求數、錯誤數和響應時間的延遲的儀表板。
基於可觀察性的監控
接下來監控會進來攝取這些資料，然後提供對適當閾值的理解，以檢查在它歷史的上下文下這是否可以接受。
這是一個“查詢”的結果，其定期檢查歷史和實時資料，以對任何超過 2% 誤差的活動發出提醒，例如：
如果沒有變更感知，接下來會發生什麼：
如果沒有變更感知解決方案，你會收到來自 DataDog 的警報（基於上面的例子），告訴你活動超過了 2% 的錯誤閾值。你開始想“為什麼會發生這種情況？”並想出一些理論，如：應用程式程式碼可能被修改、網路問題、雲提供商或第三方工具問題，甚至問題可能與另一個服務有關，而該服務本身也有問題。為了找到真正的答案，你需要翻閱許多指標和日誌，然後試圖拼湊出問題的全貌以便找到根因，但沒有太多的跡象表明系統發生了什麼事情，在哪裡發生，以及是如何發生的，因為目前的監控和觀察工具中缺乏這種資料。
用變更感知進行監控和觀察：
你會收到來自 DataDog 的警報，但不同的是，你的下一個排障步驟將大大簡化，因為你有了一個變更感知解決方案，已經為你提供了有關上述所有理論的必要上下文。使用變更感知解決方案作為你的唯一真相來源後，你就可以立即看到最近歷史上的變更，將這些變更與可能影響服務的因素關聯起來（例如程式碼變更、配置變更、上游資源或相關服務的變更），然後迅速找到根因，而不是在多個解決方案及其日誌和指標中搜尋蹤跡，並試圖將它們拼湊成完整的影象，就像試圖在乾草堆中找到一根針一樣。
這種變更感知可以基於釋出說明、審計日誌、版本差異和屬性（誰做出的變更）。然後，這一變更的相關對映被交叉引用到無數不同的連線服務中，以找到最可能的故障罪魁禍首，從而實現更快速的恢復。
以時間軸和服務對映的形式提供資料（而不僅僅是帶有閾值和限制的儀表板），可以為整個系統提供更好的上下文。
上面的截圖顯示了 K8s（Komodor）的變更感知解決方案的一個例子，它顯示了一個由 DataDog 觸發的警報。現在你有了一個時間線，顯示出在問題發生之前，特定服務中發生的所有變更；所以你有了相關的上下文，可以更快地找到根因。
正如上面的截圖所示，我們可以利用這些資訊，從 Datadog 監控器觸發的起點開始追蹤，看看系統中到底發生了什麼或改變了什麼，從而更快地確定問題根因。在這個簡單的案例中，就在 Datadog 警報被觸發之前，我們可以看到有一個健康狀況變更事件，表明這個應用程式沒有足夠的可用副本。在這之前，該應用的一個新版本部署完畢。可能是在部署過程中，可用性沒有得到保證，或者是程式碼變更影響了這個應用，並引入了一個錯誤或重大變更。只要放大該部署的細節，我們就能在幾秒鐘內搞清楚觸發該警報的原因到底是什麼。
當資料 + 自動化還不夠的時候
系統正變得越來越複雜，有許多不同的服務、應用、伺服器、基礎設施、版本等等元素，而且所有這些的規模都是以前聞所未聞的。讓組織走到今天的工具，可能不足以為明天的系統和堆疊提供動力。
從前人們有日誌，然後有了跟蹤，之後是指標，這些都被彙集到儀表板中，為我們的運維健康提供視覺化的指示。隨著時間的推移，越來越多的工具被新增到這個鏈條中，以幫助推動和管理湧入的大量資料、警報和資訊。
變更感知將是增強未來堆疊能力的一個關鍵部分，並在現有的監測和觀察工具之上提供一個額外的可操作的洞察力層。這種方法最終能夠幫助我們快速恢復，維護今天的嚴格 SLA，並減少昂貴、痛苦和可能很漫長的停機時間。
作者介紹：
Mickael Alliel 是一位自學成才的開發人員，後來轉變成 DevOps 工程師，對自動化、創新和創造性地解決問題充滿熱情。Alliel 喜歡挑戰自己，嘗試新的技術和方法。目前他正在 Komodor 開發下一代 K8s 故障排除平臺，併兼任法國美食鑑賞家。
https：//www。infoq。com/articles/beyond-monitoring-change-intelligence/
