責務で考える組織と 第三世代のSRE

2024年12⽉5⽇ SREのリアル｜組織フェーズに合わせたSREの役割とは
の登壇内容です。

Transcript

1. 責務で考える組織と 第三世代のSRE グロービス・デジタル・プラットフォーム SRE 沼⽥重太朗 2024年12⽉5⽇ SREのリアル｜組織フェーズに合わせたSREの役割とは
2. ⾃⼰紹介 沼⽥ 重太朗 株式会社グロービス グロービス・デジタル・プラットフォーム SREチーム チームリーダー（2020〜） 前職までは主に⾦融系インフラエンジニア TerraformやAtlantisが好き @chroju 2
3. グロービス・デジタル・プラットフォームについて 3 ビジネススクールを主体とするグロービスにて2016年発⾜ 育成ノウハウやコンテンツのデジタルサービス化を、マルチプロダクトで推進
4. 今⽇話したいこと 複数事業を展開するグロービスにおいて SREという組織の「責務」をどのように考えてきたか 4
5. SREチームとプロダクトとの関わり 5 GLOBIS 学び放題 GLOPLA LMS ナノ単科 ……etc SRE Auroraバージョン アップしませんか？ 最近、エラー 増えてません？ 新しい インフラ欲しい IAM user ください Argo CD 動かないです SaaSの利⽤料⾦ 先⽉⾼いなぁ…… 脆弱性の ニュースが出てる！ 503出てるけど 何かわかります？
6. 組織設計の⼀般論で考える 『チームトポロジー』でのキーは認知負荷とコミュニケーション “チームトポロジーでは、チームの認知負荷を制限し、 チーム間のコミュニケーションを明確に設計する必要がある。 “ （マシュー・スケルトン, マニュエル・パイス 著, 原⽥ 騎郎, 永瀬 美穂, 吉⽻ ⿓太郎 訳. チームトポロジー. ⽇本能率協会マネジメントセンター. 2021. “Chapter 1 組織図の問題”より） 6
7. SREチームにチームトポロジーを当てはめると？ 7 GLOBIS 学び放題 GLOPLA LMS ナノ単科 ……etc SRE Auroraバージョン アップしませんか？ 最近、エラー 増えてません？ 新しい インフラ欲しい IAM user ください Argo CD 動かないです SaaSの利⽤料⾦ 先⽉⾼いなぁ…… 脆弱性の ニュースが出てる！ 503出てるけど 何かわかります？ 増えていく プロダクトの 認知負荷 担当範囲の 広さによる 認知負荷 多くのチームとの コミュニケーション
8. 組織が育つにつれて業務は複雑化していく 8 プロダクトが少なく タスクもコミュニケーションパスも多くない プロダクトが増えるほど 認知負荷は増えていく
9. 9 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション
10. 10 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション
11. セルフサービス化、オーナーシップの委譲 プロダクトサイドの⾃律性が⾼まるようイネイブリングしていく 11 503が出ているので 原因調査お願いします レスポンスが遅いから Datadogで調べてみよう 環境変数の値を 変更してください 環境変数を変更したいので Pull Requestを出しました 🤔 SREがボトルネックに成り得る 信頼性はプロダクトの関心にしたい Nice! ✨
12. 委譲のための取り組み 12 コミュニケーションの実績計測
13. 委譲のための取り組み 13 ドキュメンテーション
14. 委譲のための取り組み 14 モブプロ
15. 委譲のための取り組み 15 成熟度モデル（WIP）
16. 16 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション
17. SREの責務を減らす コーポレートIT関連の業務は、ISチームを新設して責務を分ける 17 • AWS • SendGrid • Datadog • GitHub • Docker Hub • AWS • SendGrid • Datadog ISチーム管轄 • GitHub • Docker Hub
18. SRE内部でも責務を細分化する 18 ミッションを限定して、タスクスイッチなどの認知負荷を減らす Platform SRE Collaboration SRE EKS、Datadogなど 効率的なSREingのための プラットフォーム構築 プラットフォーム活⽤や SREプラクティス導⼊を プロダクトサイドと推進
19. 19 1. 増えていくプロダクトの認知負荷 2. 担当範囲が広いことによる認知負荷 3. 多くのチームとのコミュニケーション
20. SREチームのコミュニケーション先 事業との繋がり、横断チーム同⼠の繋がり 20 GLOBIS 学び放題 GLOPLA LMS ナノ単科 ……etc QA SRE IS DevEx 基盤(認証) Product Success
21. プロダクションミーティング 21 特定プロダクトと、全横断チームが⽉に1回⼀堂に会する会議体 元はSRE bookに書かれているプラクティスだが ⾮機能要件上の課題を広く捉えるために Product Successの枠組みで実施 例えばインシデント対応1つ取っても、 信頼性観点=SRE、品質やテスト観点=QAなど 各チームでの役割がある “各チーム個別に連携しているとボールが 落ちる部分もありそうなので、Product Success全体で顔を合わせながら認識を 合わせていくのが⼤事” あるプロダクトでのキックオフの際に 開発サイドから寄せられた発⾔
22. ミクロからマクロまで様々な接し⽅を考える 22 Pull Request モブプロ プロダクション MTG プロジェクトの 組成 定常的に繰り返されるものは 最⼩限のインタラクションへ 置き換える 不確実性が⾼い部分は コミュニケーションを 仕組みとして固定してしまう
23. 23 まとめ
24. おさらい 24 1. 増えていくプロダクトの認知負荷 ⇒SREingの責務を「分散」 2. 担当範囲が広いことによる認知負荷 ⇒チーム境界や責務の再設定 3. 多くのチームとのコミュニケーション ⇒コラボレーションを促す会議体設計
25. The Third Age of SRE 25 “All engineers can wear an SRE hat as part of their job, and at least smaller organizations will then stop hiring dedicated SREs. “ (Björn “Beorn” Rabenstein / Grafana Labs) (Emil Stolarsky, Jaime Woo. 97 Things Every SRE Should Know. O'Reilly Media, Inc. 2020. “Chapter 98. The Third Age of SRE“) 第⼀世代 Googleのみが占有的にSREを実践 第⼆世代 SRE booksによる知識拡散、専任SREの増加 第三世代 すべてのエンジニアが部分的にSREに グロービスSREの⽬指す⽅向性は「第三世代」のSRE
26. 組織設計は終わることなく模索が必要 26 タックマンモデルが描いた統⼀や安定はやってこない（かも） “最近の研究では、このモデルが必ずし も正しくないことがわかってきた。 チームが存続している間、混乱はずっと 続くというものだ。” (チームトポロジー. “Chapter 3 チームファースト思考“ より) 形成期 混乱期 統⼀期 安定期 散会期
27. We are hiring 27 だから⼀緒にやりませんか？