# ドキュメントとインフラストラクチャ
WAFR を実行すると、従うべきベストプラクティスの多くについて、文書化されたプロセス、標準運用手順 (SOP)、ランブック、プレイブックがあることがわかります。WAFR 中に、Well-Architected Tool (WA ツール) 内のメモフィールドに情報とコンテキストを記録します。ワークロードに関連するすべての関連ドキュメントアーティファクトを事前に収集することで、レビュー中の時間を節約できます。
ドキュメントを検討するときは、次の質問を考慮してください。
+ ワークロードに関するドキュメントにはどのようなものがありますか?
+ どのドキュメントが欠落していますか?
+ これらのアーティファクトを作成および保存するには、どのようなツールを使用しますか?
+ これらのアーティファクトの作成とメンテナンスには誰が関与しますか?
ワークロードに関するドキュメントの例を以下に示します。
+ ワークロード Wiki ページ
+ アーキテクチャ図
+ アーキテクチャ決定レコード (ADR)
+ 標準操作手順 (SOP)
+ Infrastructure as Code (IaC) リポジトリ
+ ネットワークトポロジ
+ プレイブックとランブック
+ 組織またはチームの構造
+ マルチアカウント戦略ドキュメント
+ 中央 ID プロバイダーの設定
+ 中央モニタリングソリューションの設定
+ 依存ワークロードのドキュメント
+ API リファレンスガイド
+ ソフトウェアライブラリのバージョン
+ エラー修正 (COE) プロセスと履歴
+ カオスエンジニアリング戦略
+ ロードテストチームの詳細
+ 脅威モデル
+ チームレトロスペクティブ
+ ゲームデーのドキュメント
## アンチパターン
これらのリソースが存在しない場合でも、検出メカニズムとして WAFR を実行できます。ただし、これらのアーティファクトがないと、プロセスに時間がかかる場合があります。ドキュメントアセットの作成は、アーキテクチャの健全性向上に向けた最初のステップとなります。
## ワークロードの検出
コンポーネントやリソースを知らずに、アーキテクチャを効率的にレビューすることは困難です。レガシーワークロードは、時間の経過とともに進化したり、所有権が変更されたりすることが多く、AWS CloudFormation、AWS CDK、Terraform などの Infrastructure as Code (IaC) ツールを使用して定義されていない可能性があります。
改善点について説明する前に、ワークロードのさまざまなアーキテクチャコンポーネントとその依存関係を理解し、共通の理解を提供するための視覚的表現を作成します。
ソフトウェアベンダーから直接、[AWS Marketplace](https://aws.amazon.com/marketplace/search/results/) から、またはオープンソースソリューションとして入手できるサードパーティーの検出および自動ダイアグラム作成ツールは多数あります。
## リソース
+ [AWS リファレンスアーキテクチャ図](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 Home](https://adr.github.io/)
+ [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/)