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

# 實驗規劃文件
<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_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | 
| 整體應用程式運作狀態 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/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_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | 
| 日誌 | 寵物採用 CloudWatch Logs | Pod 遇到的任何錯誤都會發佈至 CloudWatch Logs。 | 

## 實驗定義
<a name="experiment-definition"></a>


| 實驗名稱 | Amazon EKS PetSite Pod CPU 壓力 | 
| --- | --- | 
| 實驗原始程式碼 | （實驗來源儲存庫的連結。) | 
| 實驗描述 | 此實驗探索 PetSite 應用程式 Pod 的 CPU 使用量增加將如何影響整體客戶體驗。透過將 CPU 壓力注入每個執行中的 PetSite Pod，我們將能夠了解是否對客戶造成影響，以及影響的程度。 | 
| 實驗需求或參數 | 應用程式負載：生產平均值<br />Pod 標籤選擇器： `app=petsite` | 
| 實驗持續時間 | 10 分鐘 | 
| 環境 | Alpha 測試環境 | 
| 實驗目標資源 | PetSite 應用程式 Pod | 
| 透過負載產生工具引入的實驗基準 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | 
| 退避條件 | 無 | 

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


| 如果 | 影響 | 復原 | 
| --- | --- | --- | 
| 如果在正常生產層級流量下，PetSite 應用程式裝置遇到或導致 CPU 使用率超過 60% 達 10 分鐘，穩定狀態會發生什麼情況？<br />** ** | 對於 P99 為 4.0 秒或更短的 P50 使用者，LCP 時間將維持在 2.5 秒以下。 P99 消費者應該能夠載入 PetSite 登陸頁面。 | 偵測：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/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_tw/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/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，請擷取其他螢幕擷取畫面，以記錄應用程式是否在沒有壓力的情況下返回穩定狀態，並記下資料點中的任何異常。

   1. 如果穩定狀態未繼續，請採取步驟來復原應用程式，並記錄採取的步驟。

1. 驗證環境已恢復正常：
   + 檢閱所有業務、使用者體驗、應用程式和基礎設施指標，以確認系統已返回已知狀態。如果有幫助，請擷取儀表板螢幕擷取畫面。

## 實驗時間軸
<a name="experiment-timeline"></a>

請確定您擷取end-to-end實驗的時間軸，從負載產生開始、注入錯誤、觀察影響和應用程式復原，以及在停止負載產生時結束。這會在下列範例中說明。

![混沌實驗的時間軸範例。](http://docs.aws.amazon.com/zh_tw/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 的影響。