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
70
「頑張る」を「楽しむ」に変換する技術
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
FormFlow - Build Stunning Multistep Forms
yceruto
1
190
XP, Testing and ninja testing
m_seki
3
200
Is Xcode slowly dying out in 2025?
uetyo
1
190
エンジニア向け採用ピッチ資料
inusan
0
160
Gleamという選択肢
comamoca
6
760
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
130
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
190
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
360
エラーって何種類あるの?
kajitack
5
310
ASP.NETアプリケーションのモダナイズ インフラ編
tomokusaba
1
420
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
240
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
230
Featured
See All Featured
Speed Design
sergeychernyshev
32
1k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Statistics for Hackers
jakevdp
799
220k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
KATA
mclloyd
29
14k
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
A Modern Web Designer's Workflow
chriscoyier
694
190k
A designer walks into a library…
pauljervisheath
207
24k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
210
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 ご静聴ありがとうございました!!