生成 AI を活用した障害対応初動の改善

© 2025, Amazon Web Services, Inc. or its aﬃliates. All
rights reserved. © 2025, Amazon Web Services, Inc. or its aﬃliates. All rights reserved. Mitsuaki Tsugo J A W S S R E 支部＃ 1 3 Solutions Architect Amazon Web Service Japan G.K. ⽣成 AI を活⽤した障害対応初動の改善

rights reserved. ⾃⼰紹介津郷光明 Mitsuaki Tsugo アマゾンウェブサービスジャパンソリューションアーキテクト製造業のお客様の課題解決をご⽀援しています最近のテーマ Observability / Infrastructure as Code x ⽣成 AI

rights reserved. Agenda • 障害対応における課題 • 障害対応の優先度や必要性をどのように判断するか • Multi-layered Observability を活⽤した⾼度化 • ⽣成 AI を活⽤した⾼速化 • まとめ 3

rights reserved. SRE のプラクティス Dickerson の信頼性の階層構造インシデント後のレビューインシデントレスポンスモニタリング／オブザーバビリティ UX 開発テスト／リリースキャパシティ／スケール信頼性の情報源『SRE をはじめよう』 14章より信頼性の維持と持続可能な体制障害を価値に変えるプロセス障害の軽減パフォーマンス

rights reserved. 6 障害に対応している時は… 時間との戦い正確性が求められる意思決定の難しさ

rights reserved. 更なる難しさ - 本当に“今”対処が必要︖ - 複数の問題が同時発⽣した時、どれを最優先で対処すべき︖ - 新機能開発と障害対応、どちらを優先すべき︖ 7 何を最優先で対処すべきか・今すぐ対処が必要か短時間で判断することは難しい

rights reserved. 8 障害対応の優先度や必要性をどのように判断するか

rights reserved. SLI/SLO モニタリング SLI SLO エラーバジェットサービスレベル指標(Service Level Indicator) メトリクスで特定される計測値、つまりサービスのある種の特性を表す 1 つのデータ優れた SLI は、ユーザーの観点からサービスを計測サービスレベル⽬標(Service Level Objective) ⽬指すべき SLI に対する⽬標値多くの場合パーセントサービスにおいて⽬標値とされる「適切な信頼性のレベル」エラーバジェット(Error Budget) ⼀定の期間にわたって SLI が SLO に対してどのように実⾏されたかを計測する⼿段その期間内にサービスがどの程度信頼できないことを許容されるかを定義し、是正措置を講じる必要がある時を⽰すシグナルとして機能 SLO サービスレベル⽬標 1 章より引⽤信頼性スタック

rights reserved. 障害対応の優先度をどう決めていくか “唯⼀無⼆の正解” はない。1 つの例として AWS Well-Architected Framework セキュリティコスト効率運⽤上の優秀性パフォーマンス効率信頼性持続可能性 OPS10-BP03 ビジネスへの影響に基づいて運⽤上のイベントの優先度を決定する⼀般的なアンチパターン: • すべてのイベントが同じ緊急度で扱われるため、混乱が⽣じ、重⼤な問題への対処が遅れる。 • 影響の⼤きいイベントと⼩さいイベントの区別がつかず、リソースの誤配分につながる。 • 組織に明確な優先順位付けのフレームワークがないため、運⽤上のイベントへの対応に⼀貫性がなくなる。 • イベントの優先順位が、ビジネス成果への影響ではなく、報告された順序で決まる。実装⼿順︓ 1. 影響を評価する 2. 緊急度を評価する 3. 優先順位付けのマトリクスを作成する 4. トレーニングとコミュニケーションを⾏う: 5. インシデント対応に統合する 6. ⾒直して適応させる https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational- excellence-pillar/ops_event_response_prioritize_events.html

© 2025, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 障害対応の優先度をどう決めていくか Step1 Business Impact Assessment Step2 Technical Severity Assessment Step3 Priority Matrix Decision - ユーザー影響度（影響ユーザー数、体験への影響、代替⼿段） - 収益・ブランド影響度（売上損失、SLA違反補償、外部可視性） - 法的・コンプライアンス（規制違反リスク、セキュリティ影響） - サービス可⽤性（停⽌vs劣化、主要vs副次機能、ピーク時間） - システム安全性（データ損失リスク、障害拡⼤リスク、複雑度） - ビジネス影響度 × 技術影響度の組み合わせで優先度を決定 - P0（15分以内即時対応）～ P3（計画対応）の明確な判定基準を作成し照らし合わせ - SLI/SLOは継続監視・⻑期管理に活⽤サイトリライアビリティワークブック 8章参考

rights reserved. 12 そんなことを短時間（数分）で判断できない︕ チーム間の連携や調整も必要︕ ⼤体そんな分析できるメンバーは少ない︕

rights reserved. ⾼度化・⾼速化へのアプローチ 13 ⽣成 AI による考察提⽰＋ Multi-layered Observability

rights reserved. Multi-layered Observability 15 Infrastructure Layer Application Layer Business Layer システムの基盤の状況エンドユーザー体験の実態ビジネス影響度（ユーザー数、収益、評判、法的要件）ビジネス層を含めた3層に切り分けてテレメトリを取得する下から上に向かって取り組んでいく取り組みのながれ

rights reserved. Multi-layered Observability の必要性従来の監視と障害対応の難しさインフラ監視だけ︓ 「CPUが⾼い」しかわからないアプリ監視だけ︓「エラーが増えた」しかわからないビジネス監視だけ︓ 「売上が下がった」しかわからない結果︓ 優先度や即時対応の必要性判断ができない場合によっては影響範囲が特定できず対応策を整理できないインフラからビジネスまでトータルでの評価・判断が必要 16

rights reserved. 実際に取得するテレメトリの例 17 Infrastructure Layer Application Layer Business Layer システムの基盤の状況エンドユーザー体験の実態取り組みのながれビジネス影響度（ユーザー数、収益、評判、法的要件）

rights reserved. 実際に取得するテレメトリの例 18 Infrastructure Layer Application Layer • リソース関連（CPU / memory） • I/O (ディスク/ Network） • コンテナサービス/サーバレスサービスなど • レスポンスタイム / エラー率 • 分散トレーシング / サービスマップ • アプリケーションログなど従来より議論されている領域

rights reserved. Amazon CloudWatch Application Signals テレメトリデータの⾃動収集 AWS Distro for OpenTelemetry 利⽤サービスの検出/トポロジー可視化ダッシュボード提供トレース・メトリクスの確認 SLO モニタリング CloudWatch Synthetics / CloudWatch RUMとの連携アプリケーションの状態を把握・分析するための情報を⾃動で収集・可視化 CloudWatch / X-Ray の機能を集約し Application Performance Monitoring に特化

rights reserved. CloudWatch Application Signals SLO ダッシュボードサービスダッシュボードサービスマップサービス詳細 RUM Synthetics Canary トレースインサイト複数テレメトリを関連付けて確認できるダッシュボードがすぐに利⽤可能

rights reserved. 実際に取得するテレメトリの例 21 Infrastructure Layer Application Layer Business Layer システムの基盤の状況エンドユーザー体験の実態取り組みのながれビジネス影響度（ユーザー数、収益、評判、法的要件）

rights reserved. 実際に取得するテレメトリの例 22 Business Layer • 収益・売上関連 • リアルタイム売上、コンバージョン率、平均注⽂単価、決済成功率、カート放棄率 • ユーザー影響度 • アクティブユーザー数、新規ユーザー獲得数、ユーザー離脱率、顧客満⾜度スコア、サポート問い合わせ数 • ブランド・評判 • ソーシャルメディア⾔及数、アプリストア評価、検索ランキング、メディア⾔及 • 法的・コンプライアンス • データ保護違反件数、セキュリティインシデント数、監査ログの完全性、SLA違反件数

rights reserved. Business Layer のデータ取得⽅式の例 23 1. Amazon Kinesis Data Stream を起点としたニアリアルタイム分析アプリケーションの取引ログや API コールをリアルタイムでストリーミング処理し、売上やコンバージョン率を秒単位で計算・監視 Amazon Kinesis Data Streams Amazon Data Firehose Amazon S3 AWS Lambda Amazon CloudWatch 2. Amazon EventBridge + Lambda + CloudWatch カスタムメトリクス Amazon EventBridge AWS Lambda Amazon CloudWatch 外部 API 含むデータストア定期的に外部データストアからデータを取得し CloudWatch カスタムメトリクスとして管理・監視

rights reserved. Multi-layered Observability と障害対応 24 Infrastructure Layer Application Layer Business Layer システムの基盤の状況エンドユーザー体験の実態ビジネス影響度（ユーザー数、収益、評判、法的要件）障害対応の優先度、必要性については全ての Layer のデータを確認し、判断する必要がある取り組みのながれ

rights reserved. 障害対応の優先度をどう決めていくか Application Layer Business Layer Infrastructure Layer サイトリライアビリティワークブック 8章参考もう少し具体的にみていくと Application Layer Business Layer Infrastructure Layer Step1 Business Impact Assessment Step2 Technical Severity Assessment Step3 Priority Matrix Decision - ユーザー影響度（影響ユーザー数、体験への影響、代替⼿段） - 収益・ブランド影響度（売上損失、SLA違反補償、外部可視性） - 法的・コンプライアンス（規制違反リスク、セキュリティ影響） - 対応レイヤー︓ - サービス可⽤性（停⽌vs劣化、主要vs副次機能、ピーク時間） -システム安全性（データ損失リスク、障害拡⼤リスク、複雑度） -対応レイヤー︓ - ビジネス影響度 × 技術影響度の組み合わせで優先度を決定 - P0（15分以内即時対応）～ P3（計画対応）の明確な判定基準を作成し照らし合わせ - SLI/SLOは継続監視・⻑期管理に活⽤

rights reserved. LLM は相関分析も⼀定の精度で出⼒可能 27 ⽣成 AI 、特に⼤規模⾔語モデル ( Large Language Model, LLM )は、⾼い⾃然⾔語処理能⼒を持つ。これは障害対応においても活⽤できる⽂書要約質問応答雑談・対話⽂書の⽣成・校正感情分析情報抽出テキスト分類コード⽣成 LLM のユースケース例

rights reserved. LLM が活⽤できそうな障害対応のタスク例 • イベント通知⽂⾔の解説や要約 • テレメトリから原因と関連箇所の抽出 • 依存関係整理 • 相関分析 • 設計書などドキュメントの解説 • ソースコードの解説や改修提案 • 報告資料や⼿順書、障害情報の作成障害分析 • システム状況確認 • ビジネス影響確認 • 原因調査イベント通知 • 監視からの通知 • ユーザとの連絡暫定対処 • 復旧処置 • 復旧確認本格対処 • （必要に応じて）恒久処置再発防⽌ • 類似障害の発⽣を抑⽌する対策 • 障害情報の蓄積 • 復旧⼿順の整備

rights reserved. LLM が活⽤できそうな障害対応のタスク例 Infrastructure Layer Business Layer Application Layer の相関分析や障害対応の優先度決めの 3Step を LLM を利⽤して数分で実現する障害分析 • システム状況確認 • ビジネス影響確認 • 原因調査

rights reserved. LLM を利⽤したチャットでの障害原因の特定 User 分散管理されたテレメトリデータデータ収集と要約 Chat App Amazon CloudWatch Logs AWS X-Ray Amazon S3 Amazon Athena LLM (Agent) Infrastructure Layer Business Layer Application Layer

rights reserved. FA2 で提供する範囲 32 Failure Analysis Assistant (FA2) アーキテクチャ Amazon CloudWatch (Metrics) Amazon CloudWatch (Logs) AWS X-Ray 運⽤者 Amazon S3 Amazon Athena Amazon Bedrock Knowledgebase AWS Lambda Amazon Bedrock （LLM） Agent 既存システム AWS Lambda Amazon API Gateway Amazon DynamoDB （Agent 状態管理）（RAG データソース） ①解析起動 ②該当データ収集 ③相関分析・要約

rights reserved. FA2 で提供する範囲 33 Failure Analysis Assistant (FA2) アーキテクチャ Amazon CloudWatch (Metrics) Amazon CloudWatch (Logs) AWS X-Ray 運⽤者 Amazon S3 Amazon Athena Amazon Bedrock Knowledgebase AWS Lambda Amazon Bedrock （LLM） Agent 既存システム AWS Lambda Amazon API Gateway Amazon DynamoDB （Agent 状態管理）（RAG データソース） ①解析起動 ②該当データ収集 ③相関分析・要約エラーの概要、発⽣時刻を AWS Lambda へのリクエストに含める必要なテレメトリを⾃動判別 RAG を利⽤して精度向上

rights reserved. ⼗分な情報が集まるまで、思考→⾏動→観察を繰り返し最後に Markdown でレポート⽣成 FA2 実⾏結果のサンプル

rights reserved. © 2025, Amazon Web Services, Inc. or its aﬃliates. All rights reserved. 35 CloudWatch MCP Server CloudWatch Application Signals MCP Server https://github.com/awslabs/mcp/tree/main/src/cloudwatch-mcp-server https://github.com/awslabs/mcp/tree/main/src/cloudwatch-appsignals-mcp-server

rights reserved. 36 AWS MCP Servers

rights reserved. 37 Available Tools - CloudWatch Application Signals MCP Server 1. list_monitored_services - List all services monitored by AWS Application Signals 2. get_service_detail - Get detailed information about a specific service 3. list_slis - List all SLOs and SLIs status for all services 4. get_slo - Gets the details configuration for a specific SLO 5. search_transaction_spans - Queries OTel Spans data via Transaction Search 6. query_sampled_traces - Queries AWS X-Ray traces to gain deeper insights 7. query_service_metrics - Queries Application Signals metrics for root causing service performance issues h"ps://awslabs.github.io/mcp/servers/cloudwatch-appsignals-mcp-server

rights reserved. “CloudWatch Application Signals のサービスを確認し、SLO に問題があるか、またレイテンシーの増加傾向の有無を教えてください。もし SLO に問題があったり、レイテンシーに増加傾向がある場合は、その原因を調査してください。” 実⾏結果のサンプル CloudWatch Application Signals で 7 つのサービスで SLO 定義済み - pet-clinic-frontend-java - customers-service-java - visits-service-java - vets-service-java - insurance-service-python - billing-service-python - payment-service-dotnet

rights reserved. 39

rights reserved. 本セッションのまとめ • Multi-layered Observability を意識することで障害対応の優先度を効率的に判断できる • 特にビジネス層でのメトリクス取得が重要 • ⽣成 AI 、特に LLM を利⽤することで分析を⾼速化できる • AWS ではソリューション FA2 を aws-samples で公開している • AWS MCP Servers に CloudWatch MCP Server , CloudWatch Application Signals MCP Server があり状態把握や分析を LLM を利⽤して⾼速に実施可能 • ただし LLM のアウトプットを鵜呑みにせず最後は⼈間の判断で⾏動する 41

生成 AI を活用した 障害対応初動の改善

生成 AI を活用した 障害対応初動の改善

More Decks by Mitsuaki Tsugo

Featured

Transcript

生成 AI を活用した障害対応初動の改善

生成 AI を活用した障害対応初動の改善