本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 附录 A-混沌工程的目标类型
<a name="appendix-a"></a>

以下对目标类型的描述包括亚马逊和其他组织如何为混沌工程设计目标的真实示例。

## 弹性架构目标
<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）的提案

如果您的组织是一家金融机构，请通过制定明确的目标，通过全面的测试和验证策略来证明运营弹性，从而遵守这些法规。例如，参见[伦敦证券交易所集团利用混沌工程 AWS 来提高弹性](https://aws.amazon.com/blogs/architecture/london-stock-exchange-group-uses-chaos-engineering-on-aws-to-improve-resilience/)。