# 文档和基础设施
<a name="documentation-and-infrastructure"></a>

 运行 WAFR 时，您可能会发现，对于您遵循的许多最佳实践，您将有一个记录在案的流程、标准操作程序（SOP）、运行手册或行动手册。在 WAFR 期间，将在 Well-Architected Tool（WA Tool）内的注释字段中记录信息和上下文。通过提前收集与工作负载相关的所有相关文档构件，可以节省审查期间的时间。

 在考虑文档时，请考虑以下问题：
+  有哪些关于工作负载的文档？ 
+  缺少什么文档？ 
+  将使用哪些工具来创建和存储这些构件？ 
+  谁将参与这些构件的创建和维护？ 

 有关工作负载的一些文档示例包括：
+  工作负载维基页面 
+  架构示意图 
+  架构决策记录（ADR） 
+  标准操作程序（SOP） 
+  基础设施即代码（IaC）存储库 
+  网络拓扑 
+  行动手册和运行手册 
+  组织或团队结构 
+  多账户策略文档 
+  集中式身份提供者配置 
+  集中式监控解决方案配置 
+  相关工作负载的文档 
+  API 参考指南 
+  软件库版本 
+  更正错误（COE）流程和历史记录 
+  Chaos 工程策略 
+  负载测试团队详情 
+  威胁模型 
+  团队回顾 
+  GameDay 文档 

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

 如果这些资源都不存在，您仍然可以将 WAFR 作为发现机制运行。但是，如果没有这些构件，该流程可能需要更长时间。创建文档资产可能是改善架构运行状况的第一步。

## 工作负载发现
<a name="workload-discovery"></a>

 如果不了解架构的组件和资源，就很难高效地审查架构。旧式工作负载通常会随着时间推移而演变或所有权发生变化，并且它们可能不是使用 AWS CloudFormation、AWS CDK 或 Terraform 等基础设施即代码（IaC）工具定义的。

 在讨论改进之前，请先了解工作负载的不同架构组件及其依赖关系，并创建可视化表示来提供共同的理解。

 有许多第三方发现和自动绘图工具可以直接从软件供应商、[AWS Marketplace](https://aws.amazon.com/marketplace/search/results/) 或作为开源解决方案获得。

## 资源
<a name="resources"></a>
+  [AWS Reference Architecture Diagrams](https://aws.amazon.com/architecture/reference-architecture-diagrams) 
+  [Architectural Decision Record Process](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html) 
+  [ADR GitHub 主页](https://adr.github.io/) 
+  [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 
+  [Workload Discovery On AWS Solution](https://aws.amazon.com/solutions/implementations/workload-discovery-on-aws/)