本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 混沌工程入門
在進行實驗之前，我們建議您備妥一些基本知識，以充分利用您的混沌工程實務。這些基本概念包括：
+ 可觀測性 （指標、記錄、請求追蹤）
+ 您想要探索的實際事件或故障清單
+ 透過領導層接受的組織彈性贊助
+ 根據潛在業務影響，優先考慮關鍵調查結果，而不是執行混沌實驗時發現的新功能
## 混沌實驗的可觀測性
可觀測性包含指標、記錄和請求追蹤，在混沌工程中扮演重要角色。當您執行實驗時，您會想要了解業務指標、伺服器端指標、用戶端體驗指標和操作指標。如果沒有可觀測性，您將無法定義穩定狀態行為或建立有意義的實驗，以驗證您對應用程式的假設是否成立。
### 指標
下圖顯示您可以針對不同類型的應用程式追蹤混沌實驗的指標類型。
+ **業務指標** – *穩定狀態*表示系統的正常操作，並由您的業務指標定義。它可以由每秒交易 (TPS)、每秒點擊串流、每秒訂單或類似的測量來表示。您的應用程式在如預期般運作時會顯示穩定狀態。因此，請先確認您的應用程式運作狀態良好，再執行實驗。穩定狀態不一定表示發生故障時不會影響應用程式，因為一定百分比的故障可能落在可接受的限制內。穩定狀態是您的基準。例如，付款系統的穩定狀態可能定義為處理 300 TPS，成功率為 99%，往返時間為 500 毫秒。從視覺上來說，請將穩定狀態視為心電圖 (EKG)。如果系統的穩定狀態突然波動，您知道您的服務有問題。
+ **伺服器端指標** – 若要了解資源在實驗期間的效能，您需要在實驗之前、期間和之後深入了解其效能。若要測量資源對 的影響 AWS，您可以使用 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)。CloudWatch 是一項服務，可監控應用程式、回應效能變更、最佳化資源使用，以及提供營運運作狀態的洞見。在實驗期間，您會想要擷取伺服器端指標，例如飽和度、請求磁碟區、錯誤率和延遲。
+ **客戶體驗指標** – 在 上 AWS，您可以使用 [CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 透過 Locust、Grafana k6、Selenium 或 Puppeteer 等工具來模擬使用者請求，以擷取真實的使用者指標。實際使用者指標對於執行混沌工程實驗的組織至關重要。透過監控實際使用者在實驗期間受到的影響，團隊可以準確了解故障和中斷如何影響生產中的客戶。主要用戶端體驗指標為首次位元組時間 (TTFB)、最大有內容的顏料 (LCP)、下一個顏料的互動 (INP) 和總封鎖時間 (TBT)。
+ **操作指標** – 介入會測量您以自動化方式成功緩解故障的程度，例如，在重新啟動 Pod、任務或 EC2 執行個體時，透過複寫控制器或自動擴展等機制，成功降低用戶端請求延遲。能夠在故障期間自動介入，與良好的使用者體驗直接相關。了解隨著時間的推移，這些緩解機制是否有任何偏離至關重要。透過定義成功和失敗自動化緩解措施的指標，您可以建立指南，以協助識別整個系統的潛在迴歸。
### 日誌
集中式記錄是了解應用程式元件在混沌實驗之前、期間和之後的狀態的關鍵。我們建議您從所有應用程式元件收集日誌，以建立每個元件在注入實驗時正在執行的操作的合併檢視。這提供end-to-end實驗流程的清晰影像。
### 請求追蹤
請求追蹤可讓您觀察應用程式中元件之間任何單一請求的流程，以全面了解注入失敗對系統及其相依性的影響。透過追蹤請求，您可以查看故障如何傳播到不同的服務和元件，以便更好地評估中斷的範圍。若要追蹤 上的請求 AWS，您可以使用 [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)。
## 注入混沌實驗的失敗案例
將常見故障注入您的應用程式的目的是了解應用程式對這些意外事件的反應，以便您可以建立緩解機制並讓系統對此類故障具有彈性。此外，您應該使用混沌工程來重播歷史故障案例，以確認您的緩解機制仍然如預期運作，並且不會隨著時間而偏離。
當您規劃混沌工程實驗時，請考慮下列事件。
| 失敗模式 | Description |
| --- | --- |
| 伺服器受損 | 重新啟動 EC2 執行個體、刪除 Kubernetes Pod 或 Amazon Elastic Container Service (Amazon ECS) 任務，以了解應用程式對此類當機的反應。 |
| API 錯誤 | 將錯誤注入 AWS 和您自己的服務 APIs，以了解應用程式行為。 |
| 網路問題 | 引入延遲或擁塞，或封鎖連線以模擬真實世界的網路問題。 |
| AWS 可用區域受損 | 重播整個可用區域的損害，以驗證跨區域的復原。 |
| AWS 區域 連線受損 | 重播網路中斷 AWS 區域 ，以驗證次要區域中的資源如何對此類事件做出反應。 |
| 資料庫失敗 | 容錯移轉資料庫複本或損毀的資料，或使資料庫執行個體無法連線，以了解對應用程式和復原策略的影響。 |
| 在資料庫和 Amazon S3 複寫中暫停 | 暫停資料庫或跨可用區域的 Amazon Simple Storage Service (Amazon S3) 複寫 AWS 區域 ，或了解下游應用程式的影響。 |
| 儲存體降級 | 暫停 I/O、移除 Amazon Elastic Block Store (Amazon EBS) 磁碟區或刪除檔案，以驗證資料耐久性和復原。 |
| 相依性受損 | 降低或降低您依賴的下游或上游服務的效能，包括第三方服務，以了解end-to-end流程和對客戶的影響。 |
| 流量突增 | 在使用者流量中產生峰值，以測試自動擴展功能，並查看冷開機時間如何影響您的整體應用程式狀態。 |
| 資源耗盡 | 將 CPU、記憶體和磁碟空間最大化，以驗證應用程式的正常降級。 |
| 串聯失敗 | 啟動層疊到下游應用程式和元件的主要故障。 |
| 部署錯誤 | 推出有問題的變更或組態，以驗證轉返機制。 |
## 組織彈性贊助
混沌工程會在整個組織套用時提供最大的價值。我們建議您與執行發起人合作，他們可協助設定整個組織的彈性目標、消除對網域的恐懼、不確定性和懷疑，並啟動轉型程序，讓彈性成為每個人的責任。
為了支援建立混沌工程實務的業務案例，請將混沌工程工作連接至您的關鍵業務專案。讓彈性成為加速的資產和驅動因素，可協助您追蹤隨著時間的成功。從每月或每季的關鍵事件計數、平均復原時間，以及這些事件對客戶和組織造成的影響開始。與您的團隊設定目標，以減少 6 到 12 個月期間的事件數量，因為在應用程式堆疊之間進行改善以回應混沌工程實驗。
測量事件是否具有高度重複性。例如，假設過期的 TLS 憑證會導致停機時間，因為用戶端無法建立信任的連線。如果由於多個 TLS 憑證過期而在一年內發生多個事件，您可以執行 TLS 憑證過期的實驗，並確認您的團隊收到提醒或能夠自動緩解此類問題。這將有助於確保您對此類故障具有彈性。
若要追蹤一段時間內的混沌工程進度，請擷取下列指標，以協助強調應用程式生命週期中的混沌工程值：
+ **降低事件率** – 追蹤一段時間內的生產事件數量，並將此數量與採用混沌工程相互關聯。預期嚴重事件的速率將下降。
+ **改善平均解決時間 (MTTR)** – 計算解決事件和追蹤此資料所需的平均時間，以查看隨著時間的推移，是否因混沌工程而改善。
+ **提高應用程式可用性** – 使用服務層級指標來顯示應用程式彈性透過混沌實驗提高時的可用性改善。
+ **更快的上市時間** – Chaos 工程可以提供信心，讓您更快地推出創新產品，因為您知道應用程式具有彈性。追蹤產品發行速度的增加。
+ **降低營運成本** – 量化警示噪音、營運負載和手動管理應用程式等指標是否隨著實施混亂實務而減少。
+ **提高信心** – 調查開發人員、站點可靠性工程師 (SREs) 和其他技術人員，以評估混沌工程是否提高他們對應用程式彈性的信心。感知很重要。
+ **改善客戶體驗** ‒ 將混沌工程與客戶正面成果連線，例如減少服務中斷、轉返和中斷。
## 排定修復的優先順序
當您執行混沌實驗時，您可能會找出應用程式未如預期般執行的待改進領域。這類項目的修復會在您的待處理項目中運作，必須與其他工作一起排定優先順序，例如功能開發。我們建議您花時間進行這些增強功能，以避免未來失敗。考慮根據這些學習和修復任務可能造成的影響程度來排定這些學習和修復任務的優先順序。直接影響應用程式彈性或安全性的問題清單應優先於新功能，以避免客戶受到影響。如果團隊在特徵開發上難以排定補救措施的優先順序，請考慮聯絡您的執行發起人，以確保根據業務風險承受能力設定優先順序。