Azure インシデント切り分け時に試したほうがよさそうなガイド
目次
- はじめに
- インシデント対応の全体フロー（OODA ベース）
- 最初の3分：観測と優先度判定
- 次の5分：原因仮説と速やかな切り分け
- フェーズ別対応：Mitigation → Remediation → Post-Incident
- サービス別チェックリスト（Azure 向け）
- よくある失敗と対策
- 実例シナリオ（5選）
- まとめとチェックリスト
はじめに
Azure 環境でインシデントが発生した際、迅速かつ体系的に状況を切り分けるためのオレオレガイドラインを作ってみました。目的は「影響を最小化し、短時間で安定化させ、その後根本原因を排除する」ことです。
(AWS側を書いてみたところ、「そういえば僕ってAzureのほうがよく使うのでは…？（震）」と思ったので、
せっかくなのでAzure版も試しにということで…
※あくまでもn=1のお気持ちネタの個人メモです。
本記事は以下3点を軸に記載しました。
- 優先的に見るべき観測ポイント
- 3分→5分→10分の段階的診断フロー
- Azure 固有の観測/修復手順（Azure Monitor / Application Insights / Resource Health / Activity Log / Azure Policy / Azure AD / Key Vault 等）
インシデント対応の全体フロー（OODA）
AWS同様、観測（Observe）→方向付け（Orient）→判断（Decide）→実行（Act）のループを短いサイクルで回します。
- Observe（1分）: まず証拠を集める（メトリクス、ログ、リソースヘルス）。
- Orient（2分）: 影響範囲（全体/リージョン/サービス/ユーザー）を決定。
- Decide（2分）: Mitigation（止血）か Remediation（恒久対応）かを決定。
- Act（5分以内）: 小さな変更1つを実施し効果を観測。
3〜5分ごとに観測を更新して判断を繰り返します。
原則
- 最初の3分は観測に専念
- 変更は小さく、ロールバック手順を事前に用意
- 仮説ベースで行動（断定は事後）
※結局小さな変更を積み重ねていくのは一緒ってことですね。ひたすらA/Bテストやって事実積み上げていく感じ、というような雰囲気なのかなあ、と。やっぱり人間は差分で物事判断しやすいってことなんっすかね。
最初の一手：観測と優先度判定
ステップ 1：ダッシュボードとアラートを素早く確認（優先順）
- Azure Monitor / Application Insights（Overview）
- Resource Health（対象リソースのステータス）
- Azure Service Health（リージョン・サービス側障害）
- Activity Log（設定変更・管理操作の記録）
- Network Watcher（ネットワーク関連）
Azure CLI のサンプル（素早い確認）
# 最近のアラート一覧（過去1時間）
az monitor scheduled-query-rule list --query "[?enabled==`true`]" --top 50
# リソースのヘルス
az resource show --ids /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm> --query "properties.provisioningState"
# Activity Log（過去1時間の管理操作）
az monitor activity-log list --offset 60m
見るべき主要指標（優先度）
- エラー率（HTTP 4xx/5xx、Function の失敗数）
- レイテンシ（依存サービスを含む）
- リソースヘルス（VM/AKS/Function/CosmosDB の状態）
- リソース利用率（CPU/Memory/Connections/IO）
- 直近の設定変更（Activity Log）
ステップ 2：スコープを決める
- 影響範囲は全体か部分か
- 特定 API/エンドポイントか
- 特定ユーザー/IP のみか
- 発生時刻の推定
ステップ 3：依存マップを把握（30秒）
典型的な Azure 構成例：
User → Front Door / Application Gateway → API (App Service / AKS / Functions) → DB (Azure SQL / Cosmos DB) → Cognitive Services / Storage / External API
まずはボトムアップで疑う（外部依存→ストレージ→アプリ→ネットワーク→ユーザー）
次の打ち手：原因仮説と切り分け
原因カテゴリ（まずはカテゴリ分け）
- リソース枯渇（CPU/メモリ/コネクション/スロットリング）
- 設定/ポリシー/権限変更（Activity Log に注目）
- 依存サービス障害（Cognitive Services/外部 API / Azure 側のサービス障害）
- スケーリング/オートスケール失敗
- ネットワーク障害（NSG, Route, VNet Peering, DNS）
即効で使える確認コマンド（Azure CLI 例）
リソース枯渇系
# VM/VMSS の CPU 平均を過去30分で取得
az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm> --metric "Percentage CPU" --interval PT1M --start-time (Get-Date).ToUniversalTime().AddMinutes(-30).ToString("s")
# Function の失敗数
az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Web/sites/<functionName> --metric "FunctionExecutionUnits" --interval PT1M
# Cosmos DB の RU/s 使用率
az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DocumentDB/databaseAccounts/<account> --metric "TotalRequestUnits" --interval PT1M
設定/ポリシー変更系
# Activity Log で特定イベントを検索（例: RoleAssignment / Policy）
az monitor activity-log list --offset 60m --query "[?operationName.value=='Microsoft.Authorization/roleAssignments/write']"
依存サービス障害系
- Azure Service Health を確認（portal または CLI）
- 外部 API は last-call logs を確認
スケーリング系
# VMSS のインスタンス数・スケールアクティビティ
az vmss list-instances --resource-group <rg> --name <vmssName>
az monitor activity-log list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmssName> --offset 60m
ネットワーク系
- Network Watcher の接続監査
- NSG フローの確認
フェーズ別対応
Phase A：Mitigation（初動：最初の10分）
目標：影響を短時間で最小化（止血）。恒久対応は後回し。
典型的な Mitigation パターン
- スケールアウト（AKS / App Service / Function のインスタンス数を増やす）
- ロールバック（直近のデプロイが原因の確信がある場合）
- レート制御（Front Door / API Management / Application Gateway でトラフィック制限）
- 一時的な機能フラグで負荷の高い機能をオフにする
Azure CLI 例
# App Service のスケール（インスタンス数）
az webapp scale --resource-group <rg> --name <appName> --number-of-workers 4
# AKS のノードプールを一時増強（VMSS ベース）
az aks nodepool scale --resource-group <rg> --cluster-name <aks> --name <pool> --node-count 5
# Traffic Manager や Front Door でのトラフィック制御は、設定変更 + 即時検証を行う
Mitigation 時のチェックリスト
- 変更内容をチャットに即時共有
- ロールバック方法を明確にする
- 3〜5分でメトリクス改善を確認
- 副作用をモニタする
Phase B：Remediation（恒久対応：10分〜数時間）
原因の根本解決を行う。ログやトレースを深掘りして、パッチや設定変更を適用。
- Application Insights のトレースでボトルネック箇所の特定
- ARM テンプレート / Bicep の不適切な設定を修正
- 永続的なスケール設定（Autoscale ルール）の見直し
Phase C：Post-Incident（事後分析）
- インシデント報告（Timeline, Impact, Root Cause, Mitigation, Remediation）
- 再発防止策（アラート追加、Runbook 更新、テストケース追加、Azure Policy の強化）
- ポストモーテム会議と学びの共有
サービス別チェックリスト（Azure 向け）
Application/Compute（App Service / AKS / Functions）
- Application Insights: Failure Rate, Server Response Time, Dependency Call Failures
- AKS: Pod 健康、ノードリソース、イベント（kubectl describe / logs）
- Functions: 同時実行数、タイムアウト、Bindings の失敗
即効確認コマンド例
# App Insights クエリ（短時間で失敗カウント）
az monitor app-insights query --app <app_insights_app> --analytics-query "requests | where timestamp > ago(15m) | summarize count() by resultCode"
データベース（Azure SQL / Cosmos DB）
- Azure SQL: DTU/vCore 使用率、接続数、deadlocks
- Cosmos DB: RU 使用率、429 (Throttled) の発生
チェック例
# Cosmos DB の 429 発生の監視
az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DocumentDB/databaseAccounts/<account> --metric "TotalRequests" --interval PT1M
ストレージ（Blob, Files）
- ストレージ アカウントのスロットリング／認可エラー
- SAS トークンの期限切れやアクセス ポリシーの誤設定
セキュリティ/権限（Azure AD / Key Vault）
- Activity Log でのロール割当/権限変更をチェック
- Key Vault のアクセス失敗（GetSecret の AccessDenied）を確認
# 最近の role assignments 操作を確認
az role assignment list --scope /subscriptions/<sub>/resourceGroups/<rg> --query "[?contains(roleDefinitionName, 'Contributor') || contains(roleDefinitionName,'Owner')]"
# Key Vault のアクセス エラーは診断ログで確認
オブザーバビリティ（Azure Monitor / Application Insights / Log Analytics）
- アラート閾値が適切か（ノイズの少なさ）
- Log Analytics のクエリでエラーの根本原因を抽出
ネットワーク（VNet / NSG / Front Door / Application Gateway）
- NSG ルールや UDR の変更を確認
- Front Door / Application Gateway のヘルスプローブ結果を確認
- DNS（Azure DNS / external）での障害をチェック
よくある失敗パターン＆対策
- ログやトレースを十分に見ずに権限を与える
- 対策：まずログを確認し、最小権限で修復。変更は最小限にする。
- 複数変更を同時実行して原因を特定できなくなる
- 対策：1つずつ変更、効果測定、ロールバックの準備
- 本番で大きなパラメータ変更を実施する
- 対策：ステージングで検証、段階的ロールアウト
- アラートが鳴りっぱなしで対応が遅れる
- 対策：アラートの閾値・フィルタを改善し、適切なオンコール連携を確保
実例シナリオ（5選）
シナリオ 1：API レイテンシが急上昇（Cognitive Services/Functions 関連）
- 症状: 95p レイテンシが急増、エラーは少ない
- まず見る: Application Insights の依存関係（Cognitive Services） -> API 呼び出しの遅延
- 仮説: Cognitive Services 側のスロットリング／遅延
- Mitigation: リトライ + バックオフ、入力サイズ縮小、トラフィック削減（API Management でレート制限）
シナリオ 2：認可エラー（AccessDenied）が急増
- 症状: 403 が全ユーザーで増加
- まず見る: Activity Log で直近の RoleAllocation / Policy の変更
- 仮説: 直近に AD / Role Assignment の変更があった
- Mitigation: すぐにロールを復元または一時的に最小限の許可を付与
シナリオ 3：Cosmos DB の 429 スロットリング
- 症状: リクエストが 429 を返す
- まず見る: RU/s 使用率、パーティションホットスポット
- 仮説: RU不足またはアクセス集中
- Mitigation: パーティションキーの見直し、TTL/キャッシュ導入、一時的な RU 増加
シナリオ 4：Storage (Blob) へのアクセス失敗（VNet 経由）
- 症状: VNet 内の Function から Blob がアクセスできない
- まず見る: VNet Service Endpoint / Private Endpoint の状態、Key Vault ポリシー
- 仮説: Private Endpoint の DNS 設定ミス、または Key Vault のアクセスポリシー
- Mitigation: DNS 設定の一時切替、アクセス ポリシーの検証と修正
シナリオ 5：AKS 内のサービスが 5xx を返す（ノード/Pod 問題）
- 症状: 特定の Pod でエラー、ノード Pressure
- まず見る: kubectl describe pod / events、ノードメトリクス
- 仮説: リソース不足（OOM / CPU 限界）かイメージの不整合
- Mitigation: Pod の再起動、ノードプールのスケールアウト、一時的レプリカ増加
まとめ：開始直後にやるべきチェックリスト
- チャットにインシデントチャンネルを作成
- Azure Monitor / Application Insights を全画面表示
- Activity Log を確認して直近の設定変更を探す
- 影響範囲（全体/部分）を決める
- 仮説を立て、最初の Mitigation を 1 つだけ実行
- 3 分で効果を確認、効果なければ戻す
参考資料
- Azure Monitor ドキュメント
- Application Insights ドキュメント
- Azure Service Health / Resource Health
- Azure CLI ドキュメント
最後に
Azureで実際にインシデント発生時にどういう風に切り分けしていくかの型を身に着けるのはとても大切なのかな…
と思ってたのですが、「あれっ…これってあまり変わらないのでは…？（驚愕）」ということに、書き終わってから気づいてしまいました…。まあいいか。
AzureもAWSも、結構個別サービスでハマること多いので、改めて自分のメモ書きレベルですがこういうのを意識してみるのも大切なのかな、という気はしました。
次は、AWS/Azureで、個人的にメモしときたいな📝と思うサービスについて、
徒然なるままに書いていけたらいいなーと思ってます🚀