Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
自己完結な開発者組織を支える プラットフォーム作り
Search
Recruit
PRO
March 07, 2024
Technology
4
610
自己完結な開発者組織を支える プラットフォーム作り
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、田中の資料です。
Recruit
PRO
March 07, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
120
問題解決に役立つ数理工学
recruitengineers
PRO
11
2.8k
Curiosity & Persistence
recruitengineers
PRO
2
190
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
410
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
190
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
350
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
360
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
3
200
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
2
260
Other Decks in Technology
See All in Technology
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
5
4k
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
150
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
210
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
260
米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
2
1.2k
急成長を支える基盤作り〜地道な改善からコツコツと〜 #cre_meetup
stefafafan
0
130
Github Copilot エージェントモードで試してみた
ochtum
0
110
Windows 11 で AWS Documentation MCP Server 接続実践/practical-aws-documentation-mcp-server-connection-on-windows-11
emiki
0
1k
【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術
cygames
0
1.1k
GeminiとNotebookLMによる金融実務の業務革新
abenben
0
240
Understanding_Thread_Tuning_for_Inference_Servers_of_Deep_Models.pdf
lycorptech_jp
PRO
0
140
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
370
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
430
65k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Six Lessons from altMBA
skipperchong
28
3.9k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Transcript
自己完結な開発者組織を支える プラットフォーム作り プロダクトディベロップメント室 販促まなび領域プロダクトディベロップメントユニット 田中 京介 (@kyontan)
田中 京介 温泉, 登山, 旅行 経歴 / Career 2021年リクルート新卒入社。SREとして、マッチングサ ービス『ゼクシィ縁結び』や教育系サービス『スタディ
サプリ』および『Quipper』の開発体験の改善やパブリッ ククラウドの活用最適化などに従事。 全社の改善提案制度『Ring Dash』においては、労務部 署と連携し勤怠記録の自動化を実現し初代グランプリを 受賞した。社外でもJANOG 51 や情報科学若手の会など 複数のカンファレンスの運営に携わる 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 販促まなび領域プロダクトディベロップメントユニット 小中高BtoCプロダクト開発部 小中高SREグループ
今日伝えたいこと スタディサプリのSREチームでは、 プロダクトを素早く安全に届けるため、自己完結チームを志向しています • この目標を達成するために、私たちSREは 自己完結チームを支えるプラットフォームと文化をつくっています • プラットフォームと文化という2つの切り口から、 取り組んでいること、その背後にある考えを紹介します
プロダクトについて
PHILOSOPHY プロダクトについて 学びたい、学んでよかったと 思える人を増やすために、 学びをもっと新しく。 CONCEPT
(提供中サービスの一部) プロダクトについて
プロダクトについて 本セッションで扱う範囲
技術的な概要 • マイクロサービスの集合体 • 54のマイクロサービス (as of 2024-02-16) • Ruby:
21, Go: 13, Node.js: 9, Python: 7, Elixir: 2, Rust: 1 • 開発チーム (Team Topologies の用語で分類, 包含関係にあるチームも含む) • Stream-aligned Team: 19 • Complicated Subsystem Team: 1 • Platform (& Enabling): 4 Team Topologies: https://teamtopologies.com/key-concepts
技術的な概要 • コード: monorepoで管理 • ソースコード, Kubernetesマニフェストを単一のGitリポジトリで管理 • GitHub Actions
(with self-hosted runner) + ArgoCD • https://github.com/quipper/monorepo-deploy-actions • Kubernetes Pod数 (≒ コンテナ数): ピーク時で約2,500 • 月間リリース回数: 208 (2024-01-17 - 2024-02-16)
Vision 最高の学習プロダクトを作り続けられる開発組織の実現 Mission 自己完結チームがプロダクトを素早く安全に届け続けるための プラットフォームと文化を作る SREチームの Vision / Mission ブログ記事:
https://blog.studysapuri.jp/entry/sre-vision-mission-values
自己完結チームが プロダクトを素早く安全に届け続けるための プラットフォームと文化を作る
None
自己完結チームとは? スタディサプリの開発チームにおける造語 「自己完結チームとは、 自分たちに必要な問題解決を できる限り自分たちで行うことができる チームである」
なぜ自己完結チームを志向するのか? ユーザーへ、より素早く価値を提供できるはずだから 自己完結であるチームは、たとえば以下のことを達成できる • リリースに必要な手順を全て自分たちだけで完遂できる • 必要なデータベースなどを自分たちでセットアップできる • 問題が生じたとき、それを自分たちで検知し、修正できる
自己完結チームに求められる要素 • 自分たちでサービスが観測可能 (Observable) である • サービスがどのように動いており、今どのような状態にあるのかを自分たちで 把握し、説明できること • 何か問題が生じたときに、それを自分たちで検知し、原因を追求できること
• 自分たちでサービスが制御可能 (Controllable) である • 自分たちが必要なタイミングでサービスがリリースできること • 要求される仕様変更や、トラフィックの増加などの内外要因の 変化に対して、自分たちで対応が可能であること 自己完結チームの実現には、このほかにも多くの要素を満たす必要がある
SREの取り組み プラットフォームをつくる 文化をつくる
SREの取り組み プラットフォームをつくる 文化をつくる
プラットフォームを作る • セルフサービス化を目指す • 開発者はサービスをできる限り自分たちでコントロールできる状態 • SRE はリリースの可否を判断する存在ではない
プラットフォームを作る 手作業は極力避ける。PRを作り、CIが通れば安全である状態 • 10以上の SaaS を単一の terraform repository で管理 •
tfaction による GitOps の実現 • PRを作ればplan結果が表示され, マージすれば apply される • 安全でない・望ましくない設定は CI が通らないように • 誰がレビューしても同じ品質になるように
プラットフォームを作る 開発生産性を向上するための取り組み • qall-k8s • Kubernetes 上にある各開発者向けの独立した環境 VS Codeや RubyMine
等で直接コードを編集でき、即座に反映される • 本番との差分が小さな環境において、高速に開発ができる • Pull Request 環境 • PRごとに独立した検証環境が起動する仕組み • 負荷試験などの検証環境としても活用 ブログエントリ: https://blog.studysapuri.jp/entry/2023/03/17/studysapuri-development (“qall-k8s” で検索)
プラットフォームを作る 開発環境と本番環境の差分を小さくする • 開発用データベースは日次で本番からマスキングして同期 • オブジェクトストレージはマスキングして開発環境へコピー • パフォーマンス問題などに早期に気付くことができる
プラットフォームを作る 可観測性なくしてオーナーシップは生まれない • 定量的な信頼性指標としてのSLOの合意・運用 • より早く問題に気付きたい → SLO burn-rate などの手法を布教
• アクション可能なアラートのみを設定する • 即座に対応しなくてよい問題はオンコールなどの 割込みとは別の枠組みで対応する • 点ではなく線で捉える SLO burn-rate に関するブログエントリ: https://blog.studysapuri.jp/entry/slo-burn-rate-monitoring
プラットフォームを作る 観測可能な多くの情報を Datadog へ集約 リリース回数, GitHub PRのオープン数 CI の実行時間・待ち時間・成功率 AWSのコスト,
AWS Security Hub の非準拠リソース 10分後に試験を受ける予定のユーザー数 (!) … • 多種多様なカスタムメトリクスを収集 • APM や RUM, Continuous Profiler 等も積極的に導入中
SREの取り組み プラットフォームをつくる 文化をつくる
文化をつくる 地道な ”Enabling” の活動 • 開発者にとって身近な存在になる • SREはどうしても権限が強く気軽に聞きづらい存在と認知されがち • 積極的に聞きにいく
• 「最近なにか不満感じてないですか?」「これできたら便利ですか?」 • 困っていそうなチームがいれば積極的にモブしにいく • 「月刊SRE」: 最近の変更などを周知・アピールする
文化をつくる フィードバックを得る • 半年ごとにサーベイを実施し、開発者の 悩み・やりたいことを知る • 「最近困ったことはありますか?」 • 「XXで分からないことがあったらどこから調べますか?」 •
「より自己完結なチームになるために足りていない要素はなんですか?」 • 「プラットフォームにあるXXの機能はどのくらい知っていますか?」 • … • サーベイ→アクション→サーベイ→… のフィードバックループ
文化をつくる 過去の失敗を繰り返さないためにゲートを設ける • 開発設計レビュー • Design Doc等を記述し、アーキテクチャ上の問題などを洗い出す • 最近はチーム横断で、幅広いレビューが行えるように進化 •
Production Readiness Checklist • リリース前に実施する • スケーラビリティや可観測性が備わっているか確認する ブログエントリ: https://blog.studysapuri.jp/entry/2020/01/30/production-readiness-with-all
文化をつくる • 自己完結チームでないチームが、自己完結チームになるために • 自己完結チームが、より自己完結になれるように
まとめ (再掲) スタディサプリのSREチームでは、 プロダクトを素早く安全に届けるため、自己完結チームを志向しています • この目標を達成するために、私たちSREは 自己完結チームを支えるプラットフォームと文化をつくっています • その取り組みの一部や、背景にある考えを紹介しました •
開発者が自分たちでサービスを観測可能 & 制御可能であること • 開発者とコミュニケーションを取り続ける、地道なEnablingの活動 • フィードバックを得て取り組み方を常に見直し続けること
自己完結チームが プロダクトを素早く安全に届け続けるための プラットフォームと文化を作る