サービスレベルを管理してアジャイルを加速しよう！！ / slm-accelerate-agility

DevOpsDays 2025の登壇資料です。

Transcript

1. サービスレベルを管理して アジャイルを加速しよう！ ~~ スクラムへのSRE導入術 ~~ KDDIアジャイル開発センター株式会社 Tomoya Kitaura DevOpsDays 2025 DAY2 2025/04/16
2. 自己紹介 Tomoya Kitaura @kitta0108 KDDIアジャイル開発センター リードSRE ▪技術コミュニティ運営 - - JAWS-UG コンテナ支部 - JAWS-UG SRE支部 - NRUG SRE支部 2 2 ▪著書 - 俺たちのSREとNew Relic
3. 今日のゴール 3 ユーザーにより良い価値を届けるために 信頼性をキーとした活動/手法を [皆様の || 自分の]選択肢に加える。
4. アジェンダ 4 - SREの目的とやりたいこと - SRE x スクラムの始め方
5. SREの目的 5 信頼性を中心にバランスをとる 資料：サイト信頼性エンジニアリングと Amazon Web Servicesより https://speakerdeck.com/ymotongpoo/sre-and-aws?slide=8
6. SREの目的 6 “Reliability Is the Most Important Feature” 「信頼性は最も重要な”機能”です。」 資料：The Site Reliability Workbookより https://sre.google/workbook/reaching-beyond/
7. エクササイズ 7 タスク管理のためのToDoアプリを探しています。 どちらを使いますか？ Aのアプリ Bのアプリ - タスクの登録と削除しかできない - 絶対に期待した動作ができる。 - 魅力ある機能を多数備えている - 1/3ほどの確率で操作に失敗する。
8. エクササイズ 8 多分、どちらも市場では選ばれる事がない。 信頼性に過剰に 投資したケース 信頼性への投資を 軽視したケース Aのアプリ Bのアプリ
9. やりたいこと 9 例えばシステムアラートの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% アラートによる影響 →プロダクトバックログの最優先タスクとして追加
10. やりたいこと 10 例えばシステムアラートの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% アラートによる影響 ->機能開発を継続 ->リファインメントで対応策を提案 ->アラートの閾値を調整
11. やりたいこと 11 例えばリスクのあるタスクの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% リスクによる影響 ->検証作業を念入りにする ->デプロイを安全にする ->ロールバック手順を整備する リスクを回避するためのタスク A リスクを回避するためのタスク B リスクを回避するためのタスク C
12. やりたいこと 12 例えばリスクのあるタスクの対応 ユーザーの求めるService Level 99% 許容できるService Levelの残り1% リスクによる影響 ->対策前進で実施
13. やりたいこと 13 この活動の精度を スクラムの中で高めていきたい。 すると、ユーザーにとって、 最も価値の高いものを持続的に届ける事ができる。
14. タイトルの趣旨 14 サービスレベルを管理して アジャイルを加速しよう！ ~~ スクラムへのSRE導入術 ~~ ←ここまでの話 ←ここからの話 あと何分？
15. Dickersonの信頼性の階層構造 15 資料：サイト信頼性エンジニアリングと Amazon Web Servicesより https://speakerdeck.com/ymotongpoo/sre-and-aws?slide=10
16. スクラムへの組み込み方 16 スプリントプランニング リファインメント スプリントレビュー レトロスペクティブ パフォーマンス定点観測会 New
17. パフォーマンス定点観測の始め方 17 - 開催頻度目安 - スプリント毎に1回1h - またはデイリースクラムの後に15min - 後者の方が理想だが、成熟していないうち は前者がおすすめ - 参加者 - 開発者全員の参加が必須 - 関心のあるステークホルダーを巻き込んで いっても⭕
18. パフォーマンス定点観測の始め方 18 - アジェンダ - システムのダッシュボードをさっとみる。 - APMのTransaction上位をさっとみる。 - Security Hubの遵守状況をさっとみる。 - [option]AWSの請求ダッシュボードをさっと みる。 - [option]CI/CDのビルド時間などのパフォーマ ンスをさっとみる
19. パフォーマンス定点観測の始め方 19 - 役割 - モブプロ形式がおすすめ - 最初のうちはファシリテーションを リードエンジニアポジションの人がするとよい。 - ドライバーは基本ローテーション。 ジュニアポジションの人にお願いしても良い。
20. パフォーマンス定点観測の始め方 20 - 成果物 - 要求されるService Levelに影響のありそうな気 づきがあったらバックログのチケットを切る。 - リファインメント時に提案 - ビジネスアウトカムからみた観点が大事で 必ずステークホルダーに伝わるレベルで必要 性を言語化する。ここまでをこの会でやる。
21. パフォーマンス定点観測の始め方 21 - ちょっとしたコツ - タイムボックスは必ず守る - 長引きそうな議論は調査・整理タスクとしてチケット切っ ちゃっていい。 - 本当にその対応は必要か？は重要な問い - いつもと違う気がするけど大丈夫なんだっけ？も重要な問い - SLOはあるに越したことはないのは間違いないが、 活動を始める段階では必須ではない。 進めていく中でやりづらさを感じた時に導入を検討すると良い
22. パフォーマンス定点観測の始め方 22 とまぁ、ここまでやり方を提案してみましたが、 大事だと思うものをチーム内で議論して、 いろんなやり方を模索してもらえたら良いと思います。 うちはこんなやり方をしたら良かったよ！ のような知見がもっと世の中で広がったら素敵だなって 思います。
23. まとめ 23 - 信頼性は最も重要な”機能”です。 - 最も高い価値をユーザーに届け続けるために、 信頼性の管理は重要な事です。 - スクラムに導入するには信頼性の情報源の精度を 高めたり、見る力を養うアプローチは有効だと思 います。
24. 今日のゴール(再掲) 24 ユーザーにより良い価値を届けるために 信頼性をキーとした活動を [皆様の || 自分の]選択肢に加える。
25. さいごに 25 ご静聴ありがとうございました！！