軟件和系統開發是創新和解決未知問題的練習。軟件和系統是容易出錯的，因為它們是由具有不同觀點和技能的人（很可能是多人）制作的。技術變得越來越分散和復雜，尤其是隨著微服務的推動。很少有人擁有完整的端到端知識 […]

軟件和系統開發是創新和解決未知問題的練習。軟件和系統是容易出錯的，因為它們是由具有不同觀點和技能的人（很可能是多人）制作的。技術變得越來越分散和復雜，尤其是隨著微服務的推動。很少有人擁有整個系統的全部端到端知識。

類似于圍繞態勢感知的軍事術語，戰爭迷霧，在現代發展中理解變化的總體影響可能很困難（發展迷霧）。再加上用戶對系統始終可用的期望，測試系統的穩健性和對未知數的彈性可能只是：一個未知數。

混沌工程通過在整個應用程序和基礎架構堆棧中注入故障，然后允許工程師驗證行為并進行調整，從而使故障不會向用戶顯現，從而幫助解決未知問題。再加上站點可靠性工程實踐的興起，混沌工程試圖計算不可能的影響。

混沌史

站點可靠性工程師的熱門讀物是 Nicholas Taleb 的《黑天鵝：極不可能的影響》（2007 年）。塔勒布在他的作品中介紹了黑天鵝的隱喻。塔勒布將黑天鵝事件分類，例如突然的自然災害或在出版他的書時的商業活動，谷歌取得了驚人的空前成功。黑天鵝事件具有三個特征：不可預測，影響巨大，當它結束時，我們會設計一種解釋，讓黑天鵝看起來不那么隨機。

在處理發展的迷霧時，我們很容易陷入分布式計算的謬誤，這是計算機科學家 Peter Deutsch 提出的一組關鍵斷言。一些主要的謬誤是：網絡可靠，延遲為零，帶寬無限，并且只有一名管理員。消除謬誤，您的服務將始終如一，并且隨時可用。正如我們所知，系統和服務總是會起起落落——但是當涉及到開發未知的細節時，我們很容易忘記這一點。

例如，假設我們正在構建一些依賴 Amazon S3 進行對象存儲的功能。如果我們正在為執行復雜處理的服務構建功能并且最終輸出是在 S3 中寫入或更新對象，我們作為工程師可能會假設 S3 將在那里。我們上下測試我們的功能，并為 S3 部分提供不太復雜的測試覆蓋率。亞馬遜網絡服務在 2017 年發生了自己的黑天鵝事件，當時 S3 遭遇中斷。我們認為會存在的東西（即使性能/寫入 SLA 降低）也沒有，分布式計算的謬誤又回來咬我們。

S3 中斷確實有助于確保我們接觸到堆棧的所有部分，即使我們接觸的部分看起來并不明顯，這可能是由于我們對分布式計算的謬誤的看法/迷霧。混沌工程和混沌實驗帶來了可控的混沌，因此我們可以擺脫這些類型的事件。

什么是混沌工程？

混沌工程是故意將故障注入系統以衡量彈性的科學。與任何科學方法一樣，混沌工程專注于實驗/假設，然后將結果與對照（穩態）進行比較。分布式系統中典型的混沌工程示例是關閉隨機服務，以查看項目如何響應以及對用戶旅程的損害表現在哪些方面。

如果您對應用程序需要運行的內容（計算、存儲、網絡和應用程序基礎設施）進行橫截面分析，則將故障或動蕩條件注入該堆棧的任何部分都是有效的混沌工程實驗。網絡飽和或存儲突然變得不穩定/滿負荷是技術行業已知的故障，但混沌工程允許對這些故障進行更可控的測試，等等。由于可能會影響廣泛的基礎設施，混沌工程的用戶和從業者幾乎可以是支持應用程序/基礎設施堆棧的任何人。

誰使用混沌工程？

由于混沌工程涉及廣泛的技術和決策，混沌工程實驗可能有多個利益相關者。爆炸半徑越大（受測試和實驗影響的范圍），參與的利益相關者就越多。

根據應用程序堆棧的領域（計算、網絡、存儲和應用程序基礎架構）以及目標基礎架構所在的位置，這些團隊的利益相關者可以參與其中。

如果爆炸半徑很小并且可以在運行的容器中進行測試，那么應用程序開發團隊可以進行測試，而不必擔心突破容器。如果工作負載或基礎設施的影響范圍更廣（例如，測試 Kubernetes 基礎設施），平臺工程團隊很可能會參與其中。為未知提供覆蓋是運行 Chaos 測試和尋找弱點的核心原因。

為什么要進行混沌測試？

開發的迷霧是非常真實的，尤其是對于更大的分布式系統、復雜系統和微服務實現。從應用程序的角度來看，每個單獨的微服務都可以單獨測試并確定按設計工作。正常的監控技術可以認為單個服務是健康的。

使用微服務模式，單個請求可以遍歷多個服務以獲得聚合響應來滿足用戶或其他服務的請求。服務之間的每個遠程請求都在遍歷額外的基礎設施并跨越不同的應用程序邊界，所有這些都可能失敗。

如果一項瑣碎或非瑣碎的服務或基礎設施在服務水平協議 (SLA) 范圍內沒有響應，系統的功能和用戶旅程將受到怎樣的影響？這正是混沌工程正在解決的問題。混沌工程實驗的結果隨后被用于創建一個更具彈性的系統。

混沌工程原理

《混沌工程原理》是一篇出色的宣言，描述了混沌工程的主要目標和原則。混沌工程原理進一步分解了四種類似于科學方法的實踐。但是，與科學方法不同的是，假設系統是穩定的，然后尋找方差。越難中斷穩態，系統的信心和穩健性就越高。

從定義基線開始（穩態）

了解什么是正常/穩定對于檢測偏差/回歸至關重要。根據您要測試的內容，擁有一個良好的指標，例如響應時間或更高級別的目標，例如在特定時間內完成用戶旅程的能力，是衡量正常性的良好指標。實驗中的穩態是對照組。

假設穩態將持續

與科學方法背道而馳，假設一個假設一直都是真的不會留下太多的余地。混沌工程旨在針對強大而穩定的系統運行，試圖找出應用程序故障或基礎設施故障等故障。對不穩定的系統運行混沌工程并沒有提供太多價值，因為這些系統已經不可靠并且不穩定性是已知的。

引入變量/實驗

與任何科學實驗一樣，混沌工程在實驗中引入變量以查看系統如何響應。這些實驗代表了影響應用程序四大支柱中的一個或多個的真實故障場景：計算、網絡、存儲和應用程序基礎設施。例如，故障可能是硬件故障或網絡中斷。

嘗試反駁假設

如果假設是針對穩態的，則穩態的任何方差或中斷（對照組和實驗組之間的差異）都反駁了穩定性假設。現在有了一個可以關注的領域，可以進行修復或設計更改，以使系統更加健壯和穩定。

在實施混沌工程實驗時，實施混沌工程的原則會導致一些設計注意事項和最佳實踐。

混沌工程最佳實踐

在實施混沌工程或任何測試時，有三個支柱。第一個是提供足夠的覆蓋范圍，第二個是確保經常運行實驗并在生產中模擬/運行，第三個是最小化爆炸半徑。

為估計的故障頻率/影響提供覆蓋范圍

在軟件中，您永遠不會達到 100% 的測試覆蓋率。建立覆蓋需要時間，而考慮每個特定場景是一個白日夢。覆蓋范圍致力于使最有影響力的測試。在混沌工程中，這將測試會產生嚴重影響的項目，例如存儲不可用或可能發生很多的項目，例如網絡飽和或網絡故障。

在您的管道中連續運行實驗

軟件、系統和基礎設施確實會發生變化——每個人的狀況/健康狀況都可能會迅速發生變化。運行實驗的好地方是在 CI/CD 管道中。CI/CD 管道在進行更改時執行。衡量變革的潛在影響的最佳時機莫過于變革開始在管道中建立信心的旅程。

在生產中運行實驗

正如在生產中進行測試的可怕想法一樣，生產是用戶所處的環境，流量峰值/負載是真實的。為了全面測試生產系統的穩健性/彈性，在生產環境中運行混沌工程實驗將提供所需的見解。

最小化爆炸半徑

因為你不能以科學的名義降低生產，所以限制混沌工程實驗的爆炸半徑是一種負責任的做法。專注于小實驗，這些實驗會告訴你你想要識別什么。專注于范圍和測試。例如，兩個特定服務之間的網絡延遲。比賽日計劃可以幫助計算爆炸半徑和重點。

有了這些最佳實踐，混沌工程是一門不同于負載測試的學科。

混沌工程和負載測試有什么區別？

當然，負載本身會帶來混亂。我們通常將我們的系統設計為在多個部分中具有彈性（啟動額外的計算、網絡、持久性和/或應用程序節點以應對負載）。那是假設一切都在同一/適當的時間出現，因此我們可以領先于負載。

在計算機科學領域，Thundering Herd 問題（驚群問題)并不新鮮，但隨著我們向更加分布式的架構邁進，它會更加普遍地表現出來。例如，Thundering Herd 問題可能在機器級別，因為大量進程被啟動，另一個進程成為瓶頸（處理一個且僅一個新進程的能力）。在分布式架構中，Thundering Herd 可能是您的消息系統能夠一次攝取大量消息/事件，但處理/持久化這些消息可能會成為瓶頸。如果您收到消息過多，您好 Thundering Herd。

負載測試肯定會幫助我們為雷鳴群做準備，這是一種壓力，但是如果系統的一部分甚至不存在，或者游戲遲到了怎么辦？這就是混沌工程的用武之地。如果沒有混沌工程，一個非常難以測試的項目將是級聯故障。歷史上更等同于電網，級聯故障是一個部分的故障可以觸發其他部分的故障。在分布式系統領域，這是我們試圖找到單點故障并確保我們的應用程序/基礎設施足夠健壯以處理故障。

今天，不乏工具和平臺來幫助您實現混沌工程目標。

混沌工程工具

圍繞混沌工程有很多進步和工具。很棒的資源列表是 Awesome Chaos Engineering 列表。此列表向構建 Chaos Engineering 的混沌測試工具致敬，向使 Chaos Engineering 更易于使用的新平臺致敬。

混沌猴（Chaos Monkey）

Chaos Monkey 被公認為最早的混沌工程工具之一，由 Netflix 開發。最初的 Chaos Monkey 會隨機禁用生產實例。最終，混沌猴成為了猿猴軍團（Simian Army）的一員。盡管今天 Chaos Monkey 是一個獨立的項目。

四面軍(The Simian Army)

受原始 Chaos Monkey 成功的啟發，Simian Army 是一系列工具（例如 Janitor Monkey、Latency Monkey、Security Monkey 和 Doctor Monkey），專注于引入不同類型的故障。今天，四面軍退役了。

Gremlin 平臺（Gremlin Platform）

Gremlin 是最早的 SaaS 混沌工程平臺之一。Gremlin 能夠協調和測量打包在 SaaS 平臺中的混沌工程實驗。如果這是您第一次涉足混沌工程，Gremlin 提供了很多很棒的資源。

AWS 故障注入模擬器（AWS Fault Injection Simulator）

最近專注于 AWS 服務，AWS 提供了故障注入模擬器。如果您完全使用 AWS 平臺并希望將混沌工程實驗引入您的 AWS 環境，AWS FIS 是一個不錯的選擇。了解有關故障注入測試及其優勢的更多信息。

無論您選擇哪種工具，您的 CI/CD 管道都是運行和編排混沌工程實驗的好地方。

試驗您的 CI/CD 管道

隨著在系統中建立信心的新方法開始受到關注，CI/CD 管道是協調建立信心步驟的好地方。混沌工程實驗非常適合在 CI/CD 管道中運行。最近，Harness 和 Gremlin 創建了一個演示，展示了 CI/CD 管道和 Gremlin Experiments 之間的集成。

可能的藝術是讓混沌工程實驗的結果影響部署，或者如果部署到較低的環境，讓 Harness 作為混沌工程實驗和其他自動化測試的協調器。如需完整示例，請前往 Harness 社區了解更多信息。

線束（Harness ）在這里提供幫助

Harness 軟件交付平臺是一個非常強大的平臺，專門用于協調建立信任的步驟。就像在任何實驗中一樣，混沌工程的一個支柱是有一個基線。想象一下，您是一個團隊的新手，例如 SRE 團隊，該團隊涵蓋了數十個不是您自己編寫的應用程序。首次運行混沌工程測試將需要隔離或啟動應用程序和相關基礎設施的新發行版，以進行試驗，而不會對生產產生影響。

如果您的應用程序不是通過強大的管道部署的，那么創建另一個隔離部署可能與正常部署應用程序的正常潮起潮落一樣痛苦。沿著混沌工程成熟之旅前進，因為混沌工程測試被視為強制覆蓋，按照慣例，將它們集成到用于判斷調用或故障策略的 Harness 工作流中很簡單。

本文：什么是混沌工程？ 介紹、定義及更多

總結

以上是生活随笔為你收集整理的【混沌工程】什么是混沌工程？ 介绍、定义及更多的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。