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
130
ゲームから学ぶ、いちばん速いインシデント対応
Cloud Operator Days Tokyo 2024で発表した資料です
Kazuto Kusama
October 02, 2024
Tweet
Share
More Decks by Kazuto Kusama
See All by Kazuto Kusama
Platform Engineeringで クラウドの「楽しくない」を解消しよう
jacopen
7
480
トラシューアニマルになろう ~開発者だからこそできる、安定したサービス作りの秘訣~
jacopen
3
3.3k
あなたの興味は信頼性?それとも生産性? SREとしてのキャリアに悩むみなさまに伝えたい選択肢
jacopen
7
6.9k
PaaSの歴史と、 アプリケーションプラットフォームのこれから
jacopen
7
2.2k
AI x インシデント管理で拡げるサービスオーナーシップ
jacopen
0
180
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
7
1.6k
2024/10 PagerDuty機能アップデート
jacopen
1
66
PEK2024 Recap
jacopen
2
180
クラウドネイティブの本質から考える、生産性と信頼性の両立
jacopen
3
960
Other Decks in Technology
See All in Technology
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
2k
大規模アジャイル開発のリアル!コミュニケーション×進捗管理×高品質
findy_eventslides
0
460
BCMathを高速化した一部始終をC言語でガチ目に解説する / BCMath performance improvement explanation
sakitakamachi
2
1.2k
ソフトウェアプロジェクトの成功率が上がらない原因-「社会価値を考える」ということ-
ytanaka5569
0
120
LINEギフトのLINEミニアプリアクセシビリティ改善事例
lycorptech_jp
PRO
0
240
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
2k
OPENLOGI Company Profile
hr01
0
61k
製造業の会計システムをDDDで開発した話
caddi_eng
3
930
Multitenant 23ai の全貌 - 機能・設計・実装・運用からマイクロサービスまで
oracle4engineer
PRO
2
110
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実
kzkmaeda
0
110
LINE Notify互換のボットを作った話
kenichirokimura
0
170
ドメインイベントを活用したPHPコードのリファクタリング
kajitack
2
1.1k
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.6k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
28
1.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Writing Fast Ruby
sferik
628
61k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
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