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
330
自己完結な開発者組織を支える プラットフォーム作り
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、田中の資料です。
Recruit
PRO
March 07, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
490
プロデザ! BY リクルート vol.18_リクルートのリサーチ実践組織「リサーチブーストコミュニティ」
recruitengineers
PRO
3
320
スマートフォン版サロンボードの 機能改善の土台づくり
recruitengineers
PRO
2
82
事業状況の大きな変化を乗り越えるためのAirレジ オーダーのアジャイル開発
recruitengineers
PRO
1
75
横断組織から見たリクルートのインフラの歴史と目指すべきクラウド活用像
recruitengineers
PRO
1
52
Datadog による 自己完結的アプリケーションモニタリング
recruitengineers
PRO
4
290
プロデザ! BY リクルートvol.17_『じゃらんnet』公式アプリの高速リニューアル事例を大公開
recruitengineers
PRO
6
210
検索エンジニアが考える、 生成AI時代の人間の付加価値とは
recruitengineers
PRO
3
200
エンジニア思考で解決! 家事育児を劇的に進化させる開発プロセス応用術
recruitengineers
PRO
3
140
Other Decks in Technology
See All in Technology
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
1.7k
B2C、B2B プロダクトマネジメントの違い(および思考の罠) / B2C, B2B PM and reduction fallacy
ykmc09
4
650
Amplify 🩷 Bedrock 〜生成AI入門〜
minorun365
PRO
10
1.2k
TailwindCSSでUIライブラリを作る際のハマりどころ
shuta13
0
210
成長をサポートするピープルマネジメントのやり方
sioncojp
9
1.5k
パスワードを保存しますか?
hanacchi
0
240
「知的単純作業」を自動化する、地に足の着いた大規模言語モデル (LLM) の活用
nrryuya
8
7.9k
株式会社EventHub・エンジニア採用資料
eventhub
0
2.1k
QAエンジニアが伝えたい品質保証の羅針盤 / Compass for Quality Assurance
mii3king
1
310
PhpStorm超絶技巧40分集中講義 #phpconkagawa
yusuke
4
690
AWSやJAWS-UGとの出会いを振り返る
yoyoyopg
1
210
拓展QA日常工作的邊界
line_developers_tw
PRO
0
200
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
352
28k
KATA
mclloyd
16
12k
The Brand Is Dead. Long Live the Brand.
mthomps
49
30k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
117
18k
Faster Mobile Websites
deanohume
300
30k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
21
2k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.3k
Fireside Chat
paigeccino
22
2.7k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Making the Leap to Tech Lead
cromwellryan
125
8.6k
A Modern Web Designer's Workflow
chriscoyier
689
190k
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の活動 • フィードバックを得て取り組み方を常に見直し続けること
自己完結チームが プロダクトを素早く安全に届け続けるための プラットフォームと文化を作る