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
Plartform TeamのないPlatform Engineering
Search
yashirook
September 24, 2024
Technology
2
510
Plartform TeamのないPlatform Engineering
Platform Engineering Meetup #10の登壇資料です。
yashirook
September 24, 2024
Tweet
Share
More Decks by yashirook
See All by yashirook
Istioならできる!サービスを支える柔軟なトラフィック制御
yashiro
2
1.5k
Other Decks in Technology
See All in Technology
GC25 Recap+: Advancing Go Garbage Collection with Green Tea
logica0419
1
430
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
290
関係性が駆動するアジャイル──GPTに人格を与えたら、対話を通してふりかえりを習慣化できた話
mhlyc
0
130
GopherCon Tour 概略
logica0419
2
190
AI駆動開発を推進するためにサービス開発チームで 取り組んでいること
noayaoshiro
0
220
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
550
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
330
Where will it converge?
ibknadedeji
0
190
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
shift_evolve
PRO
3
330
"プロポーザルってなんか怖そう"という境界を超えてみた@TSUDOI by giftee Tech #1
shilo113
0
110
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
3
290
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
100
Featured
See All Featured
Statistics for Hackers
jakevdp
799
220k
Practical Orchestrator
shlominoach
190
11k
Six Lessons from altMBA
skipperchong
28
4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Typedesign – Prime Four
hannesfritz
42
2.8k
Agile that works and the tools we love
rasmusluckow
331
21k
Fireside Chat
paigeccino
40
3.7k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Optimizing for Happiness
mojombo
379
70k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Transcript
Platform Teamのない Platform Engineering 2024/09/24 Platform Engineering Meetup #10 株式会社ユーザベース スピーダ事業部SRE
八代健太郎(@yashirook)
2 自己紹介 • 略歴 ◦ 2015~2018: 物理系の研究 ◦ 2018~2020: SIerでKubernetesをはじめとするCNCFプ
ロダクトの技術検証 ◦ 2020~現在:ユーザベースでSRE • 大阪在住 • Tech ◦ Kubernetes ◦ GCP • 激辛好き🌶🌶🌶
3 ユーザベースについて
4 開発組織とSREチーム 規模・在籍メンバー属性 ・ソフトウェアエンジニア ・SRE ・テストエンジニア ・機械学習エンジニア 約100名 開発チーム構成 各プロダクト・機能ごと
に開発チームを作り、 ペアプロ・TDDで開発 ストリームアラインドチーム (開発チーム) Aチーム (4~5名) Bチーム (4~5名) Cチーム (4~5名) and more…(計20チームほど) SREチーム 全てのプロダクト開発に 横断的に関わる 組織図上のPlatform Teamは存在しない
SREチームのVision/Mission/Strategy 5 5 Platform Engineeringと重なるモチベーション
6 スピーダ事業部における Platform Engineering | 01
7 スピーダ事業のPlatform オンプレ VM 開発チーム SRE Platform システム変更の インターフェース (CI/CD,
APIなど) Platform自体の運用・改善 インターフェースの 提供 変更のリリース
8 • サービス利用者と開発者をユーザーと想定している • 基本的にはサービス利用者への価値を優先する ◦ 基盤の信頼性向上 ◦ SLI/SLOの運用 •
とはいえ、開発チームの生産性を高める仕組みをつくることは重要 • 専任でないため必然的に限られたリソース の中で、開発者体験向上に取り組むことになる ◦ システム変更のインターフェース ◦ CI/CD 開発者体験向上 (Platform Engineering) への向き合い方 サービス利用者 開発者
9 具体例①: Kubernetesに対する権限管理 | 02
10 Kubernetesに対する権限管理の課題 過去開発チームは、クラスタの状態確認や運用を実施するにあたり、デプロイサーバーに SSHしてkubectlを実行 • 強い権限を持ち、誤操作に対する安全性や監査の観点でセキュリティリスクがある • 便利なCLIツールを利用しにくい デプロイサーバー 開発チーム
SSH kubectl –context cluster-a <some-command> • いつか事故るよなぁ • 便利なツールが色々ある んだけどなぁ
11 1つ目のリリース:ローカルからIAM認証で繋げるようにする ローカルからKubernetesにアクセスできるようにした • 本番はRO、開発はRWで最低限の安全性と監査を担保 ◦ 厳格な権限制御と個別チューニングは一旦実施しない ◦ Google WorkspaceのGroupに対して付与
• 便利kubectl pluginなどが使えて生産性向上の効果も見られた 開発チーム $ kubectx cluster-a $ kubectl <some-command> • ワークフローを大きく変えることなく 少し良くできたなぁ
12 フィードバックを得る 開発チームの理解が深まった 今より少し良くするためには? それをすべきか? (相談) ある運用が従来通りできなくて、 従来の方法で実行せざるを得ない シーンがあるから SREにオペレー
ションしてほしい(権限不足) (相談) コンテキスト違いの誤操作で 環境を壊してしまわないか心配 (権限過剰) (ペアプロ、ペアオペ) こんな運用で従来の方法を 使っちゃってるなぁ
13 2つ目のリリース:デフォルト権限の弱化と権限突破 個別チームに最適化するのではなく、安全に倒した上で権限突破の仕組みを用意する • デフォルトは事故を防ぐを第一に • 必要な運用の際は権限突破の仕組みを利用して自分たちで対応 開発チーム $ kubectl
rollout restart <deployment> 権限突破サービス 権限リクエスト 権限付与 監査ログの記録 JIT-access (OSS) ↓ Privileged Access Manager (GCP)
14 振り返ってみて気づいた大事にしていたこと • 段階的に改善すること ◦ 小さな価値(MVP)のリリースを繰り返す ◦ 色々やりたくなる気持ちを抑えて、早い段階で価値 を届け、フィードバックを得る ◦
フィードバックを得る前にワークフローを大きく変更し ない • 継続的にフィードバックを受け取ること ◦ 開発チームとのペアプロ(反応をリアルに感じられ る) ◦ 気軽に話にきてもらう、能動的にフィードバックを求 める 小さな価値 ユーザーの 理解 SRE チーム 文脈 補強 意思 決定 フィード バック
15 具体例②: Terraformによる パブリッククラウドの構成変更 | 03
16 パブリッククラウドの変更に関する課題 過去開発チームは、パブリッククラウドを変更するときには、SREに依頼することで実施し ていた • 開発チームでコントロールできない待ちが発生してしまう • クラウドリソースに関するオーナーシップを持ちにくい • SREチームにとってもToil的な対応が課題に
開発チーム 依頼 Terraform CI/CD
17 どうしますか? • 慣れたインターフェース( Kubernetesのマニフェスト等)で抽象化を用意する • 主なユースケースに対する Terraformのモジュールを用意する • Terraformを書くためのドキュメントや学習リソースを整備し、アナウンスして使ってもらう
• etc… 小さな価値 ユーザーの 理解 SRE チーム 文脈 補強 意思 決定 フィード バック
18 1つ目のリリース:積極的なペアプロ 開発チームとペアプロをするとこから始めた(形のないリリース) 開発チーム • 積極的にやろうとしてくれるな、計画の精度を高められて開発チームとし ても嬉しいのかも • HCLも割とシュッと書いてくれるな •
みんなが使えるように舵を切ってもいいかも Terraform CI/CD 依頼 ペアプロでやってみ ませんか? tfactionを利用
19 2つ目のリリース:開発チームだけで書けるようにする ペアプロを繰り返すうちに、典型的なユースケースではもう開発チームだけで書けるという 感覚を得てきた • プルリクエストによる変更の受け付けを開始 • マージはSREチームメンバーがチェックした上で実施 開発チーム Terraform
CI/CD PR レビュー・マージ CloudSQLのHA構成有効化 tfactionを利用
20 これからのリリース? • 認知負荷の軽減 ◦ 典型的なユースケースでは、開発チームが設定したい箇所が概ね見えているので、抽象化 ◦ 初めて/挑戦的なユースケースの抽象化はせず、ペアプロから始める • フローの安全・高速化
◦ ガードレール ◦ Stateを切り離し、開発チームに閉じた範囲ではマージも可能に
21 小規模にPlatform Engineeringを 実践することについて | 03
22 文脈を踏まえて意思決定する 領域のベストプラクティスは意識するが、何の価値をつくり、届けるかは文脈を意識する • エクストリームプログラミング(アジャイル) ◦ ペアプロで開発を進めることが基本 ◦ 少しずつ改善する •
マイクロサービス ◦ 担当領域に関わるコンポーネントのオーナーシップは開発チームが持つ • チーム間のコミュニケーション ◦ 口頭での同期的なコミュニケーションを優先する、すぐ直接話す
23 理想とのギャップは常にある • 自分たちがやっていることはPlatform Engineeringと言えるのだろうか? ◦ IDPやセルフサービスのAPIの構築例などに圧倒される • もっと生産性と、サービス品質を高くする抽象化を求めたくなる •
ワークフローへの適合と、ベストプラクティス準拠のトレードオフ ◦ ワークフローを尊重しながら、納得感あるフローの改善に導くこと
24 それでもあえて、Platform Engineeringだと言ってみる • プラットフォームをプロダクトのように扱う ◦ ユーザーに価値が届くこと ◦ ワークフローに適合すること ◦
ユーザー(開発者)から頻繁にフィードバックを得ながら、段階的に改善すること • 形あるプラットフォームにこだわらないこと ◦ ドキュメントもプラットフォーム 小規模なためできることは限られるが、小さな価値をしっかり届ける(使われるも のをつくる)。組織としてより投資する段階になったら、その経験は活きるはず。
25 まとめ • Platform Engineering専任でないSREチームが、Platform Engineeringを実践 ◦ ユーザー(開発者)のペインを理解し、小さく価値を届ける ◦ コミュニケーションとフィードバックの繰り返し
• 小規模でも始められるし、だからこそ始めやすい ◦ むしろ、実はやっていたことはPlatform Engineeringとも言えるかも?
26 補足資料 | Appendix
27 Terraformのペアプロをしてみて 小さな価値 組織における文脈 • 開発チームは外部依存を減らすことで、計画の精度が高まるんだなぁ • Terraformを書くというプロセスは、計画スキルと技術的興味などから受け入れら れるものなんだなぁ •
スキル的にも十分適用可能だな
28