レビュープロセス

アーキテクチャの評価は非難せずに掘り下げることができる一貫した方法で実施される必要があります。これは何日もかけずに数時間で終わる軽いプロセスである必要があります。話し合いであり、監査ではありません。アーキテクチャレビューの目的は、対策を必要とする重大な問題や改善可能な領域を特定することです。レビュー結果は、お客様のワークロードの扱いやすさを改善する対策です。

「アーキテクチャ」で説明したとおり、各チームメンバーがアーキテクチャの品質に責任を持つ必要があります。Well-Architected フレームワークに基づいてアーキテクチャを作成するチームメンバーは、形式ばったレビューミーティングを開催するよりも、アーキテクチャを継続してレビューすることが推奨されています。レビューを継続することで、チームメンバーはアーキテクチャの変化に応じて回答を更新したり、機能を提供しながらアーキテクチャを改善したりすることができます。

AWS Well-Architectedは、AWS のシステムとサービスに関する内部評価方法と合致しています。これは設計方法を左右する設計原則と、根本原因の分析 (RCA) でよく取り上げられる領域が軽視されないようにするための質問に基づきます。内部システム、AWS のサービス、またはお客様に重大な問題があるときに、当社は RCA を検討し、使用している評価プロセスを改善できるかどうかを判断します。

変更が困難な一方通行のドア (のような決定)« [  多くの決定は取り消しが可能な双方向の扉です。こうした決定には簡易なプロセスを適用します。一方通行のドア (のような決定) の場合は、取り消しが困難または不可能であるため、決定を下す前により詳細な検証が必要です。 ] »  を避けるため、設計の初期段階におけるレビューを実施します。また、本番運用前にもレビューを行います。本稼働開始後に新しい機能を追加したり、テクノロジーの実装を変更したりするにつれて、ワークロードは変化し続けます。ワークロードのアーキテクチャは時間とともに変わります。アーキテクチャを変えるにつれてアーキテクチャの特性が劣化しないように適切な予防策を取る必要があります。アーキテクチャを大幅に変更するときには、Well-Architected レビューを含めて、予防プロセスに従う必要があります。

1 回限りのレビューまたは単独の測定として評価を活用するには、すべての適切な関係者をその話し合いに含める必要があります。レビューが実施されたことにより、チームが実装した内容を初めて本当に理解したということはよくあります。別のチームのワークロードをレビューするときに有効な方法は、そのアーキテクチャについて何度か気軽に話し合うことです。ほとんどの質問に対する回答はそれで得られます。その後に数回の会議で曖昧な領域や気付いたリスクについて解明したり、掘り下げたりすることができます。

会議を進行するために次のアイテムをお勧めします。

• ホワイトボードのある会議室

• 印刷した構成図や設計ノート

• 回答に別途調査が必要な質問のアクションリスト (例えば暗号化を有効にしましたか ?)

レビューを完了すると、問題のリストが出来上がります。ビジネスの状況に応じてその優先順位を決めることができます。それらの課題がチームの日常業務に及ぼす影響を考慮する必要もあります。課題に早く対処することによって、繰り返す課題の解決にではなく、ビジネス価値の創造に費やす時間ができます。課題に対処しながらレビューを更新することで、アーキテクチャがどのように改善しているのかを知ることができます。

レビューの価値は 1 度やってみると明らかになるのですが、新しいチームが当初抵抗することがあります。レビューの利点をチームに知らせることで、次のような反論に対処できます。

• 忙しすぎる (チームが大きな仕事を始める準備をしているときによくある発言)

  • 大きな仕事を始める準備をしているならば、それが円滑に進む必要があります。レビューを実施することによって、見逃していたかもしれない問題を把握できます。

  • 製品ライフサイクルの早い段階でレビューを実施して、リスクを洗い出し、機能提供ロードマップに沿ったリスク軽減計画を立てることをお勧めします。

• 結果が出ても対策をとる時間がない (スーパーボウルなど動かせないイベントを目標としている場合によくある発言)

  • そのようなイベントを動かすことはできません。アーキテクチャのリスクを把握せずに、本当に進めるつもりですか。 すべての課題に対策を講じることができないとしても、問題が生じたときの対処法を準備しておくことはできます。

• We don’t want others to know the secrets of our solution implementation!

  • Well-Architected フレームワークの質問を示せば、取り引きや技術に関する専有情報を開示する質問が 1 つもないことをチームは理解するでしょう。

組織内の他のチームと何度かレビューを実施すると、主題となる課題が見つかるかもしれません。例えば、特定の柱または主題に関して多くの課題を抱えているチームが複数あるかもしれません。すべてのレビューを総合的に検討し、それらの主題に関する課題に対処するのに役立つメカニズム、トレーニング、またはプリンシパルエンジニアリングの説明を見つける必要があります。