Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Well-Architectedな組織を
実現するためのチャレンジ - なぜ、CA W-Aを作...

Well-Architectedな組織を
実現するためのチャレンジ - なぜ、CA W-Aを作ろうと思ったのか - #jawsdays 2019

「 Are you Well-Architected? 」
2015年、 AWS Well-Architected Framework が発表され、昨年の re:Invent では、 AWS Well-Architected Tool が発表されました。
Well-Architected という言葉を耳にする機会が増えてきたと感じますが、組織としては Well-Architected な状態でしょうか?

本セッションでは、昨年末に CyberAgent Developers Blog へ寄稿した記事( https://developers.cyberagent.co.jp/blog/archives/19224/ )の内容を中心に話す予定です。また、記事では紹介しきれなかった以下の取り組みなどについても話す予定でいます。
– 横断インフラ組織として抱える課題に対して取り組んできたこと
– Organizational Reliability Engineer(ORE) というロール
– 独自で作っている Well-Architected Framework(CA W-A) が目指しているビジョン

柘植 翔太
株式会社サイバーエージェント 技術本部サービスリライアビリティグループ
Senior Organizational Reliability Engineer

2014年、株式会社サイバーエージェントへ入社。
入社後は、インフラエンジニアとして、様々なメディアサービスのインフラを担当。現在は、主にPublic Cloudを活用しているメディアサービスの立ち上げ・改善のサポートや、組織作りなどにも取り組む。

shotaTsuge

May 20, 2019
Tweet

More Decks by shotaTsuge

Other Decks in Technology

Transcript

  1. Well-Architectedな組織を 
 実現するためのチャレンジ - なぜ、CA W-Aを作ろうと思ったのか - @JAWS DAYS 2

    01 9 #jawsdays #jd 2 0 1 9 _e 株式会社サイバーエージェント 技術本部サービスリライアビリティグループ 柘植 翔太
  2. 名前 柘植 翔太 @shotaTsuge • 所属 株式会社サイバーエージェント 技術本部サービスリライアビリティグループ • ロール

    Senior Organizational Reliability Engineer • 好きなAWSサービス AWS Well-Architected Framework • コミュニティ活動 Japan AWS User Group( 2 0 1 2 - 2 0 16 )
  3. 名前 柘植 翔太 @shotaTsuge • 会社での経歴 20 1 4 /

    0 4 - 2014 / 09 Software Engineer @ AmebaPigg 20 1 4 / 0 9 - 2018 / 03 Infrastructure Engineer - Ameba Pigg - Social Game Services - Curation Media Services - Streaming Services - Matching Services - AdTech Services - FinTech Services - And more … 20 1 8 / 0 4 - Senior Organizational Reliability Engineer
  4. 寄稿歴 • サイバーエージェント公式デベロッパーブログ https://developers.cyberagent.co.jp/blog/archives/ 19224 / • Software Design 201

    9 年2⽉号 - SRE特集 - https://gihyo.jp/magazine/SD/archive/ 2 01 9 / 20 1 90 2 • AWS導⼊事例 https://aws.amazon.com/jp/solutions/case-studies/torte/
  5. 本セッションの内容 • 本セッションで話すこと📢 - ⾃分が所属する横断的インフラ組織がどんな悩みを抱えながら歩んでいるのか - OREというロールをなぜ作ったのか、そもそもどういったロールなのか - なぜ、独⾃でWell-Architected Framework(CA

    W-A)を作っているのか - Well-Architected Frameworkにどんな可能性を感じているのか • 本セッションでの注意⚠ 技術的なことは話しません🙇 CA W-Aは、現時点では試作段階であり、本セッションにおける発⾔は、 所属するチームとしての⾒解であり、会社全体の意向ではありません🙏
  6. 登壇者からのお願い • 本セッションへのお気持ち 今⽇は、友達が欲しくて登壇しに来たので、優しく⾒守ってください🙏 
 同じように悩んでいる⼈いれば、 
 #jawsdays , #jd

    20 1 9 _e のハッシュタグ付けてつぶやいてもいいし、 
 本セッションが終わった後に、登壇者に話しかけてくれると喜びます☺ 
 本セッションが終わった後に、より多くの様々な議論が⽣まれてくれれば幸いです🙏
  7. 1 .Introduction 所属する会社 / 組織について 2 .History of the Organization

    インフラ組織としての歩みと課題について 3 .Organizational Reliability Engineering ORE / AWS W-A / CA W-Aについて ORE / CA W-Aの今後について 4 .Summary 伝えたかったこと
  8. 所属する会社について • 株式会社サイバーエージェント 巷では、CAって呼ばれています • 従業員数(連結)は、約5,000⼈ • 事業について - メディア事業

    - スタートアップ(新規)事業 - ゲーム事業 - インターネット広告事業 • 今年の春に、オフィス移転予定 グループ全体ではなく、⼀部事業部
  9. インフラ組織としての歩みと課題 • SREとしての活動を始める(2016年〜) Site Reliability Engineeringの哲学を学ぶ - Google SREとのディスカッション -

    Site Reliability Engineeringに関する書籍の輪読会 - Site Reliability Engineering - The Site Reliability Workbook - 以下の4つの分類を中⼼に学んでいった - Software Engineering - System Engineering - Overhead - Toil
  10. インフラ組織としての歩みと課題 • SREやろうとしたけど(2017年〜) 感じた課題 信頼性を担保することのメリットが分かりづらい - そもそも、誰に対しての信頼性なのか?🤔 - エンジニア層に対して? -

    ビジネス層に対して? - ユーザ層に対して? 
 そもそも現状のリスクが可視化できていないし、優先度も共通認識されていない - 何がしたかったのか? - 何でしたいのか?
  11. インフラ組織としての歩みと課題 • もっと根本的な組織課題について考える(2017年〜) ⽬⽴ったやつが評価される - 本当に⼤事かもしれないけど、不満が⽣まれやすい それぞれが、⼤事なことやってると思ってる - 組織にとって⼤事なこと(優先度含め)が、定義されてないから評価されにくい -

    ⾃分ではそこが定義できない(マネージャとかに委ねたい) - 最悪、評価されないから退職リスクもあΔ😱 横断組織メリットがあるというが、誰もそのメリットが最⼤化できる組織にしていない - 横断組織とか⾔いつつ、狭い枠の中(所属する組織)でしか仕事してない - 結果メリット出せなくて、横断組織いらないってなりがち😱
  12. インフラ組織としての歩みと課題 • 改めて、横断組織のメリットを考える(2017年〜) 横断組織としての強みは - インフラ視点として考えるなら、 - 多種多様なサービスに関わってるからこそのナレッジ - そのナレッジがあるから、サービス全体の信頼性を底上げできる

    - 我々がすべきなのは、System Architectureの信頼性に対してのアプローチなのでは 他にも⼤事なこと - そもそも事業会社だったら、サービスの成⻑視点で考えるべき - Service Architectureの信頼性を最⼤値を伸ばすアプローチ
  13. インフラ組織としての歩みと課題 • ⾃分達の組織に適⽤する(2018年〜) Site Reliability Engineeringの哲学を、2つの属性にわける - System Architecture Reliability

    - 横断組織としてサービスの信頼性を担保するロール - 多種多様なメディアサービス全体の信頼性の底上げをする - Service Architecture Reliability - 特定サービスの専任としてのアプローチするロール - サービスの信頼性の最⼤値を伸ばす - もっと知りたいという⼈は、 Software Design 20 19 年2⽉号 - SRE特集 - を読んで下さい🙇 でも、現状のSRGの組織状態では、難しいとも感じた
  14. インフラ組織としての歩みと課題 • 改めて、横断組織の強みとすべきことを考える(2018年〜) なぜ出来てないのか🤔 - ⽬標(ビジョン)の共有ができておらず、すべきことが可視化できてない - 雰囲気でなく、スコープや現状‧ニーズを共通認識持てるようにする必要がある - 可視化できてれば、必要なロールもわかるし、それを作ることもできる

    - 個⼈的には、インフラエンジニアとか SRE はロールが⼤きすぎる 
 - 組織間のコミュニケーションが⾜りていない - ⽬標(ビジョン)が明確じゃないから、コミュニケーションの壁も感じている - 結果、ナレッジの共有ができない🙅 これらのことを踏まえ、OREというロールを作ることにしました
  15. OREとは • 4つの信頼性の層 Corporation(会社) ← IR(Investor Relations) ⇅ Customer(顧客) ←

    CRE(Customer Reliability Engineering) ⇅ Cooperation(連携)← ORE(Organizational Reliability Engineering) ⇅ ↑横断組織だからͦ͜ͷඞཁੑ💪 Service(サービス) ← SRE(Site Reliability Engineering)
  16. OREとは • ミッション 組織的な信頼性向上のために頑張るエンジニア 組織全体としてのナレッジが最⼤化されサービスへ還元できている状態にする - 横断組織のインフラエンジニア だからこそ持っているナレッジを適切に提供する 事業部レベルでのシステムリスクが共通認識できている状態にする -

    サービスの抱える課題を優先度やスコープとそのメリットも含めて、可視化する - 組織間コミュニケーションを活発化させる🤝 サービス成⻑へつながる技術戦略が作れている状態にする - ⾃分達のバックグラウンド的には、System Architectureの視点がやりやすい
  17. AWS W-A について • AWS Well-Architected Framework(AWS W-A)とは AWSをユーザ向けに10年以上に提供した上で得られた経験を元に、 


    提供してくれているシステム設計‧運⽤の “⼤局的な” 考え⽅とベストプラクティス集 AWS W-Aの構成要素のホワイトペーパーや確認質問集も定期的に更新されている AWSのソリューションアーキテクト(AWS W-A認定パートナー)も構成要素に含まれている 最近では、AWS Well-Architected Tool も発表され、セルフチェックをすることも可能に 2018/02時点では、⽇本語対応はされていません
  18. AWS W-A について • ホワイトペーパーについて 5つの柱(ホワイトペーパーの構成) - 運⽤の優秀性 - セキュリティ

    - 信頼性 - パフォーマンス効率 - コスト最適化 ※ 2019/02時点 
 最近では… IoT や Serverless 向けのホワイトペーパーも出ている より詳しく知りたい⼈は、公式サイトを⾒てください
  19. AWS W-A について • よくある誤解 AWS W-A をやればええ感じに出来ると思っている あくまで設計 “原則”

    なので、実装の詳細やアーキテクチャパターンは扱っていない AWS W-A は、銀の弾丸ではない🙅 監査(Audit)的な使い⽅が出来ると思っている 現状を知るのには使えるが、監査的な使い⽅は望ましくない AWS W-A をすれば OK ではなく、そこからどうやっていくかを⼀緒に考えることが⼤切 ガバナンスのインプットには使えると思っている(個⼈的⾒解) ⼀回やればOKだと思っている AWS W-A は定期的に実施する必要がある AWS W-A のフロー(チェック‧改善)を継続的にまわすことが重要
  20. AWS W-A について • 実際に AWS W-A を試してみて AWS W-Aを試してみた、サービスの⼈からの意⾒👂

    - 運⽤周りのヒントをもらったので、それをもとに改善していこうと思えた👍 - どういったセキュリティリスクがあるかを認識することができた👍 などのポジティブな意⾒をもらいつつも… ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、 弊社担当のソリューションアーキテクトによる実施の話になります。
  21. AWS W-A について • 実際に AWS W-A を試してみて AWS W-Aを試してみた、サービスの⼈からの意⾒👂

    - 複数項⽬からの選択式なので、項⽬によっては回答が難しい - 実際に課題は分かったけど、事業レベルでどう改善を進めていけば良いかわからない - 定期的にセルフチェックしたい という声も、多数ありました。 また、弊社ではAWS以外のプラットフォームも活⽤しているので、 同じ様なアプローチが出来ないかと思うようになり、 プラットフォームに依存しない Well-Architected Frameworkを作ることにしました。 ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、 弊社担当のソリューションアーキテクトによる実施の話になります。
  22. CA W-A について • CA Well-Architected Framework(CA W-A)とは - AWS

    W-Aを元に作成した、プラットフォームに依存しない汎⽤的なフレームワーク - 質を落とさないようにしつつ、回答のハードルを下げる - 複数項⽬からの選択式ではなく、Yes/No だけで判定できる⽅法を採⽤ - 回答しづらい項⽬は削除するなど、質問数を可能な限り削減 - 内製だからできるカスタマイズ - Google App Script で⾃動集計 & 解析や Slack 通知を実施してくれる Bot を⽤意 - ヒアリングシートの管理 & 運⽤を⾃動化 - Review Report(レビュー結果)の Suggestion - 社内ナレッジを適切に共有することが可能
  23. CA W-A について • サービスの今を⾒つめ直すための新たなライフサイクルを⽣み出す 学習 Condition Review 測定 Condition

    Review 改善/事業貢献 Improvement コミュニケーション Review Report Discussion & Planning 1 2 3 4
  24. CA W-A について • 実際に、CA W-Aを試してみたサービスからの声 - AWS以外のプラットフォームでも⾏えるのは嬉しい - 現状のサービスが抱えている潜在的なリスクの可視化ができる

    - 現状課題に対して、事業部全体で共通認識を持てる - 事業部にとって何をすればいいのかを考えるときの資料として活⽤できる - 社内に存在するナレッジを活⽤できるようになる - 知らなかったことを知れたり、それによる議論などが⽣まれる🗣
  25. CA W-A の実施フロー CONDITION REVIEW 事前にサービスの コンディションチェック 01 START REVIEW

    REPORT ORE とサービスの技術責任者で 2時間レビュー会を実施 02 DISCUSSION & PLANNING 事業責任者 & 技術責任者と 課題の認識合わせ 03
  26. REVIEW REPORT • Googleドキュメントを利⽤している - Overall Result(全体的な結果) - 各優先度の合計数を表⽰ -

    Pillar Results(詳細結果) - ⼤枠毎に優先度の数を表⽰ - Suggestion(改善案 or 参考資料) - 優先度が⾼い順に表⽰ - 現在、試⾏錯誤を繰り返しています
  27. DISCUSSION&PLANNING • CA W-Aフローの中でこのステップが⼀番重要になる 責任者との現状を理解した上での改善計画を⽴てるためには、 以下を明確にしないといけない - 何が問題なのか - 問題に対しての利害関係者は誰なのか

    - 問題箇所の技術領域に詳しいのは誰なのか - 問題を解決する上で誰が責任者になるのか 特に、 何が問題なのか と 責任者 が明確になっていないと、 次のステップの Improvement(改善) を着⼿することは⾮常に難しい
  28. IMPROVEMENT • どうやって改善を進めるのか Review Report の Suggestion が重要になる 組織として持っているナレッジ(ベストプラクティスやモジュールの提供など)を 効率的に提供する為に、複数サービスでのCA

    W-Aレビューの結果をもとに、 傾向的に早く提供した⽅が良いものから準備を進めている どういった Suggestion をしてるのか - ベストプラクティス集 - ECS, CI/CD … - Terraform の共通モジュール - Ansible の共通 Playbook - オペレーション周りの⾃動化ツール - and more …
  29. IMPROVEMENT • CA W-Aとは何なのか? CA W-Aは、コミュニケーションツールだと考えています🤝 ただ、チェックするのが⽬的ではなく 技術から事業成⻑を促すためのコミュニケーションツール💪 として考えています CA

    W-Aについて、もっと詳しく知りたいという⼈は、 CA BASE CAMPという社内カンファレンスに登壇した資料を後⽇アップ予定なので、 是⾮それを⾒てください🙏
  30. OREの今後について • CA W-Aは、始まりに過ぎない 横断的なアプローチなので、 System Architecture Reliability の要素が⼤きい •

    我々がやるべきことは、まだ沢⼭ある サービスの信頼性の最⼤値を伸ばす、 Service Architecture Reliability 的な アプローチをいかに実践していくかが⼤事 ビジネスKPIに紐づくSLI/SLOの策定と計測をサポートする為のフレームワークも作成予定 そのために、SRGに所属するインフラエンジニア を適切なロールに細分化することも 
 考えています。
  31. Special Thanks • JAWS DAYS 2019 Stu ff 🙇 本当に感謝しかないです🙌

    • ORE Team Shonosuke Okada(@rm_rf_slant) • AWS Well-Architected Team and Japan AWS Team いつも⼤変お世話になってます🙌