本文へスキップ

障害対応シナリオ

アラートが鳴ったときに「どこから見るべきか」を毎回その場で判断していては、対応が遅くなります。本ガイドでは、障害対応の担当者が検知から復旧・事後分析まで一貫した流れで実施できるよう、WhaTapの主要メニューをステップごとにどう繋いで使うか を整理します。

このガイドが向いている方
  • 障害対応を担当している、あるいはこれから担当するエンジニア
  • 障害対応プレイブックをチームに定着させたいリード・SRE
  • 「アラートは受け取るが、その次に何を見ればよいか分からない」メンバー

事前準備​

以下のクイックウィン3種が完了していることが、実運用の前提です。

障害対応の5ステップ​

① 検知 (Detect)  →  ② 影響範囲 (Scope)  →  ③ 原因分析 (Root Cause)
                                 ↓
                  ④ 復旧 (Mitigate)  →  ⑤ 事後分析 (Postmortem)

① 検知 — アラート確認​

ゴール: アラートが本当の異常かどうかを1分以内に判断する

  1. Slack・Email・SMS・アプリで受け取った通知から次を確認します。
    • レベル(Critical / Warning)
    • プロジェクト と エージェント名
    • 発動したイベントルール(例: 「CPU使用率の閾値超過」)
  2. 通知メッセージの ディープリンク をクリックして、WhaTap画面へ直接入ってください。
誤検知(False Positive)の切り分け

短時間スパイクのような誤検知が多い場合は、イベントルールの 持続時間 条件を上げてください(例: 1分 → 5分)。誤検知を放置するとチームがアラートを信用しなくなります。

② 影響範囲の把握 — どこまで広がったか​

ゴール: 何台のエージェント・サービス・トランザクションが影響を受けたかを2分以内に把握する

使用メニュー: アプリケーションダッシュボード またはチームのFlexboard

  1. アプリケーションダッシュボード で次を一目で確認します。
    • Apdex が急落しているか
    • TPS が異常に低い/高いか
    • 平均応答時間 が跳ねているか
    • エラー率 の上昇
  2. 複数のエージェントで同時に異常が出ていれば、インフラ・依存関係の問題 の可能性が高い(DB、ネットワークなど)。
  3. 特定のエージェントだけ異常なら、そのノード・インスタンスの問題 の可能性が高い。
障害 vs デプロイ

まず直近のデプロイがあったかを確認してください。デプロイ直後の異常であれば、ロールバックが最速の復旧 である場合が多いです。

③ 原因分析 — どこで遅くなったか​

ゴール: どのレイヤー(コード・SQL・外部呼び出し・リソース)が原因かを特定する

使用メニュー: ヒットマップ・トランザクション → トランザクショントレース → (必要に応じ) アクティブスタック

  1. ヒットマップ・トランザクション で遅くなった時間帯の点の集まりをドラッグして選択してください。
    • 色・位置から パターン をまず把握してください: 特定の時間帯だけ遅いのか、全体的に遅いのか。
  2. 選択した中で最も遅かったトランザクションをクリックして トランザクショントレース に入ってください。
    • 呼び出し関係: どのメソッド・SQL・HTTP呼び出しが時間を使っているか
    • スタックサンプル: コードのどこで待機しているか
  3. DBが疑わしい場合は DB接続状態 と Slow SQL を併せて確認してください。
  4. GC・メモリが疑わしい場合は ヒープメモリ と アクティブスタック を確認してください。
  5. スレッドの膠着やブロッキングが疑わしい場合は インスタンスパフォーマンス管理 の スレッド一覧・ダンプ を確認してください(インスタンスパフォーマンス管理の活用)。

AI分析で短縮する​

トレースやスタックを人が解釈するのに時間がかかるとき、WhaTapのAI分析機能で 一次仮説を素早く 立てられます。

  • AIアクティブスタック分析 — アクティブスタック 画面で疑わしいスタックを選択すると、AIがボトルネック区間や待機原因を自然言語で要約します。スレッドダンプが読めなくても「どのスレッドがどこで詰まっているか」が説明されます。特にGC・ロック・I/O待機の区別に有用です。
  • AIブラウザエラー・スタック分析 — フロントエンドのエラー追跡で、AIがエラースタックを解釈し、コードレベルの原因位置と対応方向を提案します。
  • WhaTap AIチャットボット / MCP — 自然言語で「このDBコネクションプールの数値は正常範囲か?」「このメトリクスが急増したときの対応は?」のような質問を投げ、ドキュメント・ガイド・類似事例に基づく回答を受けられます(現在ベータ、日本語対応予定)。
ノート

AI分析の結果は 一次仮説 として活用してください。最終判断は実際のトレース・スタック・ログを突き合わせて確認する必要があります。特にビジネス的な文脈(直近のデプロイ、トラフィックイベント)はAIには見えません。

関連する深掘りガイド:

トレース1件では足りないとき

1件のトレースは「事例」です。パターンを確認するには、同じ時間帯の複数トレースを比較してください。1件の特徴が他でも見えれば 共通原因、そうでなければ 個別の問題 です。

④ 復旧 — 応急処置​

ゴール: ユーザーへの影響を最小化する暫定措置を行う

原因別の基本措置:

表 | 原因別の迅速な復旧
原因の種類迅速な復旧
直近のデプロイ由来前のバージョンへロールバック
DBコネクションプール枯渇プールサイズ増加、またはSlow Queryを強制終了
特定ノードの障害該当ノードを再起動、またはロードバランサから除外
メモリリークプロセス再起動(根本対応は事後)
外部APIの障害該当機能を一時無効化 / フェイルオーバー
トラフィック急増オートスケールを確認、レートリミットを検討
復旧と原因分析は分ける

復旧は いまユーザーの影響を減らす作業、原因分析は なぜそうなったかを理解する作業 です。影響が続いている間に原因追求に時間を使うと被害が拡大します。まず復旧、完全な原因特定は ⑤ 事後分析 で続けましょう。

⑤ 事後分析 — 再発させないために​

ゴール: 再発防止アクションとドキュメント化

使用メニュー: イベント履歴(アラート発生履歴)+ トレース履歴

  1. イベント履歴 メニューで今回の障害の 時間帯と発動イベントの一覧 を確保してください。
  2. トレース・ログ画面から 証拠スクリーンショット を集めてください(後で再現が難しいため)。
  3. 事後分析ドキュメントにまとめます。
    • タイムライン: アラート発生 → 検知 → 復旧の時刻
    • 原因: ③で見つかった内容
    • 影響: 何分間、何人/何トランザクションに影響
    • 再発防止: イベントルール・アラート方針・コード/インフラの対応
  4. 再発防止項目のうち イベントルールの改善 はすぐに反映します。
    • より早く検知するための閾値調整
    • 新しいアラートルールの追加
    • アラート受信タグの再割り当て

チームに定着させる​

障害対応は 一人が上手いことより、チーム全員が同じ手順で行うこと が重要です。

  • 本ガイドをチームWikiに固定ブックマーク(クイックウィン2で作った共有ダッシュボードの隣に)
  • 担当者引き継ぎの際、「先週使用したトレース・イベント履歴」を共有
  • 四半期ごとに 事後分析の振り返り を繰り返す — パターンが見えたらイベントルールに昇格

次のステップ​

最終修正：