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
280
サービスレベルを管理してアジャイルを加速しよう!! / 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
120
「頑張る」を「楽しむ」に変換する技術
tomoyakitaura
17
11k
これからの設計で変わること pre:invent2024アップデート速報 / pre:invent2024 network update
tomoyakitaura
1
250
セキュリティ活動をちょっとずつやる戦略を実行した気づき / Incremental Security Initiatives
tomoyakitaura
0
190
社内共通コンテナレジストリを設立して、開発者体験向上を狙ってみた /Establishing container registry to improve DX
tomoyakitaura
2
210
LTワークショップ3日目 / LT Workshop Day 3
tomoyakitaura
0
190
LTワークショップ2日目 / LT Workshop Day 2
tomoyakitaura
0
170
LTワークショップ(1日目) / LT workshop day 1
tomoyakitaura
1
210
これまでの監視とクラウド時代の監視 / Monitoring the Past and the Cloud
tomoyakitaura
1
330
Other Decks in Programming
See All in Programming
そのpreloadは必要?見過ごされたpreloadが技術的負債として爆発した日
mugitti9
2
3.3k
ALL CODE BASE ARE BELONG TO STUDY
uzulla
17
2.8k
CSC305 Lecture 05
javiergs
PRO
0
210
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
0
750
20251016_Rails News ~Rails 8.1の足音を聴く~
morimorihoge
1
120
After go func(): Goroutines Through a Beginner’s Eye
97vaibhav
0
390
kiroとCodexで最高のSpec駆動開発を!!数時間で web3ネイティブなミニゲームを作ってみたよ!
mashharuki
0
170
Cursorハンズオン実践!
eltociear
2
1k
Pull-Requestの内容を1クリックで動作確認可能にするワークフロー
natmark
2
510
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
300
TFLintカスタムプラグインで始める Terraformコード品質管理
bells17
2
160
私はどうやって技術力を上げたのか
yusukebe
43
18k
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1371
200k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
4 Signs Your Business is Dying
shpigford
185
22k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Designing for Performance
lara
610
69k
Optimizing for Happiness
mojombo
379
70k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
900
Making the Leap to Tech Lead
cromwellryan
135
9.6k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Visualization
eitanlees
149
16k
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 ご静聴ありがとうございました!!