AWS Well-Architected Framework レビューの進め方について

AWS Well-Architected Framework レビューの進め方について投稿させていただきます。 今回はW-Aの内容ではなく、レビュー自体の進め方についてです。ちょっと毛色が違うのですがとても重要な事なのでご紹介させていただこうと思います。
2019.04.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ご機嫌いかがでしょうか、豊崎です。

AWS Well-Architected Framework レビューの進め方について投稿させていただきます。 今回はW-Aの内容ではなく、レビュー自体の進め方についてです。ちょっと毛色が違うのですがとても重要な事なのでご紹介させていただこうと思います。

AWS Well-Architected Frameworkとは何か?

AWS Frameworkは、「運用性」「信頼性」「パフォーマンス」「セキュリティ」「コスト最適化」の5つの柱からなる、システムをより良くしていくための「考え方」です。

以下、AWS Black Belt - AWS Well-Architected Frameworkより引用

システム設計・運用の大局的な考え方とベストプラクティス集 >・AWS のソリューションアーキテクトとお客様が長年にわたり数多くの経験から作り上げたもの >・AWS とお客様と共に、W-A も常に進化し続ける

 

[slideshare id=125680790&doc=20181211aws-blackbelt-well-architected-181212060610]

レビューに対する進め方について

AWS Well-Architected Frameworkのレビュープロセスの項目にには、レビューを行う上での準備や姿勢についても明記されています。AWS Well-Architected Frameworkのレビューを行う上で非常に大事なことなので内容をサマリでご紹介させていただきます。

誰も責めない

レビューは監査ではありません。レビューの目的は、改善できる部分や、対応が必要な深刻な問題を特定する事です。責められる緊張感は発言を停滞したり、レビューの場が地獄のような空気になったりします。

各チームのメンバーを集める

レビューを実施した際、「誰もわからない」という状態が発生するケースがあります。そういった状態を回避する為に、各チームメンバー、ステークホルダーを集めましょう。また、全員揃っているのに「わからない、知らない」が出てくることもあると思います。その際は、その事実を全員で共有して対応を考える機会と捉えましょう。

レビューは設計の初期段階から行う

設計、構築、運用などライフサイクル中に複数回レビューを行う事が望ましいです。その中でも、まずは変更が困難な決定を避ける為、設計の初期段階におけるレビューを行う事が望ましいです。ワークロードは新しい機能の追加や、テクノロジーの実装によって進化する為、継続的な変化ができる準備をしておく事が望ましいです。

レビューは短時間で行う

数日ではなく数時間でレビューを行うようにします。

継続的なレビューを開く

アーキテクチャの構築に携わったメンバーを招集し、アーキテクチャの成長に合わせて改良の場として継続的なレビューを行うようにしましょう。また、大幅な変更を加えた場合もWell-Architectedのレビューを含む改善プロセスを行いましょう。

レビュー後のアクション

問題のリストを作成し、優先順位を決めて実施する。問題を放置するリスク、解決した時のメリットを十分に伝えてチームに理解を得ることも重要です。

さいごに

AWS Well-Architected Framework レビューの進め方について書かせていただきましたが、それ以外のレビューでも活かせる大事な事が書かれているのではないでしょうか。AWS Well-Architected Frameworkを実施する際には是非ご参考にしていただければ幸いです。

参考

AWS Well-Architected フレームワーク https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf