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
AI x インシデント管理で拡げるサービスオーナーシップ
Search
Kazuto Kusama
December 03, 2024
Technology
0
210
AI x インシデント管理で拡げるサービスオーナーシップ
Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima
で登壇した資料です
Kazuto Kusama
December 03, 2024
Tweet
Share
More Decks by Kazuto Kusama
See All by Kazuto Kusama
今日からはじめるプラットフォームエンジニアリング
jacopen
8
2.1k
Platform Engineeringで クラウドの「楽しくない」を解消しよう
jacopen
8
670
トラシューアニマルになろう ~開発者だからこそできる、安定したサービス作りの秘訣~
jacopen
4
4.3k
あなたの興味は信頼性?それとも生産性? SREとしてのキャリアに悩むみなさまに伝えたい選択肢
jacopen
7
8.5k
PaaSの歴史と、 アプリケーションプラットフォームのこれから
jacopen
7
2.5k
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
7
1.8k
2024/10 PagerDuty機能アップデート
jacopen
1
80
ゲームから学ぶ、いちばん速いインシデント対応
jacopen
1
150
PEK2024 Recap
jacopen
2
210
Other Decks in Technology
See All in Technology
【iOSエンジニア特集】 iOSアプリ開発の裏側 開発組織が向き合う課題とこれから - 株式会社カウシェ
akifumifukaya
0
260
トップエンジニアが語るDX最前線 / 20250517 Kazutoshi Ono & Ken Yamazaki
shift_evolve
0
130
Lakehouse в Лемана Тех. От архитектуры до оптимизации
emeremyanina1234
0
500
Kent Beckの思想と学びの道筋 / 20250517 Ryutaro Yoshiba & Hiromitsu Akiba
shift_evolve
1
150
Why every SwiftUI developer should care about the Environment - iOSKonf25
peterfriese
0
170
チェックツールを導入したけど使ってもらえなかった話 #GAADjp
lycorptech_jp
PRO
1
150
"発信文化"をどうやって計測する?技術広報のKPI探索記/How do we measure communication culture?
bitkey
4
370
テスト設計、逆から読むとおもしろい──仕様にない“望ましさ”の逆設計
mhlyc
0
200
ホワイトボックス& SONiC アーキテクチャ(全体像) - SONiC Workshop Japan 2025
ebiken
PRO
1
440
正解のない未知(インボイス制度対応)をフルサイクル開発で乗り越える方法 / How to overcome the unknown invoice system with full cycle development
carta_engineering
0
170
MagicPodが描くAIエージェント戦略とソフトウェアテストの未来
magicpod
0
340
GPU 클라우드 환경에서의 회복탄력적 AI 운영 : 훈련 및 추론을 위한 견고한 아키텍처와 전략
inureyes
PRO
0
140
Featured
See All Featured
Unsuck your backbone
ammeep
671
58k
Building a Modern Day E-commerce SEO Strategy
aleyda
40
7.3k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
What's in a price? How to price your products and services
michaelherold
245
12k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Navigating Team Friction
lara
185
15k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Six Lessons from altMBA
skipperchong
28
3.8k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
720
Transcript
AI x インシデント管理で拡げる サービスオーナーシップ PagerDuty Kazuto Kusama @jacopen
Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering
Meetup Founder @Cloud Native Innovators Association
本日の配信を担当しています
PagerDutyって知ってますか?
1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防
ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防
ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
ノイズ削減: ⼤量のアラートから”インシデント”を特定 1000s of events Suppression, basic deduplication & filtering
Event Orchestration Service routing Machine learning alert correlation 80-99% noise reduced Event (= Alert, Signal): 監視ツール等か送られる雑多な情報 Incident: サービスに影響を及ぼしかねない課題。 何らかの対応が必要なもの。 7
1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防
ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 (応答がなければ) 二次対応者 オンコールの ローテーション
1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防
ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防
ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップ
きちんと纏めておくことで、組織としての成長に繋がる。スタンドプレーだとこのあたりの取り組みが 行われないことが多い
+ だと Postmortems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント ノート、Slackの会話などからタイムラインを作成
おれたちDeveloperなんだけど 何か関係があるの?
製品開発ライフサイクル Build Test Ship Run Dev Ops
製品開発ライフサイクル Build Test Ship Run Dev Ops
障害のほとんどはデプロイによって引き起こされる “障害のほとんどはデプロイによって引き起こされる。 したがって、デプロイが増えると障害も増え、結果とし てインシデント管理、軽減策、ポストモーテムが必要 となる” エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか より引用
フルサービスオーナーシップ Build Test Ship Run
フルサービスオーナーシップとは 「コードを書いた者が、その責任を負う」 • 設計と実装の点から見て、テクノロジーに最も精通した人 が 製品開発ライフサイクル全体の責任を引き受ける 運用モデル • 本番環境において自分が書いたコードの責任を負うよう、 最もシンプルな形でエンジニアに権限を与える
• “You build it, you run it.” Werner Vogels - VP & CTO of Amazon
Team Topologies https://martinfowler.com/bliki/TeamTopologies.html より引用
“コードに責任を持つ ” メリット • 自分のコードに責任を持つ開発者は、 エンドユーザーエクスペリエンスにより大きな影響を及ぼす • 開発者は自分の仕事が顧客だけでなく、 ビジネスにも与える影響をよりよく知ることができる •
開発者にとってモチベーションを高めるだけでなく、修正やアップデートの スピードアップにもつながる。 • 二次情報やサポートチケットに頼るのではなく、自分自身で問題を確認できる
“コードに責任を持つ ” メリット • 品質管理のループが生まれる • 夜中3時に好んで叩き起こされたい人はいない • 本番環境での責任を果たすため、運用品質を向上させようという モチベーションに繋がる
• 組織構造ではなく、提供するものに集中できる • 責任者が誰なのかが明確となる • 組織の変化に対応していく仕組みが出来る
“コードに責任を持つ ” メリット • MTTR(平均修復時間)削減につながる • 開発者は不具合の修正に最も適した人材 • 不具合の際には、開発者がラインの先頭に立つ •
コードの責任者が明確なら、より少ないメンバーで問題のトラブルシューティングに 対応できる • 300人規模のオンライン会議で、コードを最後に修正したのは 誰かをトラブルシューティングするような状況から決別できる
理想 現実
そんな簡単にできるものじゃない • 『作った本人が全部やった方が早い』 • それはそう • これだけだと、単に分業を否定しているだけになる • 「専門分野」を活かすことにメリットがあるから、分業が存在する
だからAI
ノイズ削減: ⼤量のアラートから”インシデント”を特定 1000s of events Suppression, basic deduplication & filtering
Event Orchestration Service routing Machine learning alert correlation 80-99% noise reduced Event (= Alert, Signal): 監視ツール等か送られる雑多な情報 Incident: サービスに影響を及ぼしかねない課題。 何らかの対応が必要なもの。 2
Recent Changes Related Incidents Past Incidents Probable Origins
インシデント発生中ってこんな感じ CIO 一体 どうなってるんだ! 現状を 教えてください! 今何が起きてるの! スココン スココン アラート
動かない! ユーザー担当 別チーム ユーザー
忙しいインシデント対応を助ける生成AI
直近で⾏ったシステム変更 が障害の原因か? - Assistant for Slack - サーバーにパッチを当てる ランブックを⽣成して -
AI Generated Runbooks - Automationの実⾏結果は どうだった? - Automation Digest - 診断と修復の改善 状況報告⽤の Status Updateを作成して - Status Updates - 31
インシデント解決と学習の改善 最新の情報は? - Assistant for Slack - ポストモーテムを作成して - Postmortems
- このインシデントは 以前にも起きた? - Assistant for Slack - 顧客への影響範囲は? - Assistant for Slack - 32
AIを活用して いいサービスを作っていきましょう
None