# 文件和基礎結構
<a name="documentation-and-infrastructure"></a>

 執行 WAFR 時，您可能會發現，您遵循的許多最佳實務都有記錄程序、標準操作程序 (SOP)、執行手冊或程序手冊。在 WAFR 期間，將資訊和內容記錄在 Well-Architected Tool (WA Tool) 內的備註欄位中。您可以事先收集與工作負載有關的所有相關文件成品，以節省檢閱的時間。

 在考慮文件時，請考慮下列問題：
+  工作負載有哪些文件？ 
+  缺少哪些文件？ 
+  使用哪些工具來建立和儲存這些成品？ 
+  誰會參與這些成品的建立和維護工作？ 

 有關工作負載的一些文件範例包括：
+  工作負載 Wiki 頁面 
+  架構圖 
+  架構決策記錄 (ADR) 
+  標準操作程序 (SOP) 
+  基礎結構即程式碼 (IaC) 儲存庫 
+  網路拓撲 
+  手冊和執行手冊 
+  組織或團隊結構 
+  多帳戶策略文件 
+  集中身分提供者組態 
+  集中監控解決方案組態 
+  相依工作負載的文件 
+  API 參考指南 
+  軟體程式庫版本 
+  錯誤糾正 (COE) 程序和歷史記錄 
+  混沌工程策略 
+  負載測試團隊詳細資訊 
+  威脅模型 
+  團隊回顧會議 
+  演練日文件 

## 反面模式
<a name="anti-patterns"></a>

 如果這些資源都不存在，您仍然可以執行 WAFR 作為探索機制。不過，如果沒有這些成品，程序可能需要更長的時間。建立文件資產是改善架構運作狀態的第一步。

## 工作負載探索
<a name="workload-discovery"></a>

 如果不知道架構的元件和資源，則很難有效率地檢閱架構。傳統工作負載通常會隨著時間演進或變更擁有權，而且可能尚未使用基礎結構即程式碼 (IaC) 工具 (如 AWS CloudFormation、AWS CDK 或 Terraform) 加以定義。

 在討論改善之前，務必先了解工作負載的不同架構元件及其相依性，並建立視覺化呈現以提供共同的了解。

 有許多第三方探索和自動製圖工具可以直接從軟體供應商、從 [AWS Marketplace](https://aws.amazon.com/marketplace/search/results/) 或作為開放原始碼解決方案取得。

## 資源
<a name="resources"></a>
+  [AWS 參考架構圖表](https://aws.amazon.com/architecture/reference-architecture-diagrams) 
+  [架構決策記錄程序](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html) 
+  [ADR GitHub 首頁](https://adr.github.io/) 
+  [為什麼您應該制定錯誤糾正 (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 
+  [AWS 解決方案上的工作負載探索](https://aws.amazon.com/solutions/implementations/workload-discovery-on-aws/)