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
200
サービスレベルを管理してアジャイルを加速しよう!! / 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
33
「頑張る」を「楽しむ」に変換する技術
tomoyakitaura
17
9.9k
これからの設計で変わること pre:invent2024アップデート速報 / pre:invent2024 network update
tomoyakitaura
1
210
セキュリティ活動をちょっとずつやる戦略を実行した気づき / Incremental Security Initiatives
tomoyakitaura
0
160
社内共通コンテナレジストリを設立して、開発者体験向上を狙ってみた /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
150
LTワークショップ(1日目) / LT workshop day 1
tomoyakitaura
1
180
これまでの監視とクラウド時代の監視 / Monitoring the Past and the Cloud
tomoyakitaura
1
280
Other Decks in Programming
See All in Programming
Browser and UI #2 HTML/ARIA
ken7253
2
170
Laravel × Clean Architecture
bumptakayuki
PRO
0
130
Носок на сок
bo0om
0
1.1k
ComposeでのPicture in Picture
takathemax
0
130
音声プラットフォームのアーキテクチャ変遷から学ぶ、クラウドネイティブなバッチ処理 (20250422_CNDS2025_Batch_Architecture)
thousanda
0
380
AIコーディングエージェントを 「使いこなす」ための実践知と現在地 in ログラス / How to Use AI Coding Agent in Loglass
rkaga
4
1.2k
一緒に働きたくなるプログラマの思想 #QiitaConference
mu_zaru
78
20k
GitHub Copilot for Azureを使い倒したい
ymd65536
1
310
The Missing Link in Angular’s Signal Story: Resource API and httpResource
manfredsteyer
PRO
0
140
Creating Awesome Change in SmartNews! En
martin_lover
0
110
Orleans + Sekiban + SignalR でリアルタイムWeb作ってみた
tomohisa
0
230
エンジニア向けCursor勉強会 @ SmartHR
yukisnow1823
3
12k
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
820
How STYLIGHT went responsive
nonsquared
100
5.5k
Navigating Team Friction
lara
185
15k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Practical Orchestrator
shlominoach
187
11k
Build your cross-platform service in a week with App Engine
jlugia
230
18k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
How GitHub (no longer) Works
holman
314
140k
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 ご静聴ありがとうございました!!