SRE で AWS Well-Architected 輪読会を実施しました！

執筆者：SRE シラト
・最近、初めて野球観戦に行って大興奮しました。
・今のところ推しは、ソフトバンク東浜。
・プロ野球チップスで当たるといいな。

今回のお話

SRE で AWS Well-Architected（以下、W/A）の輪読会を実施しました。
感想や実際にW/Aをどう活用していくべきかについて話し合いましたのでご紹介いたします！
※ SREは現在3名体制

SRE の Roadmap に『AWS のベストプラクティス実装』を組み込みました。
W/A は、SRE全体で共通認識にした方が良さそうと判断し、輪読会の実施に至りました。

項目	詳細
頻度	1, 2週間ごとに3時間まとめて確保
ペース	一度に一柱
事前準備	一読（1時間前後）
進め方	ベストプラクティス一つにつき10分のペースでディスカッション。課題意識があること、よくわからなかったこと等なんでもOK！

・可視化の重要性を再確認できた。
・課題意識のすり合わせができた。
・すぐにアクションに結びつく項目があった。
例）スクラム、NSM、Cfn gitops導入等
・最初の方に単語の意味をすり合わせしてよかった。
例) ワークロード = ComicFesta, Coolmic等プロジェクト単位

・一周だけでは、断片的な内容しか覚えていない。
・一人で読むのは辛いので、チームで苦労を共にするのがおすすめ。
・やることが多すぎてどこから手を付けるべきか判断が難しい。
・そもそもすべて対応することが現実的なのだろうか。
・難解な記述があり、原文の方がわかりやすい場合がある。

輪読会を終えて、個人的に誤解していたことが２点ありました。

ビジネスサイドなど他チームと話し合う必要性のある項目が多数あります。

例えば、運用上の優秀性の『OPS 8: ワークロードの正常性をどのように把握しますか?』には、KPIの異常検知の話が出てきます。
異常検知するとしても、ビジネスサイドと正常を定義しないといけませんよね。

一番大きな誤解でした。
AWS Well-Architectedの活用方法（2019）では以下の通りに言及されております。

Q：全項目ベストプラクティスに則っていないとダメなのか？
A：ベストプラクティスを理解した上で、皆様が「（ビジネス的な）判断をする」ことが重要

リスクや改善点の"顕在化"が重要となり、ビジネス判断でどこまで対応するかを話し合うことが大切とのことでした。

例えば、『Multi-AZの方が良いらしい』という理由で、Multi-AZにするのはNG。
ビジネスサイドにリスクを噛み砕いて説明した上で、判断できるといいのかなーと個人的には思っております。

まずは、『SRE が W/A の項目を噛み砕いて説明できるようにする』ことを目標にアクションする予定です。
一読だけでは、自信を持って自分の言葉で説明することはできませんでした。

プロジェクト全体を巻き込むには、以下の説明ができるようになる必要があると考えております。
・対応状況
・対応しないことのリスク
・対応するためにする具体的なアクション

今回は、SREでの取り組みについてご紹介でした！
W/A をコミュニケーションツールとして、活用できるよう取り組んでいきます！