混沌實踐訪談:混沌工程和系統可觀測性密不可分
在O’Reilly的一份新報告“Chaos Engineering Observability: Bringing Chaos Experiments into System Observability”中,Russ Miles探究了為什麼他認為可觀測性和混沌工程這兩個主題是“密切相關”的。他認為,隨著工程師們深入開展混沌實驗,他們會提出很多有關係統底層的問題。
在O’Reilly最新的一份報告“Chaos Engineering Observability: Bringing Chaos Experiments into System Observability”中,Russ Miles探究了為什麼他認為可觀測性和混沌工程這兩個主題是“密切相關”的。他認為,隨著工程師們深入開展混沌實驗,他們會提出很多有關係統底層的問題。觀察並理解正在執行的系統是實現這一目標的一個重要的先決條件。因此,報告提供了一個簡短的指南,用於收集混沌實驗的指標、日誌和跟蹤資訊。
ChaosIQ.io CEO Miles與Humio團隊合作,一起產出了這份32頁的報告。報告主題包括:混沌工程訊號(探索如何獲得實驗進展通知,以及如何針對相關事件採取行動,以便更好地控制實驗)、混沌實驗日誌(需要一種有效的集中式日誌解決方案)、跟蹤混沌實驗(例如傳送OpenTracing資料,以便“拼湊出關鍵的答案,比如發生了什麼、事件發生的順序,以及是誰挑起了整個事件”)。
InfoQ聯絡了Humio的CEO Geeta Schmidt,從她那裡瞭解了Humio團隊如何看待他們與使用日誌管理平臺和混沌工程所做的工作之間的關係。
藉助混沌實驗,開發人員、安全團隊和運營管理人員可以以故障和威脅注入的形式進行有意的實驗,以此來細化、重新校準對系統的理解。對系統的進一步理解為客戶和使用者帶來了更好的體驗,並改進了業務結果。
“混沌原則”的“混沌實踐”一節中提到:“在一開始就定義’穩定狀態’,作為系統的可測量輸出,用以表明系統的正常行為”。Schmidt認為,為了“檢測系統何時是正常的,以及隨著實驗的進行它是如何偏離正常狀態的”,發展觀察系統的能力是非常重要的。她強調,在與Humio客戶一起工作時,團隊已經意識到,訪問可定製的、細粒度的、接近實時的度量和日誌可以更好地理解實驗所帶來的影響。
來自Gremlin的SRE負責人Tammy Butow在去年的倫敦QCon大會上發表了演講。他認為,實現有效的混沌工程實踐有三個主要先決條件:高嚴重性事件管理、監控和度量停機影響的能力。最初由Netflix贊助,並由Casey Rosenthal、Lorin Hochstein、Aaron Blohowiak、Nora Jones和Ali Basiri共同撰寫的O’Reilly混沌工程報告對這個主題進行了廣泛的描述,並討論了識別出需要在實驗期間進行觀察的指標的重要性。
在最近釋出的InfoQ混沌工程電子雜誌中,Michael Kehoe和Aaron Rinehart分別在“LinkedIn’s Waterbear: Influencing resilient applications”和“Using Chaos Engineering to Secure Distributed Systems”這兩篇文章中討論了觀察故障注入實驗和從可控實驗結果中獲得見解的必要性。Adaptive ability Labs聯合創始人John Allspaw表示,“可觀測性”一詞與之前的含義有所不同,而且與此相關的人為因素不應該被忽視。
InfoQ最近與Miles討論了混沌工程和可觀測性的話題。
InfoQ:感謝你能夠加入我們的討論。如果團隊是第一次接觸混沌工程和可觀測性,他們應該從哪裡開始著手?
Russ Miles:可以從“混沌原則”開始。
在此基礎上,我們建議使用混沌工具包,學習一些線上教程,然後著手建立自己的一些混沌實驗。這樣你就會開始質疑係統的可觀測性,然後下一步可以參考“Distributed Systems Observability”和“Chaos Engineering”這兩本書。
最後,你也可以加入一些很棒的社群,在社群中交換意見,獲得免費的建議。可加入的社群有谷歌混沌社群、Gremlin混沌工程社群Slack頻道,以及我們的團隊和社群Slack頻道。
混沌工程是構建永不停機系統的一個令人興奮的旅程。在前進的路上,這些社群可以幫助你,我們都認為混沌工程是一個關鍵的心態和紀律,可以幫助我們建立更強大、更有彈性、可靠和安全的系統。
InfoQ:在進行混沌實驗之前,系統可觀測性有多重要?
Miles:這個問題的關鍵詞是“之前”。擁有良好的系統可觀測性是非常重要的,但不管是否進行混沌工程實驗,這個都很重要,因為它不只是一個先決條件。
混沌工程和可觀測性這兩者配合得很好。
在某些情況下,在進行混沌實驗之前,你可能已經具備了一定的系統可觀察性,這在通過混沌工程實驗來診斷系統漏洞表面偏差時無疑是有幫助的。當然,在通進行混沌工程實驗過程中,這將成為一種“強制性功能”,如果不存在更好的系統可觀察性,它將會提出明顯的要求。
因此,根據我們的經驗,良好的系統可觀測性並不是混沌工程的一個強有力的先決條件。更多的時候,在進行混沌實踐時,對系統可觀測性的需求將會凸顯出來。隨著時間的推移,這兩種技術將會相互促進和加強。
有趣的是,這也是為什麼混沌工程會成為其他非功能性或以運營為重點的系統改進的一個很好的“強制性功能”。混沌工程通常會使這種容易被遺忘或被降低優先順序的關注點變得完全不可忽視,它幫助每個人意識到這些挑戰的存在,並設計和實現系統健壯性和彈性策略來應對這些挑戰。
簡而言之,混沌工程使每個人都成為一個更好的系統所有者,而系統可觀察性是一種幾乎立即就能獲得極大好處的能力。
InfoQ:混沌工程實踐會面臨什麼特別的挑戰嗎?理解和觀察混沌實驗本身有多重要?
Miles:組織實踐混沌工程失敗的原因有很多。他們可能不理解這種理念,或者混沌工程師限制其他團隊進行混沌實驗。混沌工程做得不好很容易導致這種理念被拒絕。
ChaosIQ團隊相信,組織中的每個人最終都會加入實踐混沌工程的行列。混沌工程並不是專屬於少數人的技術,而是一種有用的理念,適用於所有擁有關鍵任務業務系統的人。這意味著即使對於中等規模的組織來說,也存在大規模的混沌工程挑戰。從規模上看,混沌工程失敗的機率增加了。
不管對於什麼樣的規模,將混沌工程實踐當作一種驚喜是走向失敗的原因之一。也就是說,在執行實驗時,如果有人感到驚訝,那麼這對每個人來說通常都是一個糟糕的時刻,因為這些大吃一驚的人通常會請求不要再執行實驗。
有時候,用混沌實驗來給團隊一個驚喜也是有用的,比如說作為一個遊戲日的一部分。為了探究團隊如何應對動盪的環境,比如探究人員/實踐/流程的弱點,你可能不會告訴團隊接下來將會應用哪些條件,因此對他們來說可能是一個驚喜。然而,遊戲日本身並不會令人感到意外,這一點很重要。
在執行混沌實驗時,確保這些實驗不應該讓任何人感到驚訝。每個可能受到混沌實驗影響的人都應該知道正在執行什麼樣的混沌實驗、何時執行、針對什麼執行以及為什麼要執行這些實驗。
混沌工具包和平臺的實驗格式以及可插拔混沌工程可觀察性工具的組合使得這種跨團隊和跨組織的可見性成為可能,從而避免了意外混沌的危險以及可能會出現的不良反應。
因此,在很多方面,無論團隊的大小和混沌工程的能力如何,將混沌實驗引入到整個系統的可觀察性中對於避免這些陷阱來說都是至關重要的。混沌工程實驗也是系統中的公民,它們應該是良好的公民,除了執行時系統的其他方面,它們的活動也需要一起被瞭解和觀察。
Miles的報告“Chaos Engineering Observability: Bringing Chaos Experiments into System Observability”可通過Humio網站下載,下載前需要進行註冊。
檢視英文原文:
https://www.infoq.com/news/2019/03/chaos-engineering-observability
相關文章
- 聲網的混沌工程實踐
- 混沌工程最佳實踐 - 尋交流
- ChaosBlade混沌測試實踐
- 混沌系統程式
- 前端自動化混沌測試實踐前端
- 在 Ali Kubernetes 系統中,我們這樣實踐混沌工程
- 混沌演練實踐(一)
- 混沌工程簡介
- 混沌工程在創業公司的實踐 - 陸蓉蓉創業
- 混沌工程 - 軟體系統高可用、彈性化的必由之路
- Netflix 混沌工程手冊 Part 3:實踐方法
- 直播混沌工程之故障演練實踐總結
- 混沌工程入門指南
- 實時數倉混沌演練實踐
- 混沌測試介紹
- 【譯】混沌工程與區塊鏈區塊鏈
- Apache Kafka的4個混沌工程實驗 | IDCFApacheKafka
- 雲原生閘道器的可觀測性體系實踐
- Spring Cloud 應用在 Kubernetes 上的最佳實踐 — 高可用(混沌工程)SpringCloud
- FT-FMEA融合混沌演練,零售運營系統韌性架構線上驗證實踐架構
- 從混沌到體系化——DevSecOps在騰訊雲的落地實踐dev
- Dubbo 可觀測性實踐之 Metrics 功能解析
- 工作混沌狀態
- 披荊斬棘:論百萬級伺服器反入侵場景的混沌工程實踐伺服器
- 企業實踐|分散式系統可觀測性之應用業務指標監控分散式指標
- 混沌理論和專案管理(轉)專案管理
- 觀遠AI實戰 | 機器學習系統的工程實踐AI機器學習
- 微服務架構下的質量迷思——混沌工程微服務架構
- 淺談彈性計算管控可觀測性體系建設
- 好玩又實用,阿里巴巴開源混沌工程工具 ChaosBlade阿里
- 雲原生背景下故障演練體系建設的思考與實踐—雲原生混沌工程系列之指南篇
- 混沌工程平臺 ChaosBlade-Box 新版重磅釋出
- 基於雲原生閘道器的可觀測性最佳實踐
- 淺談微服務的發展以及可觀測性微服務
- 雲原生混沌工程測試平臺 Chaos Mesh 升級成為 CNCF 孵化專案
- 阿里云云原生微服務可觀測實踐阿里微服務
- 使用混沌候攻擊測試Spring Boot應用Spring Boot
- 混沌 IN C++::轉換函式C++函式