混沌工程入門

可觀測性 （指標、記錄、請求追蹤）

您想要探索的實際事件或故障清單

透過領導層接受的組織彈性贊助

根據潛在業務影響，優先考慮關鍵調查結果，而不是執行混沌實驗時發現的新功能

業務指標 – 穩定狀態表示系統的正常操作，並由您的業務指標定義。它可以由每秒交易 (TPS)、每秒點擊串流、每秒訂單或類似的測量來表示。您的應用程式在如預期般運作時會顯示穩定狀態。因此，請先確認您的應用程式運作狀態良好，再執行實驗。穩定狀態不一定表示發生故障時不會影響應用程式，因為一定百分比的故障可能落在可接受的限制內。穩定狀態是您的基準。例如，付款系統的穩定狀態可能定義為處理 300 TPS，成功率為 99%，往返時間為 500 毫秒。從視覺上來說，請將穩定狀態視為心電圖 (EKG)。如果系統的穩定狀態突然波動，您知道您的服務有問題。

伺服器端指標 – 若要了解資源在實驗期間的效能，您需要在實驗之前、期間和之後深入了解其效能。若要測量資源對 的影響 AWS，您可以使用 Amazon CloudWatch。CloudWatch 是一項服務，可監控應用程式、回應效能變更、最佳化資源使用，以及提供營運運作狀態的洞見。在實驗期間，您會想要擷取伺服器端指標，例如飽和度、請求磁碟區、錯誤率和延遲。

客戶體驗指標 – 在 上 AWS，您可以使用 CloudWatch RUM 透過 Locust、Grafana k6、Selenium 或 Puppeteer 等工具來模擬使用者請求，以擷取真實的使用者指標。實際使用者指標對於執行混沌工程實驗的組織至關重要。透過監控實際使用者在實驗期間受到的影響，團隊可以準確了解故障和中斷如何影響生產中的客戶。主要用戶端體驗指標為首次位元組時間 (TTFB)、最大有內容的顏料 (LCP)、下一個顏料的互動 (INP) 和總封鎖時間 (TBT)。

操作指標 – 介入會測量您以自動化方式成功緩解故障的程度，例如，在重新啟動 Pod、任務或 EC2 執行個體時，透過複寫控制器或自動擴展等機制，成功降低用戶端請求延遲。能夠在故障期間自動介入，與良好的使用者體驗直接相關。了解隨著時間的推移，這些緩解機制是否有任何偏離至關重要。透過定義成功和失敗自動化緩解措施的指標，您可以建立指南，以協助識別整個系統的潛在迴歸。

降低事件率 – 追蹤一段時間內的生產事件數量，並將此數量與採用混沌工程相互關聯。預期嚴重事件的速率將下降。

改善平均解決時間 (MTTR) – 計算解決事件和追蹤此資料所需的平均時間，以查看隨著時間的推移，是否因混沌工程而改善。

提高應用程式可用性 – 使用服務層級指標來顯示應用程式彈性透過混沌實驗提高時的可用性改善。

更快的上市時間 – Chaos 工程可以提供信心，讓您更快地推出創新產品，因為您知道應用程式具有彈性。追蹤產品發行速度的增加。

降低營運成本 – 量化警示噪音、營運負載和手動管理應用程式等指標是否隨著實施混亂實務而減少。

提高信心 – 調查開發人員、站點可靠性工程師 (SREs) 和其他技術人員，以評估混沌工程是否提高他們對應用程式彈性的信心。感知很重要。

改善客戶體驗 ‒ 將混沌工程與客戶正面成果連線，例如減少服務中斷、轉返和中斷。