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を活用しているメディアサービスの立ち上げ・改善のサポートや、組織作りなどにも取り組む。

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. 良かったらいいねして下さいw • サイバーエージェント公式デベロッパーブログ https://developers.cyberagent.co.jp/blog/archives/ 19224 /
6. 本セッションの内容 • 本セッションで話すこと📢 - ⾃分が所属する横断的インフラ組織がどんな悩みを抱えながら歩んでいるのか - OREというロールをなぜ作ったのか、そもそもどういったロールなのか - なぜ、独⾃でWell-Architected Framework（CA W-A）を作っているのか - Well-Architected Frameworkにどんな可能性を感じているのか • 本セッションでの注意⚠ 技術的なことは話しません🙇 CA W-Aは、現時点では試作段階であり、本セッションにおける発⾔は、 所属するチームとしての⾒解であり、会社全体の意向ではありません🙏
7. 登壇者からのお願い • 本セッションへのお気持ち 今⽇は、友達が欲しくて登壇しに来たので、優しく⾒守ってください🙏 
 同じように悩んでいる⼈いれば、 
 #jawsdays , #jd 20 1 9 _e のハッシュタグ付けてつぶやいてもいいし、 
 本セッションが終わった後に、登壇者に話しかけてくれると喜びます☺ 
 本セッションが終わった後に、より多くの様々な議論が⽣まれてくれれば幸いです🙏
8. 1 .Introduction 所属する会社 / 組織について 2 .History of the Organization インフラ組織としての歩みと課題について 3 .Organizational Reliability Engineering ORE / AWS W-A / CA W-Aについて ORE / CA W-Aの今後について 4 .Summary 伝えたかったこと
9. Introduction
10. 所属する会社について
11. 所属する会社について • 株式会社サイバーエージェント 巷では、CAって呼ばれています • 従業員数（連結）は、約5,000⼈ • 事業について - メディア事業 - スタートアップ（新規）事業 - ゲーム事業 - インターネット広告事業 • 今年の春に、オフィス移転予定 グループ全体ではなく、⼀部事業部
12. 所属する会社について • CAのエンジニア⽂化 与えられる裁量とそれに対する責任も⼤きい ネイティブエンジニアから、サーバサイドエンジニアへ転向するなども出来る CAグループ内での移動も出来るので、違う業種のサービスも関わることが出来る CAに興味ある⼈は、ZEHI !! https://www.wantedly.com/companies/cyberagent ⾃分のチームも絶賛募集中です！少しでも興味あるって⼈は気軽に声かけて下さい🙏 https://www.wantedly.com/projects/ 20 8 915
13. 所属する組織について
14. 所属する組織について • 技術本部とは 社内でメディア管轄と呼ばれているサイバーエージェントグループのメディア事業や 
 スタートアップ（新規）事業のサービスに対して横断的なサポートなどをしている組織 共通基盤や秋葉原ラボ、Private Cloudなども、この組織に属している
15. • メディア管轄のサービス（⼀部抜粋） 所属する組織について
16. 所属する組織について • サービスリライアビリティグループとは メディア管轄のサービスのインフラ領域を横断的にサポートしているグループ Service Reliability Groupの頭⽂字を取って、SRGと呼ばれている 主に、既存サービスの改善や新規⽴ち上げなどを⾏なっている ⼗数⼈で、⼤⼩合わせて200弱のサービス‧システムをサポートしている💪 SRG内には、いくつかのチームがある
17. 所属する組織について • メディア管轄とSRGの相関図
18. History of the Organization
19. インフラ組織としての歩みと課題
20. インフラ組織としての歩みと課題 • SRGの前⾝となるインフラ組織（〜2015年） 会社の歴史と共に、組織の形態を変えていた - 今のSRGのように横断組織の時もあれば、サービス付の時代もあった - 昔ながらのインフラ屋的なオンプレ時代 - ⾃前のオンプレミス環境 - サーバのラッキングやミドルウェアのセットアップをしていた - Private CloudやPublic Cloudへとシフト（2012年〜） - Private Cloud専属チームの結成 - Public Cloudの利⽤が徐々に拡⼤
21. インフラ組織としての歩みと課題 • SRGの前⾝となるインフラ組織（〜2015年） インフラチームの働き⽅も、以下のような責務に変わっていった - Provisioning - Infrastructure as a Code , Deploy pipeline - Scalability - Capacity Planning - Performance - DB/App Tuning , Stress Test - Monitoring - On-Call - Security
22. インフラ組織としての歩みと課題 • SRGとしての始まり（2015年〜） この頃、横断組織のインフラエンジニアとしてのアプローチにもどかしさを感じていた - もっとプロダクトに貢献できるんじゃないのか 信頼性を軸としたプロダクト貢献をする組織に変わるべく… SREを⽬指そうと、組織名をサービスリライアビリティグループに変更しました きっかけは、SREが流⾏り始めてたので、その流れに乗った感じです🏄
23. インフラ組織としての歩みと課題 • SREとしての活動を始める（2016年〜） Site Reliability Engineeringの哲学を学ぶ - Google SREとのディスカッション - Site Reliability Engineeringに関する書籍の輪読会 - Site Reliability Engineering - The Site Reliability Workbook - 以下の4つの分類を中⼼に学んでいった - Software Engineering - System Engineering - Overhead - Toil
24. インフラ組織としての歩みと課題 • SREとしての活動を始める（2016年〜） Site Reliability Engineeringの哲学を学ぶ 学んだことを元に、以下の取り組みなどを進めていきました - Toil撲滅運動（50%ルール） - Postmortem - Runbook - On-boardingプロセス - 障害対応フローの再設計（On-Callへ向けて） - SRGとしてのSREの再定義
25. インフラ組織としての歩みと課題 • SREやろうとしたけど（2017年〜） 結果どうだったのか SREに名前を変えただけ😇 - 横断組織で、メディア組織全体としての信頼性を担保するSREにはなれなかった - 直接的なサービスの信頼性向上という意味では、インフラエンジニアの時と変化がなかった 感じた課題 横断組織として網羅的なアプローチが難しい😥 - SRGのメンバーの10倍以上の多種多様なメディアサービス数 - サービス毎に技術スタックも異なる
26. インフラ組織としての歩みと課題 • SREやろうとしたけど（2017年〜） 感じた課題 信頼性を担保することのメリットが分かりづらい - そもそも、誰に対しての信頼性なのか？🤔 - エンジニア層に対して？ - ビジネス層に対して？ - ユーザ層に対して？ 
 そもそも現状のリスクが可視化できていないし、優先度も共通認識されていない - 何がしたかったのか？ - 何でしたいのか？
27. インフラ組織としての歩みと課題 • もっと根本的な組織課題について考える（2017年〜） ⽬⽴ったやつが評価される - 本当に⼤事かもしれないけど、不満が⽣まれやすい それぞれが、⼤事なことやってると思ってる - 組織にとって⼤事なこと（優先度含め）が、定義されてないから評価されにくい - ⾃分ではそこが定義できない（マネージャとかに委ねたい） - 最悪、評価されないから退職リスクもあΔ😱 横断組織メリットがあるというが、誰もそのメリットが最⼤化できる組織にしていない - 横断組織とか⾔いつつ、狭い枠の中（所属する組織）でしか仕事してない - 結果メリット出せなくて、横断組織いらないってなりがち😱
28. インフラ組織としての歩みと課題 • 改めて、横断組織のメリットを考える（2017年〜） 横断組織としての強みは - インフラ視点として考えるなら、 - 多種多様なサービスに関わってるからこそのナレッジ - そのナレッジがあるから、サービス全体の信頼性を底上げできる - 我々がすべきなのは、System Architectureの信頼性に対してのアプローチなのでは 他にも⼤事なこと - そもそも事業会社だったら、サービスの成⻑視点で考えるべき - Service Architectureの信頼性を最⼤値を伸ばすアプローチ
29. インフラ組織としての歩みと課題 • ⾃分達の組織に適⽤する（2018年〜） Site Reliability Engineeringの哲学を、2つの属性にわける - System Architecture Reliability - 横断組織としてサービスの信頼性を担保するロール - 多種多様なメディアサービス全体の信頼性の底上げをする - Service Architecture Reliability - 特定サービスの専任としてのアプローチするロール - サービスの信頼性の最⼤値を伸ばす - もっと知りたいという⼈は、 Software Design 20 19 年2⽉号 - SRE特集 - を読んで下さい🙇 でも、現状のSRGの組織状態では、難しいとも感じた
30. インフラ組織としての歩みと課題 • 改めて、横断組織の強みとすべきことを考える（2018年〜） なぜ出来てないのか🤔 - ⽬標（ビジョン）の共有ができておらず、すべきことが可視化できてない - 雰囲気でなく、スコープや現状‧ニーズを共通認識持てるようにする必要がある - 可視化できてれば、必要なロールもわかるし、それを作ることもできる - 個⼈的には、インフラエンジニアとか SRE はロールが⼤きすぎる 
 - 組織間のコミュニケーションが⾜りていない - ⽬標（ビジョン）が明確じゃないから、コミュニケーションの壁も感じている - 結果、ナレッジの共有ができない🙅 これらのことを踏まえ、OREというロールを作ることにしました
31. Organizational 
 Reliability 
 Engineering
32. OREとは
33. OREとは • そもそも信頼性とは？ とりあえず、Wikipediaで調べてみた👀 なるほど、じゃあ⾃分達が考える必要がある信頼性って何なんだろうか？🤔
34. OREとは • 4つの信頼性の層 Corporation（会社） ← IR（Investor Relations） ⇅ Customer（顧客） ← CRE（Customer Reliability Engineering） ⇅ Cooperation（連携）← ORE（Organizational Reliability Engineering） ⇅ ↑横断組織だからͦ͜ͷඞཁੑ💪 Service（サービス） ← SRE（Site Reliability Engineering）
35. OREとは • ミッション 組織的な信頼性向上のために頑張るエンジニア 組織全体としてのナレッジが最⼤化されサービスへ還元できている状態にする - 横断組織のインフラエンジニア だからこそ持っているナレッジを適切に提供する 事業部レベルでのシステムリスクが共通認識できている状態にする - サービスの抱える課題を優先度やスコープとそのメリットも含めて、可視化する - 組織間コミュニケーションを活発化させる🤝 サービス成⻑へつながる技術戦略が作れている状態にする - ⾃分達のバックグラウンド的には、System Architectureの視点がやりやすい
36. OREとは • 要は、こういうこと ⽬的が明確化されてて、それに向かってのアクションが取りやすい状況 課題の可視化 ↓ 共通認識（優先順位‧スコープ） ↓ アクションが取れる状態（ナレッジを適切に提供） ↓ サービス成⻑へコミットできる System Architectureって視点だと、 AWS Well-Architected Framework とか良さそうだと思い、試すことにしました
37. AWS W-Aについて
38. 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時点では、⽇本語対応はされていません
39. AWS W-A について • ホワイトペーパーについて 5つの柱（ホワイトペーパーの構成） - 運⽤の優秀性 - セキュリティ - 信頼性 - パフォーマンス効率 - コスト最適化 ※ 2019/02時点 
 最近では… IoT や Serverless 向けのホワイトペーパーも出ている より詳しく知りたい⼈は、公式サイトを⾒てください
40. AWS W-A について • よくある誤解 AWS W-A をやればええ感じに出来ると思っている あくまで設計 “原則” なので、実装の詳細やアーキテクチャパターンは扱っていない AWS W-A は、銀の弾丸ではない🙅 監査（Audit）的な使い⽅が出来ると思っている 現状を知るのには使えるが、監査的な使い⽅は望ましくない AWS W-A をすれば OK ではなく、そこからどうやっていくかを⼀緒に考えることが⼤切 ガバナンスのインプットには使えると思っている（個⼈的⾒解） ⼀回やればOKだと思っている AWS W-A は定期的に実施する必要がある AWS W-A のフロー（チェック‧改善）を継続的にまわすことが重要
41. AWS W-A について • もっとAWS W-Aを知りたい⼈におすすめの資料 AWS Black Belt Online Seminar ＆ 公式ドキュメント（英語）
42. AWS W-A について • 実際に AWS W-A を試してみて AWS W-Aを試してみた、サービスの⼈からの意⾒👂 - 運⽤周りのヒントをもらったので、それをもとに改善していこうと思えた👍 - どういったセキュリティリスクがあるかを認識することができた👍 などのポジティブな意⾒をもらいつつも… ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、 弊社担当のソリューションアーキテクトによる実施の話になります。
43. AWS W-A について • 実際に AWS W-A を試してみて AWS W-Aを試してみた、サービスの⼈からの意⾒👂 - 複数項⽬からの選択式なので、項⽬によっては回答が難しい - 実際に課題は分かったけど、事業レベルでどう改善を進めていけば良いかわからない - 定期的にセルフチェックしたい という声も、多数ありました。 また、弊社ではAWS以外のプラットフォームも活⽤しているので、 同じ様なアプローチが出来ないかと思うようになり、 プラットフォームに依存しない Well-Architected Frameworkを作ることにしました。 ⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、 弊社担当のソリューションアーキテクトによる実施の話になります。
44. CA W-Aについて
45. CA W-A について • CA Well-Architected Framework（CA W-A）とは - AWS W-Aを元に作成した、プラットフォームに依存しない汎⽤的なフレームワーク - 質を落とさないようにしつつ、回答のハードルを下げる - 複数項⽬からの選択式ではなく、Yes/No だけで判定できる⽅法を採⽤ - 回答しづらい項⽬は削除するなど、質問数を可能な限り削減 - 内製だからできるカスタマイズ - Google App Script で⾃動集計 & 解析や Slack 通知を実施してくれる Bot を⽤意 - ヒアリングシートの管理 & 運⽤を⾃動化 - Review Report（レビュー結果）の Suggestion - 社内ナレッジを適切に共有することが可能
46. CA W-A について • ⼤枠は、AWS W-Aと同じ5つの柱 合計75の項⽬を回答することにより、現状のサービスの状態を紐解く - Security - Reliability - Performance - Cost Optimization - Operations
47. CA W-A について • サービスの今を⾒つめ直すための新たなライフサイクルを⽣み出す 学習 Condition Review 測定 Condition Review 改善/事業貢献 Improvement コミュニケーション Review Report Discussion & Planning 1 2 3 4
48. CA W-A について • 実際に、CA W-Aを試してみたサービスからの声 - AWS以外のプラットフォームでも⾏えるのは嬉しい - 現状のサービスが抱えている潜在的なリスクの可視化ができる - 現状課題に対して、事業部全体で共通認識を持てる - 事業部にとって何をすればいいのかを考えるときの資料として活⽤できる - 社内に存在するナレッジを活⽤できるようになる - 知らなかったことを知れたり、それによる議論などが⽣まれる🗣
49. CA W-Aの実施フロー
50. CA W-A の実施フロー CONDITION REVIEW 事前にサービスの コンディションチェック 01 START REVIEW REPORT ORE とサービスの技術責任者で 2時間レビュー会を実施 02 DISCUSSION & PLANNING 事業責任者 & 技術責任者と 課題の認識合わせ 03
51. CA W-A の実施フロー IMPROVEMENT 浮上した課題を実際に改善し、 互いに事業を成⻑させていく 04 半年後に 01 から再度実施
52. CA W-A の実施フロー 01 CONDITION REVIEW
53. CONDITION REVIEW • ヒアリングシートについて サービスのコンディションをチェックする質問集✍ 権限管理や運⽤のしやすさを考慮し、Googleスプレッドシートで管理 Google App Scriptを使って、レビュー結果の⾃動集計や解析もしている
54. CONDITION REVIEW • ヒアリングシートについて スプレッドシートをカスタマイズし、簡易的なレビュー結果をSlackへ通知 ポ チ ッ
55. CA W-A の実施フロー 02 REVIEW REPORT
56. REVIEW REPORT • Googleドキュメントを利⽤している - Overall Result（全体的な結果） - 各優先度の合計数を表⽰ - Pillar Results（詳細結果） - ⼤枠毎に優先度の数を表⽰ - Suggestion（改善案 or 参考資料） - 優先度が⾼い順に表⽰ - 現在、試⾏錯誤を繰り返しています
57. CA W-A の実施フロー 03 DISCUSSION & PLANNING
58. DISCUSSION＆PLANNING • CA W-Aフローの中でこのステップが⼀番重要になる 責任者との現状を理解した上での改善計画を⽴てるためには、 以下を明確にしないといけない - 何が問題なのか - 問題に対しての利害関係者は誰なのか - 問題箇所の技術領域に詳しいのは誰なのか - 問題を解決する上で誰が責任者になるのか 特に、 何が問題なのか と 責任者 が明確になっていないと、 次のステップの Improvement（改善） を着⼿することは⾮常に難しい
59. CA W-A の実施フロー 04 IMPROVEMENT
60. IMPROVEMENT • どうやって改善を進めるのか Review Report の Suggestion が重要になる 組織として持っているナレッジ（ベストプラクティスやモジュールの提供など）を 効率的に提供する為に、複数サービスでのCA W-Aレビューの結果をもとに、 傾向的に早く提供した⽅が良いものから準備を進めている どういった Suggestion をしてるのか - ベストプラクティス集 - ECS, CI/CD … - Terraform の共通モジュール - Ansible の共通 Playbook - オペレーション周りの⾃動化ツール - and more …
61. IMPROVEMENT • CA W-Aとは何なのか？ CA W-Aは、コミュニケーションツールだと考えています🤝 ただ、チェックするのが⽬的ではなく 技術から事業成⻑を促すためのコミュニケーションツール💪 として考えています CA W-Aについて、もっと詳しく知りたいという⼈は、 CA BASE CAMPという社内カンファレンスに登壇した資料を後⽇アップ予定なので、 是⾮それを⾒てください🙏
62. CA W-Aの今後について
63. CA W-A の今後について ⾃動で前回のレビュー結果と⽐較し、再集計までしてくれる機能の追加 提案できる情報の最⼤化 AWS W-A Tool のロードマップによっては、統合も検討
64. CA W-A の今後について • AWS W-A Toolが、AWS以外でも使えるように㊗
65. OREの今後について
66. OREの今後について • CA W-Aは、始まりに過ぎない 横断的なアプローチなので、 System Architecture Reliability の要素が⼤きい • 我々がやるべきことは、まだ沢⼭ある サービスの信頼性の最⼤値を伸ばす、 Service Architecture Reliability 的な アプローチをいかに実践していくかが⼤事 ビジネスKPIに紐づくSLI/SLOの策定と計測をサポートする為のフレームワークも作成予定 そのために、SRGに所属するインフラエンジニア を適切なロールに細分化することも 
 考えています。
67. OREの今後について • 今更ですがOREの⽬指すビジョンについて 我々は、Curiosity をテーマに掲げています - 好奇⼼が湧く（ワクワクする）ことが出来る組織を⽬指そう！ - その組織を⽬指している⾃分達も、好奇⼼をもって取り組もう！
68. Summary
69. 伝えたかったこと
70. 伝えたかったこと • ⽬標（ビジョン）明確化しましょう！ 明確化されてないと、アクション取りづらくないですか？ 多くの組織における⽬標は、サービス成⻑させて、会社も成⻑させることじゃないかと そのために、もっとコミュニケーションしていきましょう🗣 Well-Architected Frameworkは、⼀つの⼿段として使えるもの🙆 分散されているナレッジの蓄積や共有を適切に⾏うこともできる AWSでサービス運⽤してるなら、AWS W-Aは使わない理由はない • すべきことをベースにロール（役割）も考えてほしい 本当に必要なロールは何なのか？🤔 ないなら、⾃分達で宣⾔してもいい🙆 だから、ORE作りました💪
71. 伝えたかったこと • ワクワクして働ける場を作ろう！ 結局はこれのために、組織について議論するのでは… みんなが納得いく評価制度を作るのは難しいけど、そんな環境は作れるはず そしたら、⼈事に⾔われなくても、リファラル採⽤やりますよね🙆 • AWS系のカンファレンスなので… フィードバックとか、フューチャーリクエストどんどん投げましょ🗣 それで、もっとディスカッションしていきましょ！ ⾃分達も AWS W-A 含め何かしらの形で、今後もコントリビュートしていくお気持ちです！
72. 最後に
73. Special Thanks • JAWS DAYS 2019 Stu ff 🙇 本当に感謝しかないです🙌 • ORE Team Shonosuke Okada（@rm_rf_slant） • AWS Well-Architected Team and Japan AWS Team いつも⼤変お世話になってます🙌
74. Every day is still Day One :) - 我々のチャレンジは続く -
75. ご静聴ありがとうございました🙇