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

# 實驗結果文件
<a name="sample-result"></a>

## 組態
<a name="config"></a>

記錄實驗的特定組態。例如：
+ 負載產生設定為模擬 5K 使用者每秒發出總計 85 個請求。

## 先決條件
<a name="prereqs"></a>
+ 驗證寵物採用網站是否在 Alpha 測試環境中執行。
+ 驗證實驗範本已設定為將 CPU 壓力套用至在 EKS 叢集中執行的 PetSite 應用程式 Pod。  應用程式 Pod 由 Kubernetes 標籤 識別`app=petsite`。
+ 負載已確認正在執行，每秒產生 85 個請求。

## 穩定狀態
<a name="results-steady-state"></a>

記錄為了達到穩定狀態所採取的步驟，以及驗證的方式。例如：

對於寵物採用網站的測試部署，會產生 85 RPS 的負載來模擬穩定狀態。已檢閱 CloudWatch RUM 和 CloudWatch 儀表板，以確認在執行實驗之前，所有業務和應用程式指標都在正常範圍內。

可觀測性資料：


| 預期 | 觀察到的 | 
| --- | --- | 
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-result.html) | ![混沌實驗的穩定狀態報告 1。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/images/ss-1.png)![混沌實驗的穩定狀態報告 2。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/images/ss-2.png) | 

## 錯誤注入
<a name="fault-injection"></a>

AWS FIS 使用實驗範本 （提供連結） 來注入錯誤。實驗設定為執行 10 分鐘，如果工作者節點遇到 CPU 壓力超過 60%，則會設定回復。

## 故障觀察
<a name="fault-obs"></a>

已檢閱 CloudWatch RUM 和 CloudWatch 儀表板，以追蹤應用程式的穩定狀態 （使用 LCP 指標定義）。  螢幕擷取畫面擷取於下表。

可觀測性資料：


| 預期 | 觀察到的 | 
| --- | --- | 
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-result.html) | ![混沌實驗的故障觀察報告 1。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/images/fs-1.png)![混沌實驗的故障觀察報告 2。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/images/fs-2.png) | 

## 復原
<a name="recovery"></a>

移除壓力後 ( AWS FIS 實驗已完成並從 Pod 移除 CPU 壓力），應用程式應繼續正常穩定狀態。  不需要手動介入。

可觀測性資料：


| 預期 | 觀察 （螢幕擷取畫面） | 
| --- | --- | 
| LCP P99 應低於 4 秒，平均值低於 2.5 秒。 | ![混沌實驗的復原結果範例。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/images/rec-1.png) |