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

# 实验计划文件
<a name="sample-planning"></a>

## 稳定状态
<a name="planning-steady-state"></a>


| 进程名称 | 宠物收养网站 | 
| --- | --- | 
| 物理架构 | （链接到架构图。） | 
| 逻辑架构 | （链接到逻辑图。） | 
| 定义稳定状态 | 使用最大内容绘图（LCP）衡量，宠物收养网站的平均页面加载时间为2.5秒或更短，99个百分位延迟（P99）为4.0秒或更短，基准为5000个并发用户。 | 
| 稳定状态指标 | 跨用户群捕获的 LCP 指标和黄金指标（延迟、吞吐量、错误率、饱和度）。 | 
| 稳态可观测性 | LCP 将被用户的浏览器捕获，发送到 Amazon CloudWatch，然后使用 CloudWatch RUM 进行检查。在 60 秒的时间段内，将汇总该时间段内所有请求的平均时间和 P99 LCP 时间。顶级黄金指标是通过使用捕获的 CloudWatch。 | 
| 实现稳态的过程 | Grafana K6 将用于创建负载，该负载可模拟大约 5K 并发用户的正常生产流量水平。 | 

## 可观测性要求
<a name="observability-reqs"></a>

团队应该能够查看以下内容：
+ **稳定状态**：要验证应用程序是否处于正常状态，需要观察什么？
+ **故障状况**：故障状态将如何显示在仪表板上？ 例如：
  + 应触发的警报
  + 应该生成的日志
+ **故障影响**：要查看预计会受到影响的组件（影响范围），应注意什么？
+ **恢复**：如何看待和衡量恢复以捕获 MTTR？
+ **调试**：有关实验失败的故障排除详细信息。

下表提供了可观测性要求图表的建议和示例。你应该根据你的具体实验来定义应该观察的内容。


| 需要注意什么 | 链接到可观测性工具 | 正在观察到什么 | 
| --- | --- | --- | 
| 输入来源 | Grafana K6 仪表板 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | 
| 应用程序的整体运行状况 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | 
| 工作流程运行状况 | 宠物收养 CloudWatch 仪表板 | LCP 时间，黄金指标 | 
| 跟踪 | 宠物收养 X-Ray 仪表板 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | 
| 日志 | 宠物收养 CloudWatch 日志 | Pod 遇到的任何错误都将发送到 CloudWatch Logs。 | 

## 实验定义
<a name="experiment-definition"></a>


| 实验名称 | 亚马逊 EKS p PetSite od CPU stress | 
| --- | --- | 
| 实验源代码 | （链接到实验源存储库。） | 
| 实验描述 | 本实验探讨了 PetSite 应用程序 pod 的 CPU 使用率的增加将如何影响整体客户体验。 通过向每个正在运行的 PetSite pod 注入 CPU 压力，我们将能够了解是否会对客户产生影响以及这种影响的程度。 | 
| 实验要求或参数 | 应用程序负载：平均产量<br />Pod 标签选择器：`app=petsite` | 
| 实验持续时间 | 10 分钟 | 
| Environment | Alpha 测试环境 | 
| 实验目标资源 | PetSite 应用程序窗格 | 
| 通过负载生成工具引入的实验基线 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | 
| 退避条件 | 无 | 

## 假设
<a name="hypothesis"></a>


| 假设会怎样 | 影响 | 恢复 | 
| --- | --- | --- | 
| 如果在正常生产级流量下， PetSite应用程序 pod 在 10 分钟内经历或导致 CPU 使用率超过 60%，那么稳定状态会怎样？<br />** ** | P99 为 4.0 秒或更短的 P50 用户的 LCP 时间将保持在 2.5 秒以下。消费者应该能够加载 PetSite 登录页面。 | 检测：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)<br />自我修复：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)<br />恢复： <br />当 CPU 利用率恢复正常时，LCP 应自动恢复。 | 

## 实验过程
<a name="experiment-process"></a>

根据您的特定实验量身定制以下示例 step-by-step流程：

1. 验证对所有 Amazon CloudWatch、 CloudWatch RUM 和 AWS X-Ray 控制面板的访问权限和功能。

1. 验证应用程序环境的运行状况：

   1. 使用 CloudWatch控制面板确认 EKS 集群运行正常。

   1. 通过示例 URL 访问测试宠物收养网站应用程序部署。

1. 启动负载以达到稳定状态：

   1. 确认负载生成器正在运行并且每秒发送 5000 个请求。

   1. 等待 5 分钟，让应用程序达到稳定状态。

   1. 使用 CloudWatch RUM 控制面板确认应用程序的稳定状态。

1. 启动故障（实验）：

   1. 打开控制 AWS FIS 台。

   1. 运行实 pet-adoption-pod-stress验。

   1. 确认实验正在控制台中运行。

1. 观察故障对应用程序的影响：

   1. 从 CloudWatch RUM 和 CloudWatch 仪表板中捕获屏幕截图，并记下任何异常数据点。

   1. 实验完成后 AWS FIS，捕获更多屏幕截图以记录应用程序在没有 stress 的情况下是否恢复到稳定状态，并记下数据点中的任何异常。

   1. 如果稳定状态未恢复，请采取措施恢复应用程序并记录所采取的步骤。

1. 验证环境是否已恢复正常：
   + 查看所有业务、用户体验、应用程序和基础架构指标，以验证系统是否已恢复到已知状态。如果有帮助，请捕获仪表板屏幕截图

## 实验时间表
<a name="experiment-timeline"></a>

确保捕捉 end-to-end实验的时间表，从负载生成、故障注入、影响观察和应用程序恢复开始，到停止负载生成时结束。以下示例说明了这一点。

![混沌实验的时间表示例。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/chaos-engineering-on-aws/images/timeline.png)


## 实验结果
<a name="experiment-results"></a>


| 实验运行 ID | 实验结果 | 
| --- | --- | 
| `PET-ADOPT-EXP-23` | （链接到实验结果。） | 

## 已识别的缺陷
<a name="defects"></a>
+ Kubernetes 集群没有检测到 PetSite pod 的 CPU 损失，因此它没有安排额外的部署。
+ 该实验没有导致4XX或5XX的错误率增加。
+ 我们需要调整 Pod 的运行状况检查，以考虑资源限制时对 LCP 的影响。