在過去的十二年里，我有機會參與并見證了混沌工程的發展。出身卑微，最常遇到的問題是“你為什么要這樣做？”到今天的位置，幫助確保世界頂級公司的可靠性，這是一段相當長的旅程。

我第一次開始實踐這門學科，早在它有名字之前幾年，在亞馬遜，我們的工作就是防止零售網站宕機。當我們取得成功時，Netflix 寫了他們關于 Chaos Monkey 的規范博客文章（十年前的今年 7 月）。這個想法成為主流，許多工程師都被迷住了。在亞馬遜完成任務后，我急忙加入 Netflix，深入研究這個領域。我們能夠進一步推動藝術發展，構建跨越整個 Netflix 生態系統的以開發人員為中心的解決方案，最終帶來另外 9 個可用性和世界知名的客戶體驗。

五年前，我的聯合創始人 Matthew Fornaciari 和我創立了 Gremlin，其使命很簡單：建立更可靠的互聯網。我們都欣喜若狂地看到這次實踐已經走了多遠。社區中的許多人都渴望獲得更多關于如何最好地利用這種方法的數據，因此我們很自豪地展示了第一份混沌工程狀態報告。

全球的工程團隊使用 Chaos Engineering 故意將危害注入他們的系統、監控影響并修復故障，以免對客戶體驗產生負面影響。這樣做，他們避免了代價高昂的停機，同時減少了 MTTD 和 MTTR，讓他們的團隊為未知做好準備，并保護客戶體驗。事實上，Gartner 預計，到 2023 年，將混沌工程實踐作為 SRE 計劃一部分的 80% 的組織將其平均解決時間 (MTTR) 減少 90%。我們從首份混沌工程狀態報告中看到了同樣的相似之處：表現最好的混沌工程團隊擁有四個 9 的可用性，MTTR 不到一小時。

主要發現

• 增加可用性和減少 MTTR 是混沌工程最常見的兩個好處

• 經常進行混沌工程實驗的團隊有 >99.9% 的可用性

• 23% 的團隊的平均解決時間 (MTTR) 不到 1 小時，60% 的團隊不到 12 小時

• 網絡攻擊是最常運行的實驗，與報告的主要故障一致

• 雖然仍然是一種新興實踐，但大多數受訪者 (60%) 至少運行過一次混沌工程攻擊

• 34% 的受訪者在生產環境中進行混沌工程實驗

Things?break

調查顯示，前 20% 的受訪者擁有超過四個 9 的服務，這是一個令人印象深刻的水平。 23% 的團隊的平均解決時間 (MTTR) 不到 1 小時，60% 的團隊平均解決時間 (MTTR) 不到 12 小時。

您的服務的平均可用性是多少？

	可靠性	占比
	<=99%	42.5%
	99.5%-99.9%	38.1%
	>=99.99%	19.4%

每月平均高嚴重性事件數 (Sev 0 和 1)

	1-10	81.4%
	10-20	18.6%

您的平均解決時間 (MTTR) 是多少？

MTTR	占比
<1 hour	23.1%
1 hour - 12 hours	39.8%
12 hours - 1 day	15.5%
1 day - 1 week	15.2%
> 1 week	0.5%
I don't know	5.9%

我們所做的其中一項更有益的事情是每天進行紅色與藍色攻擊。 我們讓平臺團隊介入，對我們和我們的服務進行攻擊，并將其視為真實的生產事件，通過響應并查看我們所有的運行手冊并確保我們被覆蓋。

當事情確實發生時，最常見的原因是錯誤的代碼推送和依賴問題。 這些不是相互排斥的。 來自一個團隊的錯誤代碼推送可能會導致另一個團隊的服務中斷。 在團隊擁有獨立服務的現代系統中，測試所有服務的故障恢復能力非常重要。 運行基于網絡的混沌實驗，例如延遲和黑洞，確保系統解耦并且可以獨立失敗，從而最大限度地減少服務中斷的影響。

您的事件 (SEV0 和 1) 的百分比是由以下原因引起的：

	<20%	21-40%	41-60%	61-80%	>80%
錯誤的代碼部署（例如，部署到生產環境的代碼中的錯誤導致事件）	39%	24%	19%	11.8%	6.1%
內部依賴問題（非 DB）（例如，貴公司運營的服務中斷）	41%	25%	20%	10.1%	3.7%
配置錯誤（例如，云基礎設施或容器編排器中的錯誤設置導致事件）	48%	23%	14%	10.1%	5.2%
網絡問題（例如，ISP 或 DNS 中斷）	50%	19%	13%	15.7%	1.7%
第 3 方依賴問題（非 DB）（例如，與支付處理器的連接斷開）	48%	23%	13%	14.3%	1.7%
托管服務提供商問題（例如，云提供商 AZ 中斷）	61%	14%	9%	12.5%	3.9%
機器/基礎設施故障（本地）（例如，停電）	64%	14%	6%	12%	4.4%
數據庫、消息傳遞或緩存問題（例如，導致事件的數據庫節點丟失）	58%	18%	18%	5.2%	1.2%
未知	66%	10%	15%	7.4%	1%

誰知道

可用性監控因公司而異。例如，Netflix 的流量非常穩定，他們可以使用服務器端每秒的視頻啟動次數來發現中斷。與預測模式的任何偏差都表示中斷。 Google 將真實用戶監控與窗口結合使用來確定單個中斷是否會產生重大影響，或者多個小事件是否會影響服務，從而對事件的原因進行更深入的分析。很少有公司像 Netflix 和 Google 那樣擁有一致的流量模式和復雜的統計模型。這就是為什么使用綜合監控的標準正常運行時間作為監控服務正常運行時間的最流行方法位于頂部，而許多組織使用多種方法和指標。我們驚喜地發現所有受訪者都在監控可用性。這通常是團隊為積極改善應用程序中的客戶體驗而采取的第一步。

您使用什么指標來定義可用性？

可用性指標	占比
錯誤率（失敗請求/總請求）	47.9%
延遲	38.3%
訂單/交易與歷史預測	21.6%
成功請求/總請求	44%
正常運行時間/總時間段	53.3%

您如何監控可用性？

監控方式	占比
真實用戶監控	37.1%
健康檢查/合成	64.4%
服務器端響應	50.4%

在查看誰收到有關可用性和性能的報告時，人們越接近操作應用程序，他們收到報告的可能性就越大也就不足為奇了。 我們相信，隨著構建和運營的思維方式在組織中變得普遍，DevOps 將運維和開發緊密結合在一起的趨勢是使開發人員與運維保持一致。 我們還相信，隨著數字化程度的提高和在線用戶體驗變得更加重要，我們將看到接收可用性和績效報告的 C 級員工的百分比增加。

誰監控或接收可用性報告？

CEO	15.7%
CFO or VP of Finance	11.8%
CTO	33.7%
VP	30.2%
Managers	51.1%
Ops	61.4%
Developers	54.5%
Other	1.2%

誰監控或接收性能報告？

CEO	12%
CFO or VP of Finance	10.6%
CTO	36.1%
VP	28.3%
Managers	51.8%
Ops	53.8%
Developers	54.1%
Other	2%

最好表現者

表現最好的人有 99.99% 以上的可用性和不到一小時的 MTTR（上面突出顯示）。 為了獲得這些令人印象深刻的數字，我們調查了團隊使用的工具。 值得注意的是，自動縮放、負載平衡器、備份、部署的選擇推出以及通過運行狀況檢查進行監控在頂級可用性組中更為常見。 其中一些，例如多區域，是昂貴的，而其他的，例如斷路器和選擇推出，是時間和工程專業知識的問題。

始終進行混沌實驗的團隊比從未進行過實驗或臨時進行實驗的團隊具有更高的可用性水平。 但 ad-hoc 實驗是實踐的重要組成部分，可用性 > 99.9% 的團隊正在執行更多的 ad-hoc 實驗。

混沌工程實驗的頻率（按可用性）

	Never performed an attack	Performed ad-hoc attacks	Quarterly attacks	Monthly attacks	Weekly attacks	Daily or more frequent attacks
>99.9%	25.7%	28.4%	16.2%	6.8%	17.6%	5.4%
99%-99.9%%	35.7%	25%	11.6%	10.3%	8.5%	8.9%
<99%%	49.4%	18.1%	13.3%	8.4%	8.4%	2.4%

按可用性使用工具

	>99.9%	99%-99.9%	<99%
Autoscaling	65%	52%	43%
DNS failover/elastic IPs	49%	33%	24%
Load balancers	77%	64%	71%
Active-active multi-region, AZ or DC	38%	29%	19%
Active-passive multi-region, AZ, or DC	45%	34%	30%
Circuit breakers	32%	22%	16%
Backups	61%	46%	51%
DB replication	51%	47%	37%
Retry logic	41%	33%	31%
Select rollouts of deployments (Blue/Green, Canary, feature flags)	51%	36%	27%
Cached static pages when dynamic unavailable	26%	26%	19%
Monitoring with health checks	70%	58%	53%

混沌工程的演變

2010 年，Netflix 將 Chaos Monkey 引入他們的系統。 這種節點的偽隨機故障是對實例和服務器隨機故障的響應。 Netflix 希望團隊為這些故障模式做好準備，因此他們加快了流程，要求對實例中斷具有彈性。 它創建了對可靠性機制的測試，并迫使開發人員在構建時考慮到失敗。 基于該項目的成功，Netflix 開源了 Chaos Monkey，并創建了 Chaos Engineer 角色。 從那時起，混沌工程已經發展到遵循科學過程，并且實驗已經擴展到主機故障之外，以測試堆棧上下的故障。

谷歌搜索“混沌工程”

年份	搜索次數
2016	1290
2017	6990
2018	19100
2019	24800
2020	31317

對于失敗中花費的每一美元，學習一美元的教訓

-----“MASTER OF DISASTER”

------JESSE ROBBINS

2020 年，混沌工程成為主流，并成為 Politico 和彭博社的頭條新聞。 Gremlin 舉辦了有史以來規模最大的混沌工程活動，有超過 3,500 名注冊者。 Github 擁有超過 200 個混沌工程相關項目，擁有 16K+ 星。 最近，AWS 宣布他們自己的公開混沌工程產品 AWS 故障注入模擬器將于今年晚些時候推出。

Chaos Engineering?today

混沌工程正變得越來越流行和改進：60% 的受訪者表示他們已經運行過混沌工程攻擊。 Chaos Engineering 的創建者 Netflix 和 Amazon 是尖端的大型組織，但我們也看到更成熟的組織和較小的團隊采用。 使用混沌工程的團隊的多樣性也在增長。 最初的工程實踐很快被站點可靠性工程 (SRE) 團隊采用，現在許多平臺、基礎設施、運營和應用程序開發團隊正在采用這種實踐來提高其應用程序的可靠性。 主機故障，我們歸類為狀態類型攻擊，遠不如網絡和資源攻擊流行。 我們已經看到了模擬與依賴項的丟失連接或對服務的需求激增的情況。 我們還看到更多的組織將他們的實驗轉移到生產中，盡管這還處于早期階段。

使用 Gremlin 平臺的 459,548 次攻擊

68% 的客戶使用 K8S 攻擊

您的組織多久練習一次混沌工程？

	每日或更頻繁的攻擊	每周攻擊	每月攻擊	每季度攻擊	執行臨時攻擊	從未進行過攻擊
>10,000員工	5.7%	8%	4.6%	16.1%	31%	34.5%
5,001-10,000 員工	0%	13.2%	18.4%	21.1%	23.7%	23.7%
1,001-5,000 員工	8.3%	11.1%	8.3%	9.7%	22.2%	40.3%
100-1,000 員工	10.9%	10.9%	8.6%	10.9%	22.7%	35.9%
<100 員工	3.7%	7.3%	9.8%	8.5%	15.9%	54.9%

哪些團隊參與了混沌實驗？

Application Developers	52%
C-level	10%
Infrastructure	42%
Managers	32%
Operations	49%
Platform or Architecture	37%
SRE	50%
VPs	14%

您的組織中有多少百分比使用混沌工程？

	百分比
76%+	7.3%
51-75%	17.7%
26-50%	21%
<25%	54%

你在什么環境下進行過混沌實驗？

Dev/Test	63%
Staging	50%
Production	34%

按類型劃分的攻擊百分比

Network	46%
Resource	38%
State	15%
Application	1%

按目標類型劃分的攻擊百分比

Host	70%
Container	29%
Application	1%

混沌實驗結果

混沌工程最令人興奮和最有價值的方面之一是發現或驗證錯誤。 這種做法可以更容易地在未知問題影響客戶之前發現它們并確定事件的真正原因，從而加快修補過程。 對我們調查的回復中顯示的另一個主要好處是更好地理解架構。 運行混沌實驗有助于識別對我們的應用程序產生不利影響的緊密耦合或未知依賴關系，并且通常會消除創建微服務應用程序的許多好處。 從我們自己的產品中，我們發現客戶經常發現事件、緩解問題并使用 Chaos Engineering 驗證修復。 我們的調查受訪者經常發現他們的應用程序在減少 MTTR 的同時提高了可用性。

使用混沌工程后，你體驗到了什么好處？

提高可用性	47%
縮短平均解決時間 (MTTR) mean time to resolution	45%
縮短平均檢測時間 (MTTD) mean time to detection	41%
減少了交付到生產環境的錯誤數量	38%
減少中斷次數	37%
減少頁面數	25%

混沌工程的未來

采用/擴展混沌工程的最大障礙是什么？

缺乏認識	20%
其他優先事項	20%
缺乏經驗	20%
時間不夠	17%
安全問題	12%
害怕出事	11%

采用混沌工程的最大障礙是缺乏意識和經驗。緊隨其后的是“其他優先事項”，但有趣的是，超過 10% 的人提到擔心可能出現問題也是一個禁忌。確實，在實踐混沌工程時，我們正在將故障注入系統，但使用遵循科學原理的現代方法，并有條不紊地將實驗隔離到單一服務中，我們可以有意識地實踐而不破壞客戶體驗。

我們相信混沌工程的下一階段涉及向更廣泛的受眾開放這一重要的測試過程，并使其更容易在更多環境中安全地進行實驗。隨著實踐的成熟和工具的發展，我們希望工程師和操作員能夠更容易和更快地設計和運行實驗，以提高其系統跨環境的可靠性——今天，30% 的受訪者正在生產中運行混沌實驗。我們相信，混沌實驗將變得更有針對性和自動化，同時也變得更加普遍和頻繁。

我們對混沌工程的未來及其在使系統更可靠方面的作用感到興奮。

人口統計

本報告的數據源包括一項包含 400 多個回復的綜合調查和 Gremlin 的產品數據。 調查受訪者來自各種規模和行業，主要是軟件和服務。 混沌工程的采用已經沖擊了企業，近 50% 的受訪者為員工人數超過 1,000 人的公司工作，近 20% 的受訪者為員工人數超過 10,000 人的公司工作。

該調查強調了云計算的一個轉折點，近 60% 的受訪者在云中運行大部分工作負載，并使用 CI/CD 管道。 容器和 Kubernetes 正在達到類似的成熟度，但調查證實服務網格仍處于早期階段。 最常見的云平臺是 AWS，占比接近 40%，GCP、Azure 和本地云平臺緊隨其后，占比約為 11-12%。

400 多名合格的受訪者

貴公司有多少員工？

>10,000	21.4%
5,001-10,000	9.3%
1,001-5,000	17.7%
100-1,000	31.4%
<100	20.1%

你的公司幾歲了？

Over 25 years old	25.8%
10 to 25 years old	32.9%
2 to 10 years old	27.3%
Less than 2 years old	14%

貴公司屬于哪個行業？

Software & Services	50.2%
Banks, Insurance & Financial Services	23.2%
Energy Equipment & Services	0.7%
Retail & eCommerce	18.3%
Technology Hardware, Semiconductors, & Related Equipment	7.6%

你的職位是什么？

Software Engineer	32.2%
SRE	25.3%
Engineering Manager	18.2%
System Administrator	8.8%
Non-technical Executive (ex: CEO, COO, CMO, CRO)	4.9%
Technical Executive (ex: CTO, CISO, CIO)	10.6%

云中占生產工作負載的百分比是多少？

>75%	35.1%
51-75%	23.1%
25-50%	21.4%
<25%	20.4%

使用 CI/CD 管道部署的生產工作負載的百分比是多少？

>75%	39.8%
51-75%	21.1%
25-50%	20.4%
<25%	18.7%

百分之幾的生產工作負載使用容器？

>75%	27.5%
51-75%	19.9%
25-50%	23.6%
<25%	29%

百分之幾的生產工作負載使用 Kubernetes（或其他容器編排器）？

>75%	19.4%
51-75%	22.4%
25-50%	18.4%
<25%	39.8%

百分之多少的生產環境路由利用了服務網格？

>75%	0.1%
51-75%	116.5%
25-50%	17.9%
<25%	55.5%

除了檢查調查結果外，我們還匯總了有關 Gremlin 用戶技術環境的信息，以了解哪些特定工具和堆棧層最常成為混沌工程實驗的目標。 這些發現如下。

您的云提供商是什么？

Amazon Web Services	38%
Google Cloud Platform	12%
Microsoft Azure	12%
Oracle	2%
Private Cloud (On Premises)	11%

你的容器編排器是什么？

Amazon Elastic Container Service	13%
Amazon Elastic Kubernetes Service	19%
Custom Kubernetes	16%
Google Kubernetes Engine	12%
OpenShift	6%

您的消息傳遞提供者（ messaging provider）是什么？

ActiveMQ	5%
AWS SQS	17%
Kafka	25%
IBM MQ	1%
RabbitMQ	13%

你的監控工具是什么？

Amazon CloudWatch	28%
Datadog	13%
Grafana	18%
New Relic	9%
Prometheus	18%

你的數據庫是什么？

Cassandra	5%
DynamoDb	14%
MongoDB	16%
MySQL	22%
Postgres	22%

貢獻者

Dynatrace

Dynatrace 提供軟件智能以簡化云復雜性并加速數字化轉型。 借助自動和智能的大規模可觀察性，我們的一體化平臺可提供有關應用程序性能和安全性、底層基礎架構以及所有用戶體驗的準確答案，使組織能夠更快地創新、更有效地協作并交付更多 以更少的努力獲得價值。

Epsagon

Epsagon 使團隊能夠立即可視化、理解和優化他們的微服務架構。 借助我們獨特的輕量級自動儀表，消除了與其他 APM 解決方案相關的數據和手動工作方面的空白，從而顯著減少了問題檢測、根本原因分析和解決時間。

Grafana Labs

Grafana Labs 提供了一個圍繞 Grafana 構建的開放且可組合的監控和可觀察性平臺，Grafana 是用于儀表板和可視化的領先開源技術。 超過 1,000 家客戶（如 Bloomberg、JP Morgan Chase、eBay、PayPal 和 Sony）使用 Grafana Labs，全球有超過 600,000 個 Grafana 活躍安裝。 商業產品包括 Grafana Cloud，一個集成了 Prometheus 和 Graphite（指標）的托管堆棧，Grafana Enterprise，一個具有企業功能、插件和支持的 Grafana 增強版； Loki（原木）和 Tempo（痕跡）與 Grafana； 和 Grafana Metrics Enterprise，它為大規模運行的大型組織提供 Prometheus 即服務。

LaunchDarkly

LaunchDarkly 由 Edith Harbaugh 和 John Kodumal 于 2014 年創立，是軟件團隊用來構建更好的軟件、更快、風險更低的功能管理平臺。 開發團隊使用功能管理作為將代碼部署與功能發布分開的最佳實踐。 使用 LaunchDarkly，團隊可以控制從概念到發布再到價值的整個功能生命周期。 每天為超過 1 萬億個功能標志提供服務，LaunchDarkly 被 Atlassian、Microsoft 和 CircleCI 的團隊使用。

PagerDuty

PagerDuty, Inc. (NYSE:PD) 是數字運營管理領域的領導者。 在一個永遠在線的世界中，各種規模的組織都信任 PagerDuty 可以幫助他們每次都為客戶提供完美的數字體驗。 團隊使用 PagerDuty 實時識別問題和機會，并召集合適的人員更快地解決問題并在未來預防問題。 知名客戶包括 GE、思科、基因泰克、藝電、Cox Automotive、Netflix、Shopify、Zoom、DoorDash、Lululemon 等。

本文：2022 混沌工程狀態

總結

以上是生活随笔為你收集整理的【混沌工程】2022 混沌工程状态的全部內容，希望文章能夠幫你解決所遇到的問題。

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