Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インシデント対応に必要となるAIの利用パターンとPagerDutyの関係

 インシデント対応に必要となるAIの利用パターンとPagerDutyの関係

ゆるSRE勉強会 #11 で発表した資料です

Avatar for Kazuto Kusama

Kazuto Kusama

June 13, 2025
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防

    0. 備え インシデント対応フロー ここにどうAIを適用できるか
  2. ⽣成AI / AIエージェント AIOps 「AI」を区別して抑える 2017年にGartnerが提唱。 “AI for IT Operations”

    の略 監視データをMLで処理し運用タスクを 自動化するのが原点 構造化テレメトリ(メトリクス、ログ、トレー ス、イベント)を入力し、アラートノイズ削 減、イベント相関・根本原因の解析を行う 2022年以降のLLMブームで登場。自然 言語を理解・生成できるLLMを中心にし た仕組み ドキュメント、Slack スレッド、インシデント タイムライン、Runbook、ソースコードな ど 非構造テキストや画像を入力として扱 える
  3. ⽣成AI / AIエージェント AIOps 「AI」を区別して抑える 大量イベントをインプット → 相関・判断 → 自動アクション

    というストリーム処理パイプライン 大量のデータを素早く分析して結果を出 す、検知やトリアージのフェーズに向いて いる プロンプト →推論 →外部ツール呼び出し → 追加質問 という 対話ループ 非構造化データからインサイトを導き出 したり、言語生成によりコミュニケーショ ンに活用できる
  4. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防

    0. 備え 障害の「検知」をAIで高度化する 各オブザーバビリティベンダーが積極的に機能を開発中 • 異常検知 • 因果分析 • インサイト • 早期アラート 主にAIOps
  5. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防

    0. 備え 上がってきたアラートからノイズの除去を行い、対応すべ きアラートのみを抽出する。 抽出したアラートを過去の情報をもとに優先順位付けを 行う 主にAIOps
  6. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防

    0. 備え トリアージされたアラートを元に 適切なエスカレーションを行う。 基本はルールベース ただし、これまで人間の感覚に頼ってきた「いつ誰 にエスカレーションすべきか」をAIエージェントに判 断させる。 • 所属チーム • 有給休暇 • 稼働率
  7. 原因特定 復旧 4. 協⼒/解決 コミュニケーション AIOps + LLM 大量のアラート、メトリクス、ログからの分析 (AIOps)

    上記のインサイトを受けてAIエージェントが自律的に判断。次の一手を打つ その結果を受けて再度判断して・・・を繰り返し、最終的に考えられる原因を提示する
  8. 原因特定 復旧 4. 協⼒/解決 コミュニケーション LLM + Runbook 原因が判明したら、復旧に向けての取り組みを行う。 原因が既知のものであり、対処のための

    Runbookが存在するのであればAIエージェン トが自動的に実行。 原因がある程度分かっているが全てではない場合、 AIエージェントが主体となって切り 分けを実行。 未知の障害の場合は人間が主体になって作業に当たる
  9. インシデントの類型 ⼗分理解 している チームはこのシナリオを 経験済みで、何をすべきか を熟知している 100% AIと⾃動化 AIと⾃動化 +

    対応者によるアシスト 対応者主導+ AIと⾃動化 部分的に 理解している チームはこのような事態を経 験済みで、潜在的な修復⼿段 を知っている。 未知で新しい 新規、または専⾨家の 注意が必要なインシデント
  10. 原因特定 復旧 4. 協⼒/解決 コミュニケーション LLM インシデント対応の半分はコミュニケーション ステークホルダー (経営陣、CS、関連チーム etc..)に

    適切な粒度で適切なタイミングでコミュニケーションを取ることが重要 • ZoomやTeamsの会話を自動的に文字起こししてサマライズ • 会話やSlackログ、チケットなどの情報をまとめて対応状況の把握 • 上記の情報を元に、自動的にステークホルダーに情報を共有 LLMの強みが全力で生かせる領域
  11. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防

    0. 備え LLM ポストモーテム・ポストインシデントレビューでも LLM は大いに活用出来る インシデントのサマリー、タイムラインの生成、根本 原因のサマリー、ネクストアクションの抽出
  12. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防

    0. 備え Runbookの整備 原因特定や復旧をスムーズに行えるようにするための Runbookを整備しておく。過去のインシ デントや構成情報を元に手順書や FAQを整備。さらに自動化スクリプトを生成 シミュレーション/演習シナリオ作成 障害ストーリーの生成やロールプレイを生成。チャットで対話的にインシデント対応の演習を行 うことも。 このあたりもLLMの強みを発揮できる分野
  13. PagerDuty AI Agent 通知 担当者アサイン 様々な⼿段で 応答 復旧作業案の 提⽰と実⾏ 事後報告と

    改善策⽴案 診断、復旧 ジョブ⾃動実⾏ 情報収集 状況の把握 データ分析 問題の可視化 絶え間ないコミュニケーション、アクション、学習の実施を AI Agent が⽀援 インシデント 起票判断 開発者 & パートナー エコシステム PagerDuty AI Agent を活⽤した システム運⽤のライフサイクル セキュリティ コンプライアンス対応 AI 運⽤基盤 システム利⽤者への コミュニケーション 検知 トリアージ 動員 診断‧復旧 解決 サードパーティ製 Agent ⼈と AI Agent が協調してインシデント対応 アラート発⽣ AI Agent が過去データを元に初動対応 AI Agent が対応履歴を元に改善案を提⽰ 改善策の適⽤ & パートナー様の AI Agent と連携し、様々なツールと繋がる
  14. AI Powered Incident Management Platform AI Agent を活⽤した次世代の運⽤基盤 全体像 システム

    構成情報 インシデント 情報 監視データ インシデント 対応⼿順 主要な インシデント 情報 システム 変更情報 Cloud Infrastructure Monitoring - On-prem DC Monitoring - Public Cloud Security JP1 Senju Systemwalker Code/Config Management ITSM/Ticket 管理 Amazon Q Business on Amazon Bedrock PagerDuty Operations Cloud PagerDuty AI Agent Bedrock Guardrails セキュリティ保護と コンプライアンスの遵守 インシデントコマンダー∕運⽤担当者 Plug-in (標準提供) その他の 3rd party AI Agent 今後 対応予定 Web 会議や チャットの会話 データソース(DB/Document/SNS/etc.)