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
570
自己完結な開発者組織を支える プラットフォーム作り
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、田中の資料です。
Recruit
PRO
March 07, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
問題解決に役立つ数理工学
recruitengineers
PRO
7
2.2k
Curiosity & Persistence
recruitengineers
PRO
2
120
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
250
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
100
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
95
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
150
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
2
81
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
92
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
97
Other Decks in Technology
See All in Technology
ウェブアクセシビリティとは
lycorptech_jp
PRO
0
260
アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点
flatt_security
32
11k
caching_sha2_passwordのはなし
boro1234
0
220
非エンジニアにも伝えるメールセキュリティ / Email security for non-engineers
ykanoh
13
3.9k
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
110
大規模サービスにおける カスケード障害
takumiogawa
1
210
お問い合わせ対応の改善取り組みとその進め方
masartz
1
370
AIエージェント完全に理解した
segavvy
4
270
Redefine_Possible
upsider_tech
0
260
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
19
18k
大規模プロジェクトにおける 品質管理の要点と実践 / 20250327 Suguru Ishii
shift_evolve
0
280
Symfony in 2025: Scaling to 0
fabpot
2
190
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Code Review Best Practice
trishagee
67
18k
Scaling GitHub
holman
459
140k
Agile that works and the tools we love
rasmusluckow
328
21k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
The Cult of Friendly URLs
andyhume
78
6.3k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
The Pragmatic Product Professional
lauravandoore
33
6.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
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の活動 • フィードバックを得て取り組み方を常に見直し続けること
自己完結チームが プロダクトを素早く安全に届け続けるための プラットフォームと文化を作る