Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
SREはこうやって開発生産性と戦います / LM-Pioneer-Kawatsu
Search
リンクアンドモチベーション
PRO
September 16, 2022
Technology
1k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SREはこうやって開発生産性と戦います / LM-Pioneer-Kawatsu
リンクアンドモチベーション
PRO
September 16, 2022
More Decks by リンクアンドモチベーション
See All by リンクアンドモチベーション
AI活用勉強会は いいぞ!
lmi
PRO
1
320
AI時代だからこそ、 一次情報を足で稼ぐ
lmi
PRO
0
56
非開発組織のDX推進 ―― AI時代こそ「要件定義」が勝負
lmi
PRO
1
400
全社員がAIを「使う」の次へ ーノンエンジニア1,500人が安全に業務を作り変えるゴールデンパスとガードレール
lmi
PRO
3
3.7k
2年で50%しか進まなかった1,500ファイルの型付けを、3週間で片付けた話
lmi
PRO
0
120
「React でいいじゃん」と思ってた私が、「Vue 熱いじゃん」ってなった話
lmi
PRO
1
430
「AIがあれば越境できる」と思ったら、 AI Slopの山ができた
lmi
PRO
1
530
上司のダメ出しを全部AIに食わせ続けたら、 最強の相棒になってきた話
lmi
PRO
0
70
ペーペーのPdMがドペーペーの開発者になったら、見えた世界
lmi
PRO
0
78
Other Decks in Technology
See All in Technology
「Docker Desktop不要の時代」は 来たのか?
ueponx
0
620
10年後、Engineering 行為を剥奪されるとして、わたしたちは、どう、何を創ればいいだろうか。 / If Engineering Is Taken Away in 10 Years, How and What Should We Create?
bitkey
PRO
1
150
契約書画像からの情報抽出に特化した視覚接地モデルを育てる話
sansantech
PRO
1
180
触りたくないデータに、どう触るか AI時代のRBACアクセスガバナンス
ivry_presentationmaterials
0
140
NDIでApple Vision Proにリアルタイム映像送信
jyouryuusui
0
100
UniFi(ユニファイ)AIカメラの現場活用
ludicmind
1
420
OR学会2026年秋期大会_機械学習と数理最適化の融合による、配合レシピ最適化システム開発事例
brainpadpr
0
140
12 個 Tool と、 4,096 Token
hlum
0
150
【Data Engineering Summit2026_登壇資料】医療ビッグデータ×AIエージェントを支えるデータ基盤とハーネスエンジニアリング
jmdc_presentation
0
140
ブラウザとサーバーから考えるAI時代のフロントエンド監視
shogo4131
3
880
継続的なAIコスト最適化
bgpat
1
290
Getting Started with Google Antigravity
glaforge
0
240
Featured
See All Featured
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
320
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
930
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
620
Bash Introduction
62gerente
615
220k
Building Flexible Design Systems
yeseniaperezcruz
330
41k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
400
HDC tutorial
michielstock
2
960
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
ラッコキーワード サービス紹介資料
rakko
1
5.3M
The agentic SEO stack - context over prompts
schlessera
0
970
Making Projects Easy
brettharned
120
6.8k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
470
Transcript
LM - SRE はこうやって 開発生産性と戦います 株式会社 Link & Motivation SRE
- 川津 雄介
• 前職は某複写機メーカーでエンジニアして ました • 現職では SRE • FE→BE→OS→インフラ 全部やりたい派 •
採用活動もしてます 自己紹介 https://github.com/megmogmog1965 https://qiita.com/megmogmog1965
今日のテーマ SRE の言う「開発生産性」って何? 03 01 02 どうやって改善項目を決めるの? LM流・改善を成果に繋げるには (布教活動) しくみ
01 SRE の言う「開発生産性」って何?
そもそも LM の開発体制は? 開発チームはミッシ ョンで分けます。 SRE は開発室を 横断する! 新規顧客獲得の為の 機能開発チームとか
開発あるある...
最近リリース 速くなったね! 開発者
(特に何も変わって ないけど..?) 開発者
開発者 最近開発 遅くない?
(頑張って前より沢 山開発してるんだけ どなぁ...) 開発者
感覚じゃなくて... ものさし (指標) が必要
生産性指標 = 4 Key Metrics デプロイ頻度 本番環境へのリリースの頻度 (回) ※「20 回/週」とか!
リードタイム 初回の git commit から、そのコ ードが本番デプロイされるまでの 時間 ※「5日」とか! 本番環境で発生した障害から 復旧するまでの時間 ※「平均 120 分」とか! MTTR 本番へのリリース回数に対して、 障害が発生した割合 (%) ※「15%」とか! 変更障害率
開発のスピードを表す Metrics デプロイ頻度 本番環境へのリリースの頻度 (回) ※「20 回/週」とか! リードタイム 初回の git
commit から、そのコ ードが本番デプロイされるまでの 時間 ※「5日」とか! 本番環境で発生した障害から 復旧するまでの時間 ※「平均 120 分」とか! デプロイ頻度 本番へのリリース回数に対して、 障害が発生した割合 (%) ※「15%」とか! 変更障害率
品質が損なわれていないか Metrics デプロイ頻度 本番環境へのリリースの頻度 (回) ※「20 回/週」とか! リードタイム 初回の git
commit から、そのコ ードが本番デプロイされるまでの 時間 ※「5日」とか! 本番環境で発生した障害から 復旧するまでの時間 ※「平均 120 分」とか! MTTR 本番へのリリース回数に対して、 障害が発生した割合 (%) ※「15%」とか! 変更障害率
バランスが重要 品質を犠牲にすれば スピードは簡単に上げられる
02 どうやって改善項目を決めるの?
State of DevOps Report - 2021 High/Mid/Low Performaer の分類 一般的な目標値のランク
私達は今どのレベルにいるのかな? LM での High/Mid-*/Low の独自解釈版
例えば昔...
デプロイ頻度を上げたい
BEFORE…
元々 EB を手でデプロイしてた EB 沢山あるよ〜 3時間かかる... リリース担当者 が決まってて 誰でもできない EB
EB EB EB EB EB EB EB EB EB ミスったら...
AFTER !!
コンテナ化 (ECS) しました EB ECS
All Terraform 化もしました ※ 実はその前は AWS CDK (TypeScript) を使ってた
堅牢性・透明性の担保 静的なコード • HCL はほぼ「設定ファイル」 • プログラムコードの様な難しさが 無い 変更箇所が明確 •
`terraform plan` で、変更箇所が明確に分かる • 「やってみないと分からなくて怖い...」が無い
Github / CodeBuild CI でデプロイ自動化 Master マージ で自動デプロイ Blue /
Green にした Blue / Green にした
そして次は...
リードタイムを上げたい
BEFORE…
この木、なんの木? 「マージ待ち、お見合い行列の木」
開発組織が拡大する → 複雑化 • Master マージすると自動デプロイされるから、気軽にマージできない • 「明日だれがリリースする?」「もうリリースブランチ(PR)作った?」
AFTER !!
(作業を〜ではなく) プロセスを自動化します
Git-flow にしたよ!
自動でリリース担当に通知 (依頼) 朝 7:00 に Slack に自動で来る ※ Feature Flags
も導入してます
リリース用の Github PR も自動で 朝 7:00 に PR 自動で作られる
ステージングデプロイ → 自動テスト ステージング環境 自動デプロイ 自動テスト
Release ver の git tag も自動で Feature リリースなら Minor ver
が上がる Hotfix リリースなら Patch ver が上がる
Github Actions で実現 Git 周りの自動化は Github Actions でほぼ完結します
03 改善を成果に繋げるには
仕組みは、作った後の 布教活動が重要!
どうやって布教するか? 1. 全体の場で「意義・メリット」を布教! 2. 各チームに「伝道者」 (※相談人) を作る!
最後に... 計測 → 改善 のサイクル 計測 今現在の最大の ボトルネックは どこか? 改善
特定した課題をどう 「仕組み」で解決 するか?
THANKS 私達、株式会社 Link & Motivation は 一緒に働く新しい仲間を募集しています! 応募ページはこちら!