ゲームから学ぶ
いちばん速いインシデント対応
PagerDuty - Product Evangelist
Kazuto Kusama @jacopenインシデント対応、どうやってますか？

インシデントがもたらす財務的影響

$100K

1時間
時間

Proprietary & Conﬁdential$250K

$5.4B
フォーチュン 500企業における財務的な損害額 (推計)Source: Parametrix

システムの安定稼働が至上命題に

コスト
売り上げ

企業イメージ・信頼性

Proprietary & Conﬁdential

営業利益率

顧客満足度

いかに早く インシデント対応できるかが大事

つまり

RTA

RTA (Real Time Attack)
RTAとは、ゲームをクリアするまでの実時間を競うプレイスタイル。海外では「Speed Run」とも呼ばれる

RTA (Real Time Attack)
RTAとは、ゲームをクリアするまでの実時間を競うプレイスタイル。海外では「Speed Run」とも呼ばれる

インシデント対応

RTAで大事なこと
•
•
•
•
•
•

徹底的なゲーム理解• ゲームのメカニクスを深く理解することが不可欠。仕組みの研究に多大な時間を割く
完璧な操作の習得• フレーム単位で入力するスキルが求められる
ルート最適化の継続• 常に新しいショートカットやテクニックを模索
分析と改善• 過去のランを記録し、セグメントごとの時間を分析。弱点を特定し重点的に練習
コミュニティとの連携• 他のランナーとの情報交換や競争によりモチベーション維持と技術向上
健康管理• 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ

インシデント対応で大事なこと
•
•
•
•
•
•

徹底的な理解と準備• システムやプロセスの深い理解、事前の計画と準備
迅速な対応と意思決定• 問題の素早い検知と初期対応
継続的な学習• 各インシデントからの教訓を活かした継続的な学習と改善
分析と改善• インシデントの詳細な分析と対応プロセスの最適化
チームワークとコミュニティの重要性• チーム内の連携や外部ステークホルダーとの協力
健康管理• 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ

PagerDuty Operations Cloud
インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ

1. 検知

2. トリアージ

3. 動員

あらゆるツールからイベントを受信インシデントを特定
⾃動処理

最適な担当者に通知

4. 協⼒/解決
迅速な解決を⽀援

5. 学習/予防
運⽤改善のための知⾒を提供

解決のヒントを提⽰

クラウド

●
●

コンテナ

過去の類似インシデント
直近の構成/コード変更...etc.

マイクロサービス

診断‧修復作業の⾃動化

ネットワークアプリ‧サービス

担当者が最適な通知⽅法を選択

セキュリティ

チーム内外と円滑に連携

データベース

架電、 SMS、メール
Appプッシュ通知、チャット

サーバー
ソーシャル

700+

80%-99%Integrations

ノイズ削減

⾃動エスカレーション
スケジュール管理

対応履歴
MTTA/MTTR 分析
担当者の負荷状況
ポストモーテム

ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化オンコール

必要なアラートだけに絞り込みオンコール

一次対応者

必要なアラートだけに絞り込み

電話やSMS、プッシュ通知、Slackなど、人それぞれ適した通知

オンコールのローテーション

オンコール

一次対応者(応答がなければ)二次対応者必要なアラートだけに絞り込み

電話やSMS、プッシュ通知、Slackなど、人それぞれ適した通知

オンコールのローテーションかしこくスケジュールJPEU

1:00-9:00 GMT

9:00-17:00 GMT

17:00-1:00 GMT

必要なアラートだけに絞り込み

電話やSMS、プッシュ通知、Slackなど、人それぞれ適した通知

グローバルな連携

US

+

だと

Past Incidents
過去の類似インシデント一覧と、発生時期・回数のヒートマップを表示。

Related Incidents
他サービスで現在発生している、関連性の高いインシデントを表示。

インシデント対応のカテゴリ
インシデント対応はAny%ではない
Any%とは･･･ 達成率関係なし、バグ利用あり、とにかく早ければいい
制約
•
•
•
•

安全性の確保。2次災害を起こしてはいけない
証拠の適切な収集と保全
ステークホルダーへの適切な情報提供
根本原因分析の徹底• 対処療法ではなく、再発防止のための原因究明

RTAとインシデント対応が異なるところ• RTAは予測可能 な世界との戦い• インシデント対応は予測不可能 な世界との戦い• RTAのラン中は自分との戦い• インシデント対応中は自分・チーム・経営陣・顧客などあらゆるステーク
ホルダーが関与

War room
インシデント発生時に迅速な意思決定を行っていくために関係者が招集される部屋を作る。物理的な部屋がある場合はホワイトボードとマーカー、スクリーン。
加えて会議ブリッジやチャットツールのWar roomが作られることもある

CIO
ユーザー担当インシデントコマンダー

その他関係者

作業担当

だと

+

Teams
通話
(ZoomもOK)

JIRAやServiceNow
と連携

Slack
チャンネル
(TeamsもOK)

必要な環境を自動生成
手作業は少なければ少ないほど良い！

ポストモーテム
SREのプラクティスでおなじみ•

インシデントのインパクト•

緩和や解消のために行われたアクション

•

根本原因

•

インシデントの再発を避けるためのフォローアップ

きちんと纏めておくことで、組織としての成長 に繋がる。スタンドプレーだとこのあたりの取り組みが行われないことが多い+だとPostmotems
ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント
ノート、Slackの会話などからタイムラインを作成

チームとして対応し、運用の成熟度を上げていく
マニュアル

リアクティブ

レスポンシブ

積極的

予防的

問題は社内チームではなく顧客によって特定される。

常に消火モード

問題が発生するたびに解決

シームレスで協調的な問題管理問題が発生する前に先回り

オペレーションプロセスはレガ
シーシステムに依存しており、インシデントは手動で発生し、チケットシステムなどのキューイン
グワークフローを使用して処理される。

初期の技術投資により、クラウ
ドホスティングやアプリケーショ
ンの成熟度に応じてリアルタイ
ムでの可視化と動員が可能になる。

チームは顧客に影響を与える
問題をより迅速に把握できる。

問題は顧客が気付く前に技術チームによって検出・修正される。

優れた顧客体験が常に維持される。

緊急時に専門家に迅速にアクセスするための仕組みがほとん
どない。

分散型チームのアプローチが見られるが、スキルはサイロ化されている。
インシデントを管理するための明確なプロセスがない。

機械学習を使用して潜在的な問題を特定し、誤検知を減らし、ノイズを低減する。
問題は自動的に特定され、専門家によって対応されるが、適切なチームを編成することは依然として課題である。
分散型チームがマイクロサー
ビスの完全な責任を持つようになる。

問題に関する情報は、ビジネスのステークホルダーを含む適切な人物に提供される。
プログラム学習と最適化の機会の特定が一般化している。
分散型チームは、サービス変更の影響を理解し、運用の責任を完全に負う。

機械学習に基づく予測的な修正が行われる。
組織全体で一貫したベストプラ
クティスが実施される。
高度に自動化されたプロセスにより、雑務やエスカレーションが排除される。
継続的な学習、改善、予防が技術的でない関係者を含む組織全体で行われる。
チームは変更の将来的な影響を予測できる。