WAFR の実行

肯定的な意図を伝える: WAFR の肯定的な意図を参加者と再確認します。仕事に関する重要な会話は難しい場合があるため、WAFR が改善の機会を見つけるために実施されていることを再確認してください。非難しない文化を強化します。攻撃も防御もなく、アーキテクチャの改善について協力して議論します。

サポーターを取り込む: 複雑なワークロードアーキテクチャをナビゲートし、質問し、応答を調整し、メモを取ることは、1 人で実行するには難しい場合があります。WAFR の成功はチームアクティビティです。代わりの役割を指定して、あるユーザーがレビューを実行し、別のユーザーがメモを取り、ドキュメントを確認し、ディスカッションを監視できるようにします。

トピックに留まる: アーキテクチャ上の決定についてグループで会話するときに、人々が脱線してしまうことはよくあります。時間を効率よく使いたい場合は、WAFR 参加者が互いに尊重し合ってトピックに留まるようにしてください。サイドコンセプトとアイデアを一元化された場所に記録し、今後のディスカッションセッションで取り上げることができます。

適切なメモを取る: WA ツールのボックスにチェックを入れるだけでは、後のマイルストーンで WAFR を再検討する人にコンテキストが提供されません。WA ツールのメモボックスを使用するか、文字制限を超えた場合は WAFR メモボックスからリンクされた外部ドキュメントを作成します。コンテキストは、他の関係者、特にワークロードを初めて使用する人が進行中の作業を理解し、優先順位を決定するのに役立ちます。

ソリューションに焦点を当てない: ソリューションではなく、ワークロードに関するデータポイントのキャプチャに焦点を当てます。ソリューションに重点を置きすぎると、WAFR セッション中に時間が浪費され、重要なデータポイントを取得できなくなる可能性があります。範囲外のことをブレインストーミングするのは、他の参加者の時間を最大限に活用することにはなりません。

ツールではなくワークロードに焦点を当てる: AWS マネジメントコンソールの Well-Architected Tool (WA ツール) を表示した画面を共有するのは一般的です。WA ツールでデータをキャプチャすることは重要ですが、ツールだけに集中しないでください。代わりに、アーキテクチャに関するディスカッションに焦点を当ててください。レビューは会話形式にし、コンテキストに合わせて質問を言い換えます。

ディスカッションをパートに分割する: 1 回の会議で 6 つの柱をすべて確認するのは難しい場合があります。レビューを小さなセッションに分割することで、トピックをターゲットにしたアプローチが可能になり、参加者とのスケジューリングが容易になります。

休憩を取ることを忘れない: アーキテクチャを徹底的に確認することは参加者にとって疲れる可能性があり、時間の経過とともに集中力が低下する可能性があります。WAFR 中は頻繁に休憩をスケジュールします。参加者の時間を大切にし、必要がなくなった時点で退席できるようにします。

可能性について慎重に考える: 質問に対する答えが、「たぶん」、「そのような」、「対処するための何かがバックログにあります」である場合は、それが実質的に「いいえ」を意味していないか慎重に検討してください。WAFR とは、意図した状態ではなく、ワークロードの正直な現在の状態をキャプチャすることを目的としています。

トレードオフを検討する: Well-Architected は各柱間でトレードオフを行うことに重点を置いています。ワークロードの耐障害性を高めるとコスト最適化が損なわれる可能性があり、またコストをさらに最適化するとワークロードの環境への影響が悪化する可能性があります。柱は、会話の枠組みを提供し、情報に基づいたアーキテクチャの選択を行うのに役立ちます。

完璧なワークロードは存在しないことを認識する: ワークロードが完璧であることは稀で、完璧である必要もほとんどありません。WAFR を完璧主義の追求とすることを避け、ワークロードが意図されたビジネス目的に沿って安全かつ効率的に機能することに重点を置いてください。