本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 附錄 A ‒ 混沌工程的目標類型
<a name="appendix-a"></a>

以下目標類型的描述包括 Amazon 和其他組織如何設計混沌工程目標的實際範例。

## 彈性架構目標
<a name="resilient-architecture"></a>

採用混沌工程的初始驅動因素之一是識別和減少跨系統和基礎設施的單點故障 (SPOF)。目標設定為驗證關鍵系統和架構的彈性，特別是新服務或應用程式。

彈性架構目標涉及執行混沌實驗，以模擬服務相依性的失敗。實驗會確認逾時、重試、快取行為和斷路器組態是否正常運作。這些實驗有助於發現修復問題，防止影響客戶的事件。如需範例，請參閱[使用混沌工程在 Prime Video 中建置彈性服務](https://aws.amazon.com/blogs/opensource/building-resilient-services-at-prime-video-with-chaos-engineering/)。

## 服務復原目標
<a name="service-recovery"></a>

服務復原目標著重於改善從營運中斷或基礎設施故障復原的能力。例如，您的組織可能旨在在發生中斷時，為您的核心服務實現特定的復原時間目標 (RTO)。團隊可以設計混沌實驗，以驗證和最佳化疏散策略、容錯移轉機制和自動化復原程序。最佳化最終會減少服務還原所需的時間。如需範例，請參閱 [AWS Lambda：under-the-hood的恢復能力](https://aws.amazon.com/blogs/compute/aws-lambda-resilience-under-the-hood/)。

## 使用者體驗目標
<a name="ux"></a>

維持一致且可靠的使用者體驗至關重要，特別是在高流量期間或關鍵事件期間。在這種情況下，設定以特定服務層級目標 (SLOs) 為中心的目標。這種以客戶為中心的方法可確保彈性工作直接與提供卓越的使用者體驗保持一致，即使在遇到故障或條件降低的情況下也是如此。如需範例，請參閱[工程彈性：Amazon Search 的混沌工程之旅中的課程](https://community.aws/posts/amazon-search-chaos-engineering-journey)。

## 指標驅動的目標
<a name="metrics"></a>

您可以根據量化指標建立目標，例如彈性分數，該分數的計算方式為將點授予採用經驗證的彈性最佳實務的服務。然後，您可以使用特定的混沌實驗來判斷彈性分數。此分數可以做為衡量團隊在緩解已知可用性風險以及實作建議彈性衡量指標方面追蹤進度的衡量標準。不過，請務必謹慎解譯此類分數，並避免過度強調單一指標，而犧牲更廣泛的彈性目標。如需範例，請參閱[了解彈性分數](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resil-score.html)。

## 法規合規目標
<a name="compliance"></a>

金融服務業已成為接受混沌工程的先鋒，主要是由要求強大彈性的嚴格法規要求所推動。法規將要求金融機構主動識別、測試和修復其關鍵系統和程序中的漏洞。這些法規包括下列項目：
+ 強化美國聯邦機構所發行之營運恢復能力的健全運作實務相關文章
+ 歐洲中央銀行的營運彈性指導方針
+ 歐盟委員會提出的數位營運彈性法案 (DORA) 提案

如果您的組織是金融機構，請設定透過全面測試和驗證策略展現營運彈性的明確目標，以遵守這些法規。如需範例，請參閱 [London Stock Exchange Group 在 上使用混沌工程 AWS 來改善彈性](https://aws.amazon.com/blogs/architecture/london-stock-exchange-group-uses-chaos-engineering-on-aws-to-improve-resilience/)。