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
420
自己完結な開発者組織を支える プラットフォーム作り
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、田中の資料です。
Recruit
PRO
March 07, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
SIerでの経験が活きた!『SUUMO』『ゼクシィ』担当PdMの企画プロセスを紐解く〜プロデザ!〜
recruitengineers
PRO
0
68
事業目的とのプロトコル変換
recruitengineers
PRO
4
96
Boosting Hotel Profits: The Power of Enhanced Cancellation Predictions
recruitengineers
PRO
3
670
ヘルススコアの改善の過程で起きた嬉しい変化
recruitengineers
PRO
4
720
スクラム開発導入による 他組織を巻き込んだ開発生産性向上の取り込み
recruitengineers
PRO
3
380
大公開!SUUMOの裏側 -データ組織の取り組みLT会-
recruitengineers
PRO
4
120
FIFOキューで実現する Spring Bootの非同期処理とその性能評価方法
recruitengineers
PRO
5
160
組合せ最適化による問題解決の実践的アプローチ
recruitengineers
PRO
8
1.4k
社内のAI活用事例と活用促進のための取り組みを大公開!
recruitengineers
PRO
4
710
Other Decks in Technology
See All in Technology
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
180
20240724_cm_odyssey_hibiyatech
hiashisan
0
110
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
270
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 / AI Test Lab vol.1
shift_evolve
0
190
コンテナ・K8s研修 - 前半 コンテナ基礎・ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
120
Azure AI ことはじめ
tsubakimoto_s
0
130
Luupの開発組織におけるインシデントマネジメントの変遷 ver.RoadtoSRENEXT2024
grimoh
1
270
AIエージェントを現場に導入する目線とは
masahiro_nishimi
1
1.5k
データ分析を支える技術 生成AI再入門
ishikawa_satoru
0
380
What is DRE? - Road to SRE NEXT@広島
chanyou0311
3
620
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
506
110k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
90
47k
Bash Introduction
62gerente
607
210k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
28
2.2k
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
23
1.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.3k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Designing Experiences People Love
moore
136
23k
Six Lessons from altMBA
skipperchong
24
3.2k
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の活動 • フィードバックを得て取り組み方を常に見直し続けること
自己完結チームが プロダクトを素早く安全に届け続けるための プラットフォームと文化を作る