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

我第一次開始實踐這門學(xué)科，早在它有名字之前幾年，在亞馬遜，我們的工作就是防止零售網(wǎng)站宕機(jī)。當(dāng)我們?nèi)〉贸晒r，Netflix 寫了他們關(guān)于 Chaos Monkey 的規(guī)范博客文章（十年前的今年 7 月）。這個想法成為主流，許多工程師都被迷住了。在亞馬遜完成任務(wù)后，我急忙加入 Netflix，深入研究這個領(lǐng)域。我們能夠進(jìn)一步推動藝術(shù)發(fā)展，構(gòu)建跨越整個 Netflix 生態(tài)系統(tǒng)的以開發(fā)人員為中心的解決方案，最終帶來另外 9 個可用性和世界知名的客戶體驗。

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

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

主要發(fā)現(xiàn)

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

• 經(jīng)常進(jìn)行混沌工程實驗的團(tuán)隊有 >99.9% 的可用性

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

• 網(wǎng)絡(luò)攻擊是最常運(yùn)行的實驗，與報告的主要故障一致

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

• 34% 的受訪者在生產(chǎn)環(huán)境中進(jìn)行混沌工程實驗

Things?break

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

您的服務(wù)的平均可用性是多少？

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

每月平均高嚴(yán)重性事件數(shù) (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%

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

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

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

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

誰知道

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

您使用什么指標(biāo)來定義可用性？

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

您如何監(jiān)控可用性？

監(jiān)控方式	占比
真實用戶監(jiān)控	37.1%
健康檢查/合成	64.4%
服務(wù)器端響應(yīng)	50.4%

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

誰監(jiān)控或接收可用性報告？

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%

誰監(jiān)控或接收性能報告？

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%

最好表現(xiàn)者

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

始終進(jìn)行混沌實驗的團(tuán)隊比從未進(jìn)行過實驗或臨時進(jìn)行實驗的團(tuán)隊具有更高的可用性水平。 但 ad-hoc 實驗是實踐的重要組成部分，可用性 > 99.9% 的團(tuán)隊正在執(zhí)行更多的 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 引入他們的系統(tǒng)。 這種節(jié)點(diǎn)的偽隨機(jī)故障是對實例和服務(wù)器隨機(jī)故障的響應(yīng)。 Netflix 希望團(tuán)隊為這些故障模式做好準(zhǔn)備，因此他們加快了流程，要求對實例中斷具有彈性。 它創(chuàng)建了對可靠性機(jī)制的測試，并迫使開發(fā)人員在構(gòu)建時考慮到失敗。 基于該項目的成功，Netflix 開源了 Chaos Monkey，并創(chuàng)建了 Chaos Engineer 角色。 從那時起，混沌工程已經(jīng)發(fā)展到遵循科學(xué)過程，并且實驗已經(jīng)擴(kuò)展到主機(jī)故障之外，以測試堆棧上下的故障。

谷歌搜索“混沌工程”

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

對于失敗中花費(fèi)的每一美元，學(xué)習(xí)一美元的教訓(xùn)

-----“MASTER OF DISASTER”

------JESSE ROBBINS

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

Chaos Engineering?today

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

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

68% 的客戶使用 K8S 攻擊

您的組織多久練習(xí)一次混沌工程？

	每日或更頻繁的攻擊	每周攻擊	每月攻擊	每季度攻擊	執(zhí)行臨時攻擊	從未進(jìn)行過攻擊
>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%

哪些團(tuán)隊參與了混沌實驗？

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%

你在什么環(huán)境下進(jìn)行過混沌實驗？

Dev/Test	63%
Staging	50%
Production	34%

按類型劃分的攻擊百分比

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

按目標(biāo)類型劃分的攻擊百分比

Host	70%
Container	29%
Application	1%

混沌實驗結(jié)果

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

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

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

混沌工程的未來

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

缺乏認(rèn)識	20%
其他優(yōu)先事項	20%
缺乏經(jīng)驗	20%
時間不夠	17%
安全問題	12%
害怕出事	11%

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

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

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

人口統(tǒng)計

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

該調(diào)查強(qiáng)調(diào)了云計算的一個轉(zhuǎn)折點(diǎn)，近 60% 的受訪者在云中運(yùn)行大部分工作負(fù)載，并使用 CI/CD 管道。 容器和 Kubernetes 正在達(dá)到類似的成熟度，但調(diào)查證實服務(wù)網(wǎng)格仍處于早期階段。 最常見的云平臺是 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%

貴公司屬于哪個行業(yè)？

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%

云中占生產(chǎn)工作負(fù)載的百分比是多少？

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

使用 CI/CD 管道部署的生產(chǎn)工作負(fù)載的百分比是多少？

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

百分之幾的生產(chǎn)工作負(fù)載使用容器？

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

百分之幾的生產(chǎn)工作負(fù)載使用 Kubernetes（或其他容器編排器）？

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

百分之多少的生產(chǎn)環(huán)境路由利用了服務(wù)網(wǎng)格？

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

除了檢查調(diào)查結(jié)果外，我們還匯總了有關(guān) Gremlin 用戶技術(shù)環(huán)境的信息，以了解哪些特定工具和堆棧層最常成為混沌工程實驗的目標(biāo)。 這些發(fā)現(xiàn)如下。

您的云提供商是什么？

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%

你的監(jiān)控工具是什么？

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

你的數(shù)據(jù)庫是什么？

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

貢獻(xiàn)者

Dynatrace

Dynatrace 提供軟件智能以簡化云復(fù)雜性并加速數(shù)字化轉(zhuǎn)型。 借助自動和智能的大規(guī)模可觀察性，我們的一體化平臺可提供有關(guān)應(yīng)用程序性能和安全性、底層基礎(chǔ)架構(gòu)以及所有用戶體驗的準(zhǔn)確答案，使組織能夠更快地創(chuàng)新、更有效地協(xié)作并交付更多 以更少的努力獲得價值。

Epsagon

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

Grafana Labs

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

LaunchDarkly

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

PagerDuty

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

本文：2022 混沌工程狀態(tài)

總結(jié)

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

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