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
210
サービスレベルを管理してアジャイルを加速しよう!! / 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
36
「頑張る」を「楽しむ」に変換する技術
tomoyakitaura
17
10k
これからの設計で変わること 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
生成AIで知るお願いの仕方の難しさ
ohmori_yusuke
1
120
AIコーディングの本質は“コード“ではなく“構造“だった / The essence of AI coding is not “code” but "structure
seike460
PRO
2
450
Golangci-lint v2爆誕: 君たちはどうすべきか
logica0419
1
270
Jakarta EE Meets AI
ivargrimstad
0
930
Носок на сок
bo0om
0
1.3k
大LLM時代にこの先生きのこるには-ITエンジニア編
fumiyakume
8
3.4k
MySQL初心者が311個のカラムにNot NULL制約を追加していってALTER TABLEについて学んだ話
hatsu38
2
140
バイラテラルアップサンプリング
fadis
3
550
音声プラットフォームのアーキテクチャ変遷から学ぶ、クラウドネイティブなバッチ処理 (20250422_CNDS2025_Batch_Architecture)
thousanda
0
430
Rubyの!メソッドをちゃんと理解する
alstrocrack
1
310
iOSアプリで測る!名古屋駅までの 方向と距離
ryunakayama
0
160
Global Azure 2025 @ Kansai / Hyperlight
kosmosebi
0
150
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Practical Orchestrator
shlominoach
187
11k
Documentation Writing (for coders)
carmenintech
71
4.8k
Automating Front-end Workflow
addyosmani
1370
200k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
840
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.7k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
A better future with KSS
kneath
239
17k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
Site-Speed That Sticks
csswizardry
6
540
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 ご静聴ありがとうございました!!