ゲームから学ぶ、いちばん速いインシデント対応

Cloud Operator Days Tokyo 2024で発表した資料です

Transcript

1. ゲームから学ぶ いちばん速い インシデント対応 PagerDuty - Product Evangelist Kazuto Kusama @jacopen
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association
3. 本日ブースでワンオペしてます！
4. インシデント対応、どうやってますか？
5. Proprietary & Confidential 1時間 時間 $100K $250K インシデントがもたらす財務的影響
6. $5.4B フォーチュン 500企業における 財務的な損害額 (推計) Source: Parametrix
7. Proprietary & Confidential システムの安定稼働が至上命題に コスト 企業イメージ ・信頼性 売り上げ 顧客満足度 営業利益率
8. いかに早く インシデント対応できるかが大事
9. つまり RTA
10. RTA (Real Time Attack) RTAとは、ゲームをクリアするまでの実時間を競うプレイスタイル。海外では「 Speed Run」とも呼ばれる
11. RTA (Real Time Attack) RTAとは、ゲームをクリアするまでの実 時間を競うプレイスタイル。海外では 「Speed Run」とも呼ばれる インシデント対応
12. RTAで大事なこと • 徹底的なゲーム理解 • ゲームのメカニクスを深く理解することが不可欠。仕組みの研究に多大な時間を割く • 完璧な操作の習得 • フレーム単位で入力するスキルが求められる • ルート最適化の継続 • 常に新しいショートカットやテクニックを模索 • 分析と改善 • 過去のランを記録し、セグメントごとの時間を分析。弱点を特定し重点的に練習 • コミュニティとの連携 • 他のランナーとの情報交換や競争によりモチベーション維持と技術向上 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
13. インシデント対応で大事なこと • 徹底的な理解と準備 • システムやプロセスの深い理解、事前の計画と準備 • 迅速な対応と意思決定 • 問題の素早い検知と初期対応 • 継続的な学習 • 各インシデントからの教訓を活かした継続的な学習と改善 • 分析と改善 • インシデントの詳細な分析と対応プロセスの最適化 • チームワークとコミュニティの重要性 • チーム内の連携や外部ステークホルダーとの協力 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
14. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防 ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
15. インシデント対応で大事なこと • 徹底的な理解と準備 • システムやプロセスの深い理解、事前の計画と準備 • 迅速な対応と意思決定 • 問題の素早い検知と初期対応 • 継続的な学習 • 各インシデントからの教訓を活かした継続的な学習と改善 • 分析と改善 • インシデントの詳細な分析と対応プロセスの最適化 • チームワークとコミュニティの重要性 • チーム内の連携や外部ステークホルダーとの協力 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
16. オンコール 必要なアラートだけに絞り込み
17. オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 オンコールの ローテーション
18. オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 (応答がなければ) 二次対応者 オンコールの ローテーション
19. かしこくスケジュール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 9:00-17:00 GMT グローバルな連携 JP EU US 17:00-1:00 GMT 1:00-9:00 GMT
20. インシデント対応で大事なこと • 徹底的な理解と準備 • システムやプロセスの深い理解、事前の計画と準備 • 迅速な対応と意思決定 • 問題の素早い検知と初期対応 • 継続的な学習 • 各インシデントからの教訓を活かした継続的な学習と改善 • 分析と改善 • インシデントの詳細な分析と対応プロセスの最適化 • チームワークとコミュニティの重要性 • チーム内の連携や外部ステークホルダーとの協力 • 健康管理 • 常に安定したパフォーマンスを出すため、また継続して改善を続けるためのサステナビリティ
21. + だと Past Incidents 過去の類似インシデント一覧と、 発生時期・回数のヒートマップを表示。 Related Incidents 他サービスで現在発生している、 関連性の高いインシデントを表示。
22. インシデント対応のカテゴリ インシデント対応はAny%ではない Any%とは･･･ 達成率関係なし、バグ利用あり、とにかく早ければいい 制約 • 安全性の確保。2次災害を起こしてはいけない • 証拠の適切な収集と保全 • ステークホルダーへの適切な情報提供 • 根本原因分析の徹底 • 対処療法ではなく、再発防止のための原因究明
23. RTAとインシデント対応が異なるところ • RTAは予測可能な世界との戦い • インシデント対応は予測不可能 な世界との戦い • RTAのラン中は自分との戦い • インシデント対応中は自分・チーム・経営陣・顧客などあらゆるステーク ホルダーが関与
24. War room インシデント発生時に迅速な意思決定を行っていくために関係者が招集される 部屋を作る。物理的な部屋がある場合はホワイトボードとマーカー、スクリーン。 加えて会議ブリッジやチャットツールの War roomが作られることもある 作業担当 CIO ユーザー担当 その他関係者 インシデントコマンダー
25. + だと Teams 通話 (ZoomもOK) Slack チャンネル (TeamsもOK) JIRAや ServiceNow と連携 必要な環境を自動生成 手作業は少なければ少ないほど良い！
26. ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップ きちんと纏めておくことで、組織としての成長に繋がる。スタンドプレーだとこのあたりの取り組みが 行われないことが多い
27. + だと Postmotems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント ノート、Slackの会話などからタイムラインを作成
28. マニュアル リアクティブ レスポンシブ 積極的 予防的 問題は社内チームではなく 顧客によって特定される。 オペレーションプロセスはレガ シーシステムに依存しており、イ ンシデントは手動で発生し、チ ケットシステムなどのキューイン グワークフローを使用して処理 される。 緊急時に専門家に迅速にアク セスするための仕組みがほとん どない。 常に消火モード 初期の技術投資により、クラウ ドホスティングやアプリケーショ ンの成熟度に応じてリアルタイ ムでの可視化と動員が可能に なる。 分散型チームのアプローチが 見られるが、スキルはサイロ 化されている。 インシデントを管理するための 明確なプロセスがない。 問題が発生する前に先回り 優れた顧客体験が常に維持さ れる。 機械学習に基づく予測的な修 正が行われる。 組織全体で一貫したベストプラ クティスが実施される。 高度に自動化されたプロセスに より、雑務やエスカレーションが 排除される。 継続的な学習、改善、予防が技 術的でない関係者を含む組織 全体で行われる。 チームは変更の将来的な影響 を予測できる。 問題が発生するたびに解決 チームは顧客に影響を与える 問題をより迅速に把握できる。 機械学習を使用して潜在的な 問題を特定し、誤検知を減ら し、ノイズを低減する。 問題は自動的に特定され、専 門家によって対応されるが、適 切なチームを編成することは 依然として課題である。 分散型チームがマイクロサー ビスの完全な責任を持つよう になる。 シームレスで協調的な 問題管理 問題は顧客が気付く前に技術 チームによって検出・修正され る。 問題に関する情報は、ビジネス のステークホルダーを含む適切 な人物に提供される。 プログラム学習と最適化の機会 の特定が一般化している。 分散型チームは、サービス変更 の影響を理解し、運用の責任を 完全に負う。 チームとして対応し、運用の成熟度を上げていく