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
ゲームから学ぶ、いちばん速いインシデント対応
Search
Kazuto Kusama
October 02, 2024
Technology
1
160
ゲームから学ぶ、いちばん速いインシデント対応
Cloud Operator Days Tokyo 2024で発表した資料です
Kazuto Kusama
October 02, 2024
Tweet
Share
More Decks by Kazuto Kusama
See All by Kazuto Kusama
AI によってシステム障害が増える!? ~AI エージェント時代だからこそ必要な、インシデントとの向き合い方~
jacopen
4
200
インシデント対応に必要となるAIの利用パターンとPagerDutyの関係
jacopen
0
56
今日からはじめるプラットフォームエンジニアリング
jacopen
8
3.5k
Platform Engineeringで クラウドの「楽しくない」を解消しよう
jacopen
8
790
トラシューアニマルになろう ~開発者だからこそできる、安定したサービス作りの秘訣~
jacopen
4
4.8k
あなたの興味は信頼性?それとも生産性? SREとしてのキャリアに悩むみなさまに伝えたい選択肢
jacopen
7
9.1k
PaaSの歴史と、 アプリケーションプラットフォームのこれから
jacopen
7
2.7k
AI x インシデント管理で拡げるサービスオーナーシップ
jacopen
0
250
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
7
1.9k
Other Decks in Technology
See All in Technology
複数のGemini CLIが同時開発する狂気 - Jujutsuが実現するAIエージェント協調の新世界
gunta
13
3.8k
「AI駆動開発」のボトルネック『言語化』を効率化するには
taniiicom
1
210
Snowflake のアーキテクチャは本当に筋がよかったのか / Data Engineering Study #30
indigo13love
0
280
「育てる」サーバーレス 〜チーム開発研修で学んだ、小さく始めて大きく拡張するAWS設計〜
yu_kod
1
180
大規模イベントを支える ABEMA の アーキテクチャ 変遷 2025
nagapad
5
510
AI人生苦節10年で会得したAIがやること_人間がやること.pdf
shibuiwilliam
1
210
会社もクラウドも違うけど 通じたコスト削減テクニック/Cost optimization strategies effective regardless of company or cloud provider
aeonpeople
2
370
From Live Coding to Vibe Coding with Firebase Studio
firebasethailand
1
320
生成AIを活用した野球データ分析 - メジャーリーグ編 / Baseball Analytics for Gen AI
shinyorke
PRO
1
230
Tiptapで実現する堅牢で柔軟なエディター開発
kirik
1
150
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
180
【2025 Japan AWS Jr. Champions Ignition】点から線、線から面へ〜僕たちが起こすコラボレーション・ムーブメント〜
amixedcolor
1
110
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
A Tale of Four Properties
chriscoyier
160
23k
Gamification - CAS2011
davidbonilla
81
5.4k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
The Cost Of JavaScript in 2023
addyosmani
51
8.6k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Building an army of robots
kneath
306
45k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Thoughts on Productivity
jonyablonski
69
4.8k
KATA
mclloyd
30
14k
It's Worth the Effort
3n
185
28k
Transcript
ゲームから学ぶ いちばん速い インシデント対応 PagerDuty - Product Evangelist Kazuto Kusama @jacopen
Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering
Meetup Founder @Cloud Native Innovators Association
本日ブースでワンオペしてます!
インシデント対応、どうやってますか?
Proprietary & Confidential 1時間 時間 $100K $250K インシデントがもたらす財務的影響
$5.4B フォーチュン 500企業における 財務的な損害額 (推計) Source: Parametrix
Proprietary & Confidential システムの安定稼働が至上命題に コスト 企業イメージ ・信頼性 売り上げ 顧客満足度 営業利益率
いかに早く インシデント対応できるかが大事
つまり RTA
RTA (Real Time Attack) RTAとは、ゲームをクリアするまでの実時間を競うプレイスタイル。海外では「 Speed Run」とも呼ばれる
RTA (Real Time Attack) RTAとは、ゲームをクリアするまでの実 時間を競うプレイスタイル。海外では 「Speed Run」とも呼ばれる インシデント対応
RTAで大事なこと • 徹底的なゲーム理解 • ゲームのメカニクスを深く理解することが不可欠。仕組みの研究に多大な時間を割く • 完璧な操作の習得 • フレーム単位で入力するスキルが求められる •
ルート最適化の継続 • 常に新しいショートカットやテクニックを模索 • 分析と改善 • 過去のランを記録し、セグメントごとの時間を分析。弱点を特定し重点的に練習 • コミュニティとの連携 • 他のランナーとの情報交換や競争によりモチベーション維持と技術向上 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
インシデント対応で大事なこと • 徹底的な理解と準備 • システムやプロセスの深い理解、事前の計画と準備 • 迅速な対応と意思決定 • 問題の素早い検知と初期対応 •
継続的な学習 • 各インシデントからの教訓を活かした継続的な学習と改善 • 分析と改善 • インシデントの詳細な分析と対応プロセスの最適化 • チームワークとコミュニティの重要性 • チーム内の連携や外部ステークホルダーとの協力 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防
ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
インシデント対応で大事なこと • 徹底的な理解と準備 • システムやプロセスの深い理解、事前の計画と準備 • 迅速な対応と意思決定 • 問題の素早い検知と初期対応 •
継続的な学習 • 各インシデントからの教訓を活かした継続的な学習と改善 • 分析と改善 • インシデントの詳細な分析と対応プロセスの最適化 • チームワークとコミュニティの重要性 • チーム内の連携や外部ステークホルダーとの協力 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
オンコール 必要なアラートだけに絞り込み
オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 オンコールの ローテーション
オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 (応答がなければ) 二次対応者 オンコールの ローテーション
かしこくスケジュール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 9:00-17:00 GMT グローバルな連携 JP EU US
17:00-1:00 GMT 1:00-9:00 GMT
インシデント対応で大事なこと • 徹底的な理解と準備 • システムやプロセスの深い理解、事前の計画と準備 • 迅速な対応と意思決定 • 問題の素早い検知と初期対応 •
継続的な学習 • 各インシデントからの教訓を活かした継続的な学習と改善 • 分析と改善 • インシデントの詳細な分析と対応プロセスの最適化 • チームワークとコミュニティの重要性 • チーム内の連携や外部ステークホルダーとの協力 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
+ だと Past Incidents 過去の類似インシデント一覧と、 発生時期・回数のヒートマップを表示。 Related Incidents 他サービスで現在発生している、 関連性の高いインシデントを表示。
インシデント対応のカテゴリ インシデント対応はAny%ではない Any%とは・・・ 達成率関係なし、バグ利用あり、とにかく早ければいい 制約 • 安全性の確保。2次災害を起こしてはいけない • 証拠の適切な収集と保全 •
ステークホルダーへの適切な情報提供 • 根本原因分析の徹底 • 対処療法ではなく、再発防止のための原因究明
RTAとインシデント対応が異なるところ • RTAは予測可能な世界との戦い • インシデント対応は予測不可能 な世界との戦い • RTAのラン中は自分との戦い • インシデント対応中は自分・チーム・経営陣・顧客などあらゆるステーク
ホルダーが関与
War room インシデント発生時に迅速な意思決定を行っていくために関係者が招集される 部屋を作る。物理的な部屋がある場合はホワイトボードとマーカー、スクリーン。 加えて会議ブリッジやチャットツールの War roomが作られることもある 作業担当 CIO ユーザー担当
その他関係者 インシデントコマンダー
+ だと Teams 通話 (ZoomもOK) Slack チャンネル (TeamsもOK) JIRAや ServiceNow
と連携 必要な環境を自動生成 手作業は少なければ少ないほど良い!
ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップ
きちんと纏めておくことで、組織としての成長に繋がる。スタンドプレーだとこのあたりの取り組みが 行われないことが多い
+ だと Postmotems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント ノート、Slackの会話などからタイムラインを作成
マニュアル リアクティブ レスポンシブ 積極的 予防的 問題は社内チームではなく 顧客によって特定される。 オペレーションプロセスはレガ シーシステムに依存しており、イ ンシデントは手動で発生し、チ
ケットシステムなどのキューイン グワークフローを使用して処理 される。 緊急時に専門家に迅速にアク セスするための仕組みがほとん どない。 常に消火モード 初期の技術投資により、クラウ ドホスティングやアプリケーショ ンの成熟度に応じてリアルタイ ムでの可視化と動員が可能に なる。 分散型チームのアプローチが 見られるが、スキルはサイロ 化されている。 インシデントを管理するための 明確なプロセスがない。 問題が発生する前に先回り 優れた顧客体験が常に維持さ れる。 機械学習に基づく予測的な修 正が行われる。 組織全体で一貫したベストプラ クティスが実施される。 高度に自動化されたプロセスに より、雑務やエスカレーションが 排除される。 継続的な学習、改善、予防が技 術的でない関係者を含む組織 全体で行われる。 チームは変更の将来的な影響 を予測できる。 問題が発生するたびに解決 チームは顧客に影響を与える 問題をより迅速に把握できる。 機械学習を使用して潜在的な 問題を特定し、誤検知を減ら し、ノイズを低減する。 問題は自動的に特定され、専 門家によって対応されるが、適 切なチームを編成することは 依然として課題である。 分散型チームがマイクロサー ビスの完全な責任を持つよう になる。 シームレスで協調的な 問題管理 問題は顧客が気付く前に技術 チームによって検出・修正され る。 問題に関する情報は、ビジネス のステークホルダーを含む適切 な人物に提供される。 プログラム学習と最適化の機会 の特定が一般化している。 分散型チームは、サービス変更 の影響を理解し、運用の責任を 完全に負う。 チームとして対応し、運用の成熟度を上げていく
None