【レポート】インシデント対応を 10 倍速くする方法、教えます – PagerDuty と AWS で爆速障害対応　#AWSSummit

AWS Summit Japan 2024

AWS Summit Japan 2024 のセッション「インシデント対応を 10 倍速くする方法、教えます - PagerDuty と AWS で爆速障害対応」についてのレポートブログです。

#AWS

#セッションレポート

#PagerDuty

さいちゃん

2024.6.21

どうもさいちゃんです。2024 年 6 月 20 日、21 日に行われた AWS Summit Japan 2024 に参加し様々なセッションを視聴してきました。本記事は、「インシデント対応を 10 倍速くする方法、教えます - PagerDuty と AWS で爆速障害対応」というセッションにつてのレポートブログとなります。　

登壇者とセッション概要

登壇者

草間一人氏 PagerDuty 株式会社プロダクトエバンジェリスト

セッション概要

クラウドシフトによって企業のシステム運⽤は⼤きく変わりました。ハードウェアの運⽤や障害対応から解放された⽅は多いでしょう。ですが、クラウドはクラウドで独⾃の運⽤体制が必要です。クラウドによって潤沢なリソースが使えるようになり、運⽤するシステム数が数倍になった結果、以前より運⽤が⼤変になったという話もよく聞きます。DX の進む現代では、システムの安定運⽤は必要不可⽋です。本セッションでは、複雑かつ⼤規模なシステムにおいても、PagerDuty と AWS の組み合わせによってわずか数分でインシデント対応できるようにする⽅法をお話しします。 AWSSummit Japan セッション一覧

レポート

近年のインシデントマネジメントの傾向

近年インシデントマネジメントが脚光を浴びている
インシデント対応や、インシデントマネジメントに関してのイベントが多数開催されている
なぜ注目されているのか？
- サービスの重要性の高まり
- システムの複雑化、大規模化により、一つのシステムのダウンが他の会社やシステムにまで影響
- インシデントが起こった際のインパクトが大きくなってきている
- 技術の選択肢が多くなってきているためトラブルが起きた際の対応も複雑化している
どの様にインシデント管理を行っていますか？
- CloudWatch Alarmの利用や、Slack 通知等を行っているという組織も多いのではないか？
- アラートが出たことに気づいた複数人が、インシデントにそれぞれ対応するというような方法
- 深夜帯にインシデントが発生し、対応者が１人しかいなかった場合
- 複雑なシステムのインシデントに一人では対応しきれない or 時間がかかるといった問題も
- 上記のような課題を解決するには、インシデント対応をより体系的に行う必要がある
- 組織としての対応能力を高めることが現在のインシデント対応
- 組織としてフォーメーションを組むことで、本セッションのタイトル通り10 倍早い組織的対応が可能となる

体系的なインシデント対応を進めるために

インシデントコマンダー
- SRE というロール広まってきている
- インシデントコマンダーもシステム運用に重要な言葉
- コマンダーとは、「指揮官」のこと。つまり、インシデント対応の指揮者
- 日々のロールに関係なく、インシデントコマンダーがインシデント対応を進める上で最も位の高い人
- インシデントコマンダーは直接手を動かすわけではない
- 手を出さず、直接的なインシデント対応作業は、作業担当に委譲することが重要
- 誰がどの作業を担当するのか指示を出す立場
- 対応してくれる人、誰かいませんか？ではなく、明示的にアサインしていく必要がある
- なぜインシデントコマンダーが手を出してはいけない？
- 実際の作業だけがインシデント対応でない
- 関わる人々に情報共有や連携をとるといったコミュニケーションもインシデント対応には必要
- コマンド打ちながらコミュニケーションをとるのは難しい
- インシデントコマンダーはコミニケションに注力する（交通整理をする役割）
- インシデントの規模によっては複数のインシデントコマンダーが存在する場合もある
- 作業は他の人に委譲し、コミュニケーション（交通整理を行う）部分に注力することで最速で対応できる

体系的なインシデント対応のフローと PagerDuty の活用

PgerDuty の導入で体系的なインシデント対応がもっと楽に
トリアージ
- あらゆるツール()から検知したアラートを PagerDuty はトリアージしてくれる
- アラート検知サービスとの連携は簡単にできる
- アラートがたくさん出てきてもあまり役に立たないことも
  - いらないアラートなども多くある
  - インシデントに関係したちょっとしたアラートや現在対応しているものについては現場担当が無視している場合も多い
  - 無視するアラートなどは最初から送らない方が効率的
  - PagerDuty は機械学習などを使用して本当に必要なアラートだけをトリアージすることが可能
動員
- アラートを元に最適な人を動員する
- 電話やプッシュ通知など担当者ごとに通知方法を決定可能
- 深夜にアラートが起こった場合にもその時間の担当者にのみ通知を送ることが可能（担当者全員を起こす必要なし）
- グローバルに展開している企業の場合、地理的時差を活用し、この時間にはこの地域の担当者に連絡するといった設定が可能
- 担当者が不在の場合次の担当者に連絡するなどのローテーションも可能
協力/解決
- 影響範囲の把握
  - インシデントコマンダーの仕事の一つに状況の把握がある
  - 関連システムに影響が及んでいるかも？
  - インシデント自体が他のシステムからの影響の可能性も
  - 上記の様な場合は他のシステムの担当者を呼び出すなどの連携が可能
  - PagerDuty ではどのサービスがどのサービスに影響しているかを簡単に確認可能な機能を提供
- War room
  - 関係者が収集される場所
  - 会議室などの場合もあるが、最近はWeb会議の場合も多い
  - PagerDuty ではインシデントを検知したと同時に必要な環境を自動生成
  - JIRA チケットの起票や Slack 部屋作成、Teams や Zoom の部屋作製など
  - 上記のような対応は必要だが、インシデント中はすぐに対応するのが難しい場合も
- 関係者（ステークホルダー）とのコミュニケーションをとる上で大切なこと
  - 適切な粒度
  - 滑っての人に詳細を共有するのではなく、抽象化して分かりやすく伝えることも必要
  - 適切なタイミング
  - 報告のタイミングの話
  - 最初の報告からしばらく報告がないと関係者も不安になる
  - ステータスが変化した場合や定期的に報告
  - 適切な方法
  - ブロードキャスト型
  - 関係者それぞれに報告していると大変時間がかかる上に連絡漏れが発生してしまう場合も
  - 現状をどこか一か所に記載して関係者が確認できる様にしておく
  - こうすることで、関係者が増えても工数増えない
  - PagerDuty にも各関係者が確認できるステータスページを作る機能やステータスアップデートの機能がある
- 要員の管理
  - インシデント対応が長時間にわたることも
  - 疲弊した状態での対応は２次被害や対応に余計に時間がかかる場合のも
  - インシデントコマンダーが関係者の就労時間を把握して休ませることが必要。
  - PagerDuty では特定の人だけが対応していないか稼働時間の状況分析や確認ができるダッシュボードを提供
学習予防
- 過去のインシデント情報をまとめて管理
- 同じアラートに対して過去にどのように対応したかを確認する
- 関連インシデントを紹介する機能
  - 関連する Git の変更情報を見ることもできる（IaC を採用していてコードの変更でインシデントが起こった場合などに便利）
- 再発予防
  - ポストモーテム
  - インシデントのインパクトや解消のために行われたアクション、原因などをまとめること
  - 組織の成長につながる
  - PagerDuty ではポストモーテムを簡単に作れる
  - ポストモーテム作成時に時系列を様々な記録ややり取りを振り返り、時系列を整理するのはかなり大変
  - PagerDuty では Slack のやり取りなどから時系列をまとめてレポートを作ってくれる機能がある