Google雲基礎架構工程師:視覺隱喻的混沌工程和可觀察性
關鍵要點
- 對於現代軟體系統,可觀察性與數學方程無關。它是關於人們如何與他們的複雜系統互動並試圖理解他們的複雜系統。
- 可觀察性利用混沌工程,因為它允許檢測系統穩態的偏差。混沌工程利用可觀察性,因為它有助於發現和克服系統的弱點。
- 可觀察性以系統發出的訊號為基礎,並提供有關係統行為的原始資料。然而,可觀察性不僅受限於這些訊號的質量,還受限於這些訊號的視覺化和解釋方式。
- 考慮到混沌工程、可觀察性和視覺化涉及人類及其個人解釋,儀表板的設計者可能會對這些解釋產生偏見,這是一個事實。從這個意義上說,視覺隱喻並不能保證我們以正確的方式解釋這些資料。
- 基於視覺隱喻的儀表板可以提供比經典視覺化更有用的資料。然而,這兩種策略都容易產生偏見。例如,在一項研究中,大多數參與者注意到整體結果存在偏差,因為顯示的條形圖和折線圖沒有顯示圖中的重要截止點。
作者/ Yury Niño Roa
來源/翻譯外網
由於 Netflix、Slack 和 Linkedin 等領先的技術公司已經採用混沌工程學科來抵禦生產中的意外中斷,因此這一學科近年來已成為主流。在這條道路上,可觀察性發揮了關鍵作用,將資料和監控的力量帶給了工程師,他們現在有策略來了解他們的系統,確定當出現故障時他們將如何表現,並增加彈性和可靠性。
混沌工程和可觀察性是兩個緊密相連的學科。根據 Russ Miles 的說法,“可觀察性原則將系統變成可檢查和可除錯的犯罪現場,而混沌工程鼓勵並利用可觀察性來幫助先發制人地發現和克服系統弱點”。混沌工程鼓勵並要求可觀察性,因為要自信地執行混沌實驗,可觀察性必須檢測系統何時正常以及在執行方法實驗時它如何偏離該穩態。如圖 1 所示。
學術界和科技行業都做出了巨大的努力來提供實踐混沌工程和可觀察性的工具。但是,指標的視覺化和適當的視覺策略選擇仍然有限。本文介紹了一個新角色:視覺隱喻。具體來說,它提供了混沌工程和可觀察性的概念基礎,展示了市場上最先進的視覺化技術,並展示了樹形圖、儀表圖、地心圖和城市隱喻如何豐富視覺策略的範圍以觀察混沌。
01
混沌工程和可觀測性的基礎
關於混沌工程:混沌、彈性和可靠性是關鍵概念,而關於可觀察性,監控、指標和儀表板對於人類想要觀察他們的系統至關重要。因此,在深入研究混沌工程與可觀察性之間的關係之前,明確這些定義很重要。
混沌工程被混沌原理定義為在系統上進行實驗的學科,以建立對系統承受生產中動盪條件的能力的信心。為了專門解決大規模分散式系統的不確定性,混沌工程提供了一種基於以下四個步驟的實驗的方法:第一個步驟包括定義穩定狀態,即系統的可測量輸出,指示正常行為。第二步與假設相關聯,該假設提出了一個具有改變穩態後果的句子。有了這個假設,現在是時候介紹現實世界的事件了,例如伺服器崩潰或硬碟驅動器故障,以證實或反駁該假設。最後,
可觀察性是能夠完全理解一個系統。在控制理論中,它被定義為衡量一個系統的內部狀態可以從其外部輸出的知識中推斷出的程度。特別是,在軟體工程中,可觀察性可以被描述為提出正確問題、提供正確答案以及利用收集到的資料構建知識的藝術。
監控與可觀察性不同,瞭解差異很重要。監控是關於收集、處理、彙總和顯示有關係統的實時定量資料;而可觀察性是關於處理和分析資料,允許團隊積極理解和除錯系統的行為。對於現代軟體系統,可觀察性與數學方程無關。它是關於人們如何與他們的複雜系統互動並試圖理解他們的複雜系統。
從這個意義上說,監控涉及讀取系統通過稱為度量的數字傳送的訊號。指標是一個數字,可選擇附加標籤以進行分組和搜尋,例如查詢計數和型別、錯誤計數和型別、處理時間或伺服器生命週期。這些值在儀表板中視覺化,這些儀表板是提供服務核心指標核心摘要檢視的應用程式。
傳統上,儀表板是基於折線圖、餅圖或條形圖構建的。考慮到可觀察性取決於系統發出的訊號以及這些訊號的視覺化和解釋質量,因此提供最佳工具和設計非常重要。如果顏色、圖例和比例尺使用不當,一些視覺化可能會受到限制,並讓操作員感到困惑。下一節提供了監控和可觀察性的最新技術,並更詳細地描述了其中的一些限制。
02
監控和可觀察性
監控和可觀察性已成為工程團隊以及希望提供卓越解決方案的現代數字企業最重要的能力之一。由於監控和觀察系統的原因有很多,因此 Google 記錄了四個黃金訊號或指標,這些訊號或指標定義了系統健康的意義,並且是可觀察性和監控平臺當前狀態的基礎。四個指標描述如下:
延遲是服務處理請求所花費的時間。它包括由於失去與資料庫或其他可能無法很快提供服務的關鍵後端的連線而觸發的 HTTP 500 錯誤。延遲是一個基本指標,因為慢錯誤比快錯誤更糟糕。
流量是衡量系統需求量的指標。它確定系統在給定時間從使用者或通過服務執行的事務承受多少壓力。例如,對於 Web 服務,此度量通常是每秒 HTTP 請求數。通過監控應用程式或服務中的真實使用者互動和流量,工程團隊可以瞭解系統如何應對需求變化,以及他們應該如何擴充套件資源以滿足需求。
錯誤與顯式或隱式失敗的請求率相關。根據系統和發生故障的元件,監控錯誤情況可能會大不相同。這就是為什麼工程團隊需要監控整個系統以及單個服務級別的錯誤發生率的原因。優先考慮哪些錯誤是關鍵的,哪些是不那麼危險的,這也很重要。
最後,飽和度是系統關於資源利用率的訊號,例如記憶體、I/O 或 CPU。考慮到許多系統在達到 100% 利用率之前效能會下降,因此有一個飽和度目標是必不可少的。它使我們能夠回答以下問題:該服務還有多少容量?什麼程度的飽和度可以確保為客戶提供服務效能和可用性?
03
用於監控的傳統視覺化
如今,使用折線圖、條形圖或餅圖等傳統方法監控上一節中描述的四個黃金訊號。
折線圖是根據時間視覺化系統的四個黃金訊號的行為的最常用策略,如圖 2 所示。
圖 2. 虛構專案中的折線圖
折線圖在顏色、圖例、軸和系列標題方面提出了不同的挑戰,因為變數會聚、交叉並通常糾纏在一起。如果儀表板的建立者不使用適當的視覺資產,這種型別的圖形可能會變成最令人困惑的圖表之一。
另一個常見的圖表是條形圖,它用於顯示具有高度或長度的矩形條的分類資料,與它們所代表的值成比例。一些雲提供商使用它們來表示日誌的分類資料,如圖 3 所示。
圖 3. 虛構專案中的條形圖
最後,雖然使用較少,但餅圖是一種表示和比較資料分佈比例的簡單方法。當一個比例占主導地位時,它們最有效——一半或四分之三。多個顏色的多個楔形在楔形之間產生相同性,從而難以比較值。
考慮到這些限制,下一節將介紹一種視覺化四個黃金指標的不同方法。由於本文是關於混沌工程的,因此在報告事件的場景中分析了該技術。
04
視覺隱喻作為視覺化混亂的建議
為了克服前面提到的限制,本文提出了一種視覺化生產混亂的新策略。該提案基於其他科學領域的概念:視覺隱喻。視覺隱喻是一種將應用領域的概念和物件對映到相似性和類比系統的策略。計算機隱喻是互動式視覺物件和模型物件之間同化的基本思想。它的作用是促進對物件語義的更好理解。一個熟悉的例子可能是在跑車圖片前使用黑豹,這表明該產品在速度、動力和耐力方面具有可比性。
一些示例包括:地圖、城市和幾何場景,如圖 3 所示。該圖顯示了城市隱喻,這是一種用於視覺化程式程式碼屬性的流行方法。例如,許多專案都使用這種隱喻來視覺化軟體儲存庫的屬性。現有的研究已被用於繪製帶有包的社群,以及帶有建築物的類。
圖 4. 虛構專案中的城市隱喻,取自此處。
在這種情況下,隱喻將類表示為建築物,將包表示為建築物所在的社群。建築物的每個邊緣都用於對映類的屬性。
05
展示一個視覺化事件的實驗
為了確定參與運營活動的工程團隊的看法,對其中的 28 個進行了關於經典儀表板和視覺隱喻的調查。具體來說,他們被問及使用經典儀表板和視覺隱喻將四個黃金指標、錯誤、延遲、流量和飽和度視覺化的事件。
這項研究包括關於事件的具體問題,其中提供了兩種視覺化:一個帶有傳統圖表,另一個帶有視覺隱喻。對於每種情況,分析了每種視覺化型別的價值。在接下來的段落中,將介紹每個問題和分析。
在人口統計方面,有 28 名參與者的背景分佈在後端、前端和全棧工程師、軟體架構師、資料工程師和站點可靠性工程師中。最大的參與來自後端開發工程師,如圖 5 所示。
圖 5. 人口資料
第一個問題是關於飽和訊號的。基本上,使用了兩個儀表板(折線圖和城市隱喻)來詢問五個微服務的狀態:ms_authentication、ms_patients、ms_payments、ms_medications 和 ms_appointments。這些微服務是虛構醫療保健系統的一部分。
具體來說,問題是:使用傳統儀表板(參見圖 6)和視覺隱喻(參見圖 7),哪些微服務受到影響?正確答案是 ms_authentication。
圖 6. 傳統折線圖
圖 7. 視覺城市隱喻
如圖 8 所示,當他們使用視覺隱喻時,一些參與者的答案發生了變化,選擇了正確的答案。
圖 8. 參與者使用傳統圖表與視覺隱喻的回答
所有參與者都同意,受 CPU 高利用率影響的微服務是身份驗證。在這種情況下,視覺隱喻比傳統圖表更有用,因為炭線令人困惑,顏色、形狀和大小都很差,改變了參與者的感知。
關於錯誤訊號,使用經典條形圖和樹形圖要求參與者計算每個微服務的平均錯誤,如圖 9 所示。
圖 9. 用於視覺化錯誤的傳統條形圖
圖 10. 視覺化錯誤的視覺化樹形圖隱喻
正確答案是 ms_appointments,雖然有些參與者沒有選擇它,但他們中的許多人在使用視覺隱喻時改變了答案。圖 11 說明了這一點。
圖 11. 使用傳統圖表與視覺隱喻來視覺化錯誤的參與者的答案
關於交通訊號,使用經典的條形圖和地心比喻來詢問參與者哪個第三方服務的交通量更大。本案例分析了原有微服務與新增的四個第三方服務srv_ldap、srv_goverment、srv_assurance和srv_authentication之間的互動。圖 12 使用條形圖顯示了這種整合,圖 13 使用地心隱喻顯示了相同的流量值。在比喻中,圓圈代表服務和微服務,線條連線它們之間的關係。
圖 12. 用於視覺化微服務和第三方服務之間流量的傳統條形圖
圖 13. 視覺化微服務和第三方服務之間流量的視覺地心隱喻
儘管有線條和大小來表示微服務和第三方服務之間的連線和流量負載,但這個比喻讓參與者感到困惑。圓的大小可能與 srv_ldap 的最小百分比相關聯,這是正確答案,由餅圖中的綠色部分表示(參見圖 14)。
圖 14. 使用傳統圖表與視覺隱喻來視覺化微服務和第三方服務之間的流量的參與者的回答。
最後,我們使用條形圖視覺化與儀表隱喻來分析延遲訊號。兩種視覺化分別在圖 15 和 16 中說明。
圖 15. 用於視覺化延遲訊號的傳統條形圖。
圖 16. 視覺化微服務延遲的視覺化儀表隱喻。
對於這種情況,這個比喻絕對沒有為參與者提供價值,因為正確的答案是 ms_patients,如圖 17 所示。
圖 17. 使用傳統圖表與視覺隱喻來視覺化微服務和第三方服務之間的延遲的參與者的回答。
06
引入視覺隱喻的結論
混亂的視覺化,特別是生產事件的視覺化,對專注於可觀察性的工業和學術界提出了一些挑戰。正如我們在本文中所展示的,由於混沌工程、可觀察性和視覺化涉及人類與機器的互動,因此解釋中的偏差是一個持續存在的風險。通過一項研究,其中 28 位工程師回答了與經典儀表板與視覺隱喻相關的 12 個問題,可以得出結論,可觀察性不僅受到這些訊號的數量和質量的限制,而且還受到這些訊號的視覺化和解釋方式的限制。結論是視覺隱喻可以比經典儀表板表現更好,但是,由於兩者都涉及人類,因此無法保證操作員以正確的方式解釋事件中的資料。
有疑問加站長微信聯絡(非本文作者)
- 優維低程式碼:Route Alias 路由別名和Segues 頁面切換
- Go語言愛好者週刊:第 161 期
- 手寫程式語言-實現運算子過載
- Go語言愛好者週刊:第 160 期 — 竟然這麼多人不理解 map 的 make 含義
- 低程式碼實戰 | 1分鐘,從0到1建立一個簡單的微應用
- 優維低程式碼:Pipes 管道
- 【1-2 Golang】Go語言快速入門—陣列與切片
- 里程碑!用自己的程式語言實現了一個網站
- 【1-1 Golang】Go語言快速入門—基本語法
- Go語言愛好者週刊:第 159 期 — 這道題目有點意思
- 萬字長文告訴你Go 1.19中值得關注的幾個變化
- 9月更新!7個超好用的功能上線了!EasyOps®UI8.0更有大變動
- 碼住!Golang併發安全與引用傳遞總結
- Google雲基礎架構工程師:視覺隱喻的混沌工程和可觀察性
- 統一的可觀察性:指標、日誌和跟蹤
- 用位運算為你的程式加速
- 如何用Golang來手擼一個Blog - Milu.blog 開發總結
- 十七年運維老兵萬字長文講透優維低程式碼~
- 一文讀懂 Kubernetes的四種服務型別!
- 優維低程式碼:Use Resolves