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
サービスレベルを管理してアジャイルを加速しよう!! / slm-accelerate-agility
Search
TomoyaKitaura
April 16, 2025
Programming
1
230
サービスレベルを管理してアジャイルを加速しよう!! / slm-accelerate-agility
DevOpsDays 2025の登壇資料です。
TomoyaKitaura
April 16, 2025
Tweet
Share
More Decks by TomoyaKitaura
See All by TomoyaKitaura
New Relicの推せるところ・推せないところ / newrelic good and bad
tomoyakitaura
0
68
「頑張る」を「楽しむ」に変換する技術
tomoyakitaura
17
10k
これからの設計で変わること pre:invent2024アップデート速報 / pre:invent2024 network update
tomoyakitaura
1
220
セキュリティ活動をちょっとずつやる戦略を実行した気づき / Incremental Security Initiatives
tomoyakitaura
0
170
社内共通コンテナレジストリを設立して、開発者体験向上を狙ってみた /Establishing container registry to improve DX
tomoyakitaura
2
200
LTワークショップ3日目 / LT Workshop Day 3
tomoyakitaura
0
170
LTワークショップ2日目 / LT Workshop Day 2
tomoyakitaura
0
160
LTワークショップ(1日目) / LT workshop day 1
tomoyakitaura
1
190
これまでの監視とクラウド時代の監視 / Monitoring the Past and the Cloud
tomoyakitaura
1
300
Other Decks in Programming
See All in Programming
Datadog RUM 本番導入までの道
shinter61
1
300
WindowInsetsだってテストしたい
ryunen344
1
180
Kotlin エンジニアへ送る:Swift 案件に参加させられる日に備えて~似てるけど色々違う Swift の仕様 / from Kotlin to Swift
lovee
1
230
XSLTで作るBrainfuck処理系
makki_d
0
210
Webからモバイルへ Vue.js × Capacitor 活用事例
naokihaba
0
710
関数型まつり2025登壇資料「関数プログラミングと再帰」
taisontsukada
2
830
Using AI Tools Around Software Development
inouehi
0
1.2k
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
790
[初登壇@jAZUG]アプリ開発者が気になるGoogleCloud/Azure+wasm/wasi
asaringo
0
130
技術懸念に立ち向かい 法改正を穏便に乗り切った話
pop_cashew
0
1.5k
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
230
Gleamという選択肢
comamoca
6
730
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
46
14k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Into the Great Unknown - MozCon
thekraken
39
1.8k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Making Projects Easy
brettharned
116
6.2k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
43
2.4k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
The Invisible Side of Design
smashingmag
299
51k
Transcript
サービスレベルを管理して アジャイルを加速しよう! ~~ スクラムへのSRE導入術 ~~ KDDIアジャイル開発センター株式会社 Tomoya Kitaura DevOpsDays 2025
DAY2 2025/04/16
自己紹介 Tomoya Kitaura @kitta0108 KDDIアジャイル開発センター リードSRE ▪技術コミュニティ運営 - - JAWS-UG
コンテナ支部 - JAWS-UG SRE支部 - NRUG SRE支部 2 2 ▪著書 - 俺たちのSREとNew Relic
今日のゴール 3 ユーザーにより良い価値を届けるために 信頼性をキーとした活動/手法を [皆様の || 自分の]選択肢に加える。
アジェンダ 4 - SREの目的とやりたいこと - SRE x スクラムの始め方
SREの目的 5 信頼性を中心にバランスをとる 資料:サイト信頼性エンジニアリングと Amazon Web Servicesより https://speakerdeck.com/ymotongpoo/sre-and-aws?slide=8
SREの目的 6 “Reliability Is the Most Important Feature” 「信頼性は最も重要な”機能”です。」 資料:The
Site Reliability Workbookより https://sre.google/workbook/reaching-beyond/
エクササイズ 7 タスク管理のためのToDoアプリを探しています。 どちらを使いますか? Aのアプリ Bのアプリ - タスクの登録と削除しかできない - 絶対に期待した動作ができる。
- 魅力ある機能を多数備えている - 1/3ほどの確率で操作に失敗する。
エクササイズ 8 多分、どちらも市場では選ばれる事がない。 信頼性に過剰に 投資したケース 信頼性への投資を 軽視したケース Aのアプリ Bのアプリ
やりたいこと 9 例えばシステムアラートの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% アラートによる影響 →プロダクトバックログの最優先タスクとして追加
やりたいこと 10 例えばシステムアラートの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% アラートによる影響 ->機能開発を継続
->リファインメントで対応策を提案 ->アラートの閾値を調整
やりたいこと 11 例えばリスクのあるタスクの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% リスクによる影響 ->検証作業を念入りにする
->デプロイを安全にする ->ロールバック手順を整備する リスクを回避するためのタスク A リスクを回避するためのタスク B リスクを回避するためのタスク C
やりたいこと 12 例えばリスクのあるタスクの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% リスクによる影響 ->対策前進で実施
やりたいこと 13 この活動の精度を スクラムの中で高めていきたい。 すると、ユーザーにとって、 最も価値の高いものを持続的に届ける事ができる。
タイトルの趣旨 14 サービスレベルを管理して アジャイルを加速しよう! ~~ スクラムへのSRE導入術 ~~ ←ここまでの話 ←ここからの話 あと何分?
Dickersonの信頼性の階層構造 15 資料:サイト信頼性エンジニアリングと Amazon Web Servicesより https://speakerdeck.com/ymotongpoo/sre-and-aws?slide=10
スクラムへの組み込み方 16 スプリントプランニング リファインメント スプリントレビュー レトロスペクティブ パフォーマンス定点観測会 New
パフォーマンス定点観測の始め方 17 - 開催頻度目安 - スプリント毎に1回1h - またはデイリースクラムの後に15min - 後者の方が理想だが、成熟していないうち
は前者がおすすめ - 参加者 - 開発者全員の参加が必須 - 関心のあるステークホルダーを巻き込んで いっても⭕
パフォーマンス定点観測の始め方 18 - アジェンダ - システムのダッシュボードをさっとみる。 - APMのTransaction上位をさっとみる。 - Security
Hubの遵守状況をさっとみる。 - [option]AWSの請求ダッシュボードをさっと みる。 - [option]CI/CDのビルド時間などのパフォーマ ンスをさっとみる
パフォーマンス定点観測の始め方 19 - 役割 - モブプロ形式がおすすめ - 最初のうちはファシリテーションを リードエンジニアポジションの人がするとよい。 -
ドライバーは基本ローテーション。 ジュニアポジションの人にお願いしても良い。
パフォーマンス定点観測の始め方 20 - 成果物 - 要求されるService Levelに影響のありそうな気 づきがあったらバックログのチケットを切る。 - リファインメント時に提案
- ビジネスアウトカムからみた観点が大事で 必ずステークホルダーに伝わるレベルで必要 性を言語化する。ここまでをこの会でやる。
パフォーマンス定点観測の始め方 21 - ちょっとしたコツ - タイムボックスは必ず守る - 長引きそうな議論は調査・整理タスクとしてチケット切っ ちゃっていい。 -
本当にその対応は必要か?は重要な問い - いつもと違う気がするけど大丈夫なんだっけ?も重要な問い - SLOはあるに越したことはないのは間違いないが、 活動を始める段階では必須ではない。 進めていく中でやりづらさを感じた時に導入を検討すると良い
パフォーマンス定点観測の始め方 22 とまぁ、ここまでやり方を提案してみましたが、 大事だと思うものをチーム内で議論して、 いろんなやり方を模索してもらえたら良いと思います。 うちはこんなやり方をしたら良かったよ! のような知見がもっと世の中で広がったら素敵だなって 思います。
まとめ 23 - 信頼性は最も重要な”機能”です。 - 最も高い価値をユーザーに届け続けるために、 信頼性の管理は重要な事です。 - スクラムに導入するには信頼性の情報源の精度を 高めたり、見る力を養うアプローチは有効だと思
います。
今日のゴール(再掲) 24 ユーザーにより良い価値を届けるために 信頼性をキーとした活動を [皆様の || 自分の]選択肢に加える。
さいごに 25 ご静聴ありがとうございました!!