本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 混沌工程入门
在进行实验之前，我们建议您准备一些基本要素，以充分利用混沌工程实践。这些基本要素包括：
+ 可观察性（指标、日志、请求跟踪）
+ 你想探索的现实世界事件或故障清单
+ 通过领导力支持来赞助组织韧性
+ 根据潜在的业务影响，优先考虑关键发现，而不是在进行混沌实验时发现的新功能
## 混沌实验的可观察性
可观察性包括指标、日志记录和请求跟踪，在混沌工程中起着关键作用。在运行实验时，您需要了解业务指标、服务器端指标、客户体验指标和运营指标。如果没有可观测性，您将无法定义稳态行为或创建有意义的实验来验证您对应用程序的假设是否成立。
### 指标
下图显示了您可以针对不同类型的应用程序的混沌实验跟踪的指标类型。
+ **业务指标**-*稳定状态*表示系统的正常运行，由您的业务指标定义。它可以用每秒交易量 (TPS)、每秒点击流、每秒订单数或类似的衡量标准来表示。当您的应用程序按预期运行时，它会显示出稳定的状态。因此，在运行实验之前，请验证您的应用程序是否运行正常。稳定状态并不一定意味着故障发生时不会对应用程序产生任何影响，因为故障的百分比可能在可接受的范围内。稳定状态是您的基准。例如，支付系统的稳定状态可以定义为处理 300 TPS，成功率为 99%，往返时间为 500 毫秒。从视觉上看，可以将稳定状态想象成心电图 (EKG)。如果系统的稳定状态突然波动，则表明您的服务存在问题。
+ **服务器端指标** — 要了解您的资源在实验期间的表现，您需要深入了解其在实验之前、期间和之后的性能。要衡量您的资源对的影响 AWS，您可以使用 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)。 CloudWatch 是一项监控应用程序、响应性能变化、优化资源使用并提供对运行状况的见解的服务。在实验期间，您需要捕获服务器端指标，例如饱和度、请求量、错误率和延迟。
+ **客户体验指标** — 开启后 AWS，你可以使用 [CloudWatchRUM 通过 Locust、Grafana k6、Selenium](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 或 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)。
## 混沌实验中注入的失败场景
将常见故障注入应用程序的目的是了解应用程序对这些意外事件的反应，以便您可以创建缓解机制并使系统能够抵御此类故障。此外，您应该使用混沌工程来重播历史故障场景，以验证缓解机制是否仍按预期运行，并且不会随着时间的推移而发生偏差。
在计划混沌工程实验时，请考虑以下事件。
| 故障模式 | 说明 |
| --- | --- |
| 服务器损坏 | 重启 EC2 实例，删除 Kubernetes pod 或亚马逊弹性容器服务 (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) 和其他技术人员，以评估混乱工程是否增强了他们对应用程序弹性的信心。感知很重要。
+ **改善客户体验** − 将混乱工程与客户的积极成果联系起来，例如减少服务中断、回滚和中断。
## 确定补救的优先顺序
在执行混沌实验时，您可能会发现应用程序无法按预期运行的需要改进的领域。修复此类项目将成为待办事项中的工作，必须与其他工作（例如功能开发）一起确定优先顺序。我们建议您为这些增强留出时间，以避免 future 出现故障。考虑根据这些学习和补救任务可能造成的影响程度对其进行优先排序。直接影响应用程序弹性或安全性的发现应优先于新功能，以避免对客户造成影响。如果团队难以将补救工作置于功能开发之上，请考虑联系您的执行发起人，确保根据业务风险承受能力设定优先级。