軟件和系統(tǒng)開發(fā)是創(chuàng)新和解決未知問題的練習(xí)。軟件和系統(tǒng)是容易出錯的，因?yàn)樗鼈兪怯删哂胁煌^點(diǎn)和技能的人（很可能是多人）制作的。技術(shù)變得越來越分散和復(fù)雜，尤其是隨著微服務(wù)的推動。很少有人擁有完整的端到端知識 […]

軟件和系統(tǒng)開發(fā)是創(chuàng)新和解決未知問題的練習(xí)。軟件和系統(tǒng)是容易出錯的，因?yàn)樗鼈兪怯删哂胁煌^點(diǎn)和技能的人（很可能是多人）制作的。技術(shù)變得越來越分散和復(fù)雜，尤其是隨著微服務(wù)的推動。很少有人擁有整個系統(tǒng)的全部端到端知識。

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

混沌工程通過在整個應(yīng)用程序和基礎(chǔ)架構(gòu)堆棧中注入故障，然后允許工程師驗(yàn)證行為并進(jìn)行調(diào)整，從而使故障不會向用戶顯現(xiàn)，從而幫助解決未知問題。再加上站點(diǎn)可靠性工程實(shí)踐的興起，混沌工程試圖計(jì)算不可能的影響。

混沌史

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

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

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

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

什么是混沌工程？

混沌工程是故意將故障注入系統(tǒng)以衡量彈性的科學(xué)。與任何科學(xué)方法一樣，混沌工程專注于實(shí)驗(yàn)/假設(shè)，然后將結(jié)果與對照（穩(wěn)態(tài)）進(jìn)行比較。分布式系統(tǒng)中典型的混沌工程示例是關(guān)閉隨機(jī)服務(wù)，以查看項(xiàng)目如何響應(yīng)以及對用戶旅程的損害表現(xiàn)在哪些方面。

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

誰使用混沌工程？

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

根據(jù)應(yīng)用程序堆棧的領(lǐng)域（計(jì)算、網(wǎng)絡(luò)、存儲和應(yīng)用程序基礎(chǔ)架構(gòu)）以及目標(biāo)基礎(chǔ)架構(gòu)所在的位置，這些團(tuán)隊(duì)的利益相關(guān)者可以參與其中。

如果爆炸半徑很小并且可以在運(yùn)行的容器中進(jìn)行測試，那么應(yīng)用程序開發(fā)團(tuán)隊(duì)可以進(jìn)行測試，而不必?fù)?dān)心突破容器。如果工作負(fù)載或基礎(chǔ)設(shè)施的影響范圍更廣（例如，測試 Kubernetes 基礎(chǔ)設(shè)施），平臺工程團(tuán)隊(duì)很可能會參與其中。為未知提供覆蓋是運(yùn)行 Chaos 測試和尋找弱點(diǎn)的核心原因。

為什么要進(jìn)行混沌測試？

開發(fā)的迷霧是非常真實(shí)的，尤其是對于更大的分布式系統(tǒng)、復(fù)雜系統(tǒng)和微服務(wù)實(shí)現(xiàn)。從應(yīng)用程序的角度來看，每個單獨(dú)的微服務(wù)都可以單獨(dú)測試并確定按設(shè)計(jì)工作。正常的監(jiān)控技術(shù)可以認(rèn)為單個服務(wù)是健康的。

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

如果一項(xiàng)瑣碎或非瑣碎的服務(wù)或基礎(chǔ)設(shè)施在服務(wù)水平協(xié)議 (SLA) 范圍內(nèi)沒有響應(yīng)，系統(tǒng)的功能和用戶旅程將受到怎樣的影響？這正是混沌工程正在解決的問題。混沌工程實(shí)驗(yàn)的結(jié)果隨后被用于創(chuàng)建一個更具彈性的系統(tǒng)。

混沌工程原理

《混沌工程原理》是一篇出色的宣言，描述了混沌工程的主要目標(biāo)和原則?；煦绻こ淘磉M(jìn)一步分解了四種類似于科學(xué)方法的實(shí)踐。但是，與科學(xué)方法不同的是，假設(shè)系統(tǒng)是穩(wěn)定的，然后尋找方差。越難中斷穩(wěn)態(tài)，系統(tǒng)的信心和穩(wěn)健性就越高。

從定義基線開始（穩(wěn)態(tài)）

了解什么是正常/穩(wěn)定對于檢測偏差/回歸至關(guān)重要。根據(jù)您要測試的內(nèi)容，擁有一個良好的指標(biāo)，例如響應(yīng)時間或更高級別的目標(biāo)，例如在特定時間內(nèi)完成用戶旅程的能力，是衡量正常性的良好指標(biāo)。實(shí)驗(yàn)中的穩(wěn)態(tài)是對照組。

假設(shè)穩(wěn)態(tài)將持續(xù)

與科學(xué)方法背道而馳，假設(shè)一個假設(shè)一直都是真的不會留下太多的余地。混沌工程旨在針對強(qiáng)大而穩(wěn)定的系統(tǒng)運(yùn)行，試圖找出應(yīng)用程序故障或基礎(chǔ)設(shè)施故障等故障。對不穩(wěn)定的系統(tǒng)運(yùn)行混沌工程并沒有提供太多價(jià)值，因?yàn)檫@些系統(tǒng)已經(jīng)不可靠并且不穩(wěn)定性是已知的。

引入變量/實(shí)驗(yàn)

與任何科學(xué)實(shí)驗(yàn)一樣，混沌工程在實(shí)驗(yàn)中引入變量以查看系統(tǒng)如何響應(yīng)。這些實(shí)驗(yàn)代表了影響應(yīng)用程序四大支柱中的一個或多個的真實(shí)故障場景：計(jì)算、網(wǎng)絡(luò)、存儲和應(yīng)用程序基礎(chǔ)設(shè)施。例如，故障可能是硬件故障或網(wǎng)絡(luò)中斷。

嘗試反駁假設(shè)

如果假設(shè)是針對穩(wěn)態(tài)的，則穩(wěn)態(tài)的任何方差或中斷（對照組和實(shí)驗(yàn)組之間的差異）都反駁了穩(wěn)定性假設(shè)?，F(xiàn)在有了一個可以關(guān)注的領(lǐng)域，可以進(jìn)行修復(fù)或設(shè)計(jì)更改，以使系統(tǒng)更加健壯和穩(wěn)定。

在實(shí)施混沌工程實(shí)驗(yàn)時，實(shí)施混沌工程的原則會導(dǎo)致一些設(shè)計(jì)注意事項(xiàng)和最佳實(shí)踐。

混沌工程最佳實(shí)踐

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

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

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

在您的管道中連續(xù)運(yùn)行實(shí)驗(yàn)

軟件、系統(tǒng)和基礎(chǔ)設(shè)施確實(shí)會發(fā)生變化——每個人的狀況/健康狀況都可能會迅速發(fā)生變化。運(yùn)行實(shí)驗(yàn)的好地方是在 CI/CD 管道中。CI/CD 管道在進(jìn)行更改時執(zhí)行。衡量變革的潛在影響的最佳時機(jī)莫過于變革開始在管道中建立信心的旅程。

在生產(chǎn)中運(yùn)行實(shí)驗(yàn)

正如在生產(chǎn)中進(jìn)行測試的可怕想法一樣，生產(chǎn)是用戶所處的環(huán)境，流量峰值/負(fù)載是真實(shí)的。為了全面測試生產(chǎn)系統(tǒng)的穩(wěn)健性/彈性，在生產(chǎn)環(huán)境中運(yùn)行混沌工程實(shí)驗(yàn)將提供所需的見解。

最小化爆炸半徑

因?yàn)槟悴荒芤钥茖W(xué)的名義降低生產(chǎn)，所以限制混沌工程實(shí)驗(yàn)的爆炸半徑是一種負(fù)責(zé)任的做法。專注于小實(shí)驗(yàn)，這些實(shí)驗(yàn)會告訴你你想要識別什么。專注于范圍和測試。例如，兩個特定服務(wù)之間的網(wǎng)絡(luò)延遲。比賽日計(jì)劃可以幫助計(jì)算爆炸半徑和重點(diǎn)。

有了這些最佳實(shí)踐，混沌工程是一門不同于負(fù)載測試的學(xué)科。

混沌工程和負(fù)載測試有什么區(qū)別？

當(dāng)然，負(fù)載本身會帶來混亂。我們通常將我們的系統(tǒng)設(shè)計(jì)為在多個部分中具有彈性（啟動額外的計(jì)算、網(wǎng)絡(luò)、持久性和/或應(yīng)用程序節(jié)點(diǎn)以應(yīng)對負(fù)載）。那是假設(shè)一切都在同一/適當(dāng)?shù)臅r間出現(xiàn)，因此我們可以領(lǐng)先于負(fù)載。

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

負(fù)載測試肯定會幫助我們?yōu)槔坐Q群做準(zhǔn)備，這是一種壓力，但是如果系統(tǒng)的一部分甚至不存在，或者游戲遲到了怎么辦？這就是混沌工程的用武之地。如果沒有混沌工程，一個非常難以測試的項(xiàng)目將是級聯(lián)故障。歷史上更等同于電網(wǎng)，級聯(lián)故障是一個部分的故障可以觸發(fā)其他部分的故障。在分布式系統(tǒng)領(lǐng)域，這是我們試圖找到單點(diǎn)故障并確保我們的應(yīng)用程序/基礎(chǔ)設(shè)施足夠健壯以處理故障。

今天，不乏工具和平臺來幫助您實(shí)現(xiàn)混沌工程目標(biāo)。

混沌工程工具

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

混沌猴（Chaos Monkey）

Chaos Monkey 被公認(rèn)為最早的混沌工程工具之一，由 Netflix 開發(fā)。最初的 Chaos Monkey 會隨機(jī)禁用生產(chǎn)實(shí)例。最終，混沌猴成為了猿猴軍團(tuán)（Simian Army）的一員。盡管今天 Chaos Monkey 是一個獨(dú)立的項(xiàng)目。

四面軍(The Simian Army)

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

Gremlin 平臺（Gremlin Platform）

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

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

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

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

試驗(yàn)?zāi)?CI/CD 管道

隨著在系統(tǒng)中建立信心的新方法開始受到關(guān)注，CI/CD 管道是協(xié)調(diào)建立信心步驟的好地方?；煦绻こ虒?shí)驗(yàn)非常適合在 CI/CD 管道中運(yùn)行。最近，Harness 和 Gremlin 創(chuàng)建了一個演示，展示了 CI/CD 管道和 Gremlin Experiments 之間的集成。

可能的藝術(shù)是讓混沌工程實(shí)驗(yàn)的結(jié)果影響部署，或者如果部署到較低的環(huán)境，讓 Harness 作為混沌工程實(shí)驗(yàn)和其他自動化測試的協(xié)調(diào)器。如需完整示例，請前往 Harness 社區(qū)了解更多信息。

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

Harness 軟件交付平臺是一個非常強(qiáng)大的平臺，專門用于協(xié)調(diào)建立信任的步驟。就像在任何實(shí)驗(yàn)中一樣，混沌工程的一個支柱是有一個基線。想象一下，您是一個團(tuán)隊(duì)的新手，例如 SRE 團(tuán)隊(duì)，該團(tuán)隊(duì)涵蓋了數(shù)十個不是您自己編寫的應(yīng)用程序。首次運(yùn)行混沌工程測試將需要隔離或啟動應(yīng)用程序和相關(guān)基礎(chǔ)設(shè)施的新發(fā)行版，以進(jìn)行試驗(yàn)，而不會對生產(chǎn)產(chǎn)生影響。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。