Azure Troubleshooting

Azure Troubleshooting

Azure の障害調査、切り分け、初動確認、復旧確認を read-only で進め、事実ベースのレポートへ落とすための workspace skill。

When to Use

• Azure リソースの障害、性能劣化、到達性異常を調査したいとき
• Azure Resource Health の Active / Updated / Resolved イベントを解釈したいとき
• Load Balancer、VM、NIC、NSG、Activity Log を軸に原因を切り分けたいとき
• AKS、App Service、Azure SQL、PostgreSQL、Cosmos DB、Entra ID の障害切り分けをしたいとき
• Azure プラットフォーム障害か、顧客側の構成 / OS / アプリ障害かを切り分けたいとき
• 調査結果を Troubleshooting/ 向けレポートとして保存したいとき

When NOT to Use

• 通常の製品 Q&A や比較検討だけを行うとき
• 変更作業や復旧操作を実行するとき
• 設計提案やベストプラクティス整理が主目的のとき

Inputs

最低限、以下のうち 1 つ以上を受け取る。

• サブスクリプション ID
• リソース ID またはリソース名 + Resource Group
• 発生時刻
• 影響症状
• 監視アラート本文

不足している場合は、調査に必要なキー情報だけ追加確認する。

Core Rules

• まず live 状態を read-only で確認し、推測より観測結果を優先する
• Azure CLI / Activity Log / Resource Health の事実と、そこからの解釈を分けて書く
• Activity Log は control-plane の履歴確認に有効だが、network runtime event の証明には過信しない
• 現在も障害中か、過去に発生して既に復旧したのかを最初に切り分ける
• Microsoft / Azure の意味づけは公式 Docs で裏付ける
• 障害調査レポートは Troubleshooting/ を正本にし、Answer/ と重複保存しない
• Load Balancer 系では Resource Health が復旧済みでも VipAvailability と DipAvailability を確認する
• DipAvailability の BackendPort と BackendIPAddress は別次元集計として扱い、直接の 1 台 1 ポート値として書かない
• VPN Gateway や BGP flap 疑いでは、Activity Log だけで 瞬断なし と断定せず、RouteDiagnosticLog / TunnelDiagnosticLog / BGP 系メトリクスの有無も確認する
• 報告書では「報告書としては」のようなメタ表現を避け、判断文そのものへ落とす
• 破壊的操作、構成変更、再起動、フェールオーバーはこの skill の範囲外

Workflow

1. Scope Fix: affected resource, time window, resource ID, and current user impact. 2. Live Fact Collection: auth/subscription, current resource state, Activity Log, Resource Health, and dependent resources. 3. Platform vs Workload Split: decide active Azure platform impact, recovered Azure event, or customer-side continuing issue. 4. Service Branch: use references/service-branches.md for AKS, App Service, Database, Entra ID, Load Balancer, VPN/BGP. 5. Official Grounding: verify Resource Health, diagnostic limits, and service-specific claims with Microsoft Learn URLs. 6. Report Synthesis: primary conclusion, facts, current state, interpretation, next checks, and SR identifiers if needed. 7. Save: troubleshooting records go to Troubleshooting/; ordinary Q&A answers go to Answer/.

Decision Points

• Auth blocked: report MFA/Conditional Access status and prefer normal browser login when device code is blocked.
• Resource Graph gaps: child resources may be missing; construct child IDs and query az resource show --ids directly.
• Recovered Resource Health: do not call it ongoing once Resolved and current Available are confirmed.
• Run Command RBAC: do not imply guest execution is possible without Microsoft.Compute/virtualMachines/runCommand/action or equivalent role evidence.
• Incomplete scope: resolve resource ID / subscription / resource group first; do not broaden blindly.
• No official doc: state that the official docs do not explicitly say it, and separate observation from hypothesis.

Done Criteria

• [ ] 対象リソースと発生時刻が明確
• [ ] current state を live で確認済み
• [ ] Activity Log または同等の履歴を確認済み
• [ ] network runtime が論点なら、Activity Log だけで足りるか / resource logs や metrics が必要かを判定済み
• [ ] Azure 側継続影響か、復旧済みか、顧客側継続影響かを切り分け済み
• [ ] 公式 Docs の URL を最低 1 件以上付与
• [ ] 事実と解釈を分けて記述
• [ ] レポートを Troubleshooting/ へ保存、または保存先判定理由を明示

Output Shape

レポートは 回答、いただいた質問、事実確認結果、解釈、次に確認すべきこと を基本にする。詳細テンプレートは references/report-template.md を使う。

Example Prompts

• /azure-troubleshooting subscription ID と resource ID を渡すので、Azure 側継続障害か切り分けて
• /azure-troubleshooting Resource Health の PlatformInitiated アラートが来た。current state と Activity Log を見て報告書を作って
• /azure-troubleshooting Load Balancer と配下 VM の障害調査をして、Troubleshooting に保存して
• /azure-troubleshooting AKS の API server は生きていそうだが Pod が不安定。Azure 側かワークロード側か切り分けて
• /azure-troubleshooting App Service が 5xx を返している。platform 障害か app 側か切り分けて
• /azure-troubleshooting Azure SQL / PostgreSQL の接続障害を調べて、platform とネットワークを切り分けて
• /azure-troubleshooting Entra ID のサインイン障害を tenant-wide か app-specific か切り分けて

References

• references/service-branches.md
• references/report-template.md

Azure Troubleshooting Report Template

# {タイトル}

## 回答

{一次結論}

## いただいた質問

{原文}

## 事実確認結果

{観測結果}

## 解釈

{公式 Docs 付きの意味づけ}

## 次に確認すべきこと

{次アクション}

Azure Troubleshooting Service Branches

Azure インシデント調査で、共通の live fact collection の後に分岐するサービス別チェックリスト。

Load Balancer / VM

First Checks

• Microsoft.ResourceHealth/availabilityStatuses/current で current health を確認する
• Activity Log で Active / Updated / Resolved の履歴を確認する
• az vm get-instance-view で関連 VM の power / provisioning を確認する
• VipAvailability を確認する
• DipAvailability を BackendPort と BackendIPAddress で別々に確認する
• 直近 24 時間の Azure Administrative Activity で LB / VM / NIC / NSG への構成変更有無を確認する

Split

• Resource Health が復旧済みでも VIP が低下: LB 全体の dataplane 影響を優先
• VIP は 100% だが DIP が低下: backend 個別異常を優先
• DipAvailability は別次元集計なので、BackendPort と BackendIPAddress を組み合わせて推定する
• HealthProbeStatus が列挙されない環境では DipAvailability を主指標にする
• BackendPort 側と特定 Backend IP 側の両方に低下が残り、他の Backend IP が 100% に戻っている場合は、その VM の待受サービス、OS Firewall、アプリ応答を優先する

Report Notes

• 10.186.80.198:59502 のような直接値として書かず、「別次元の集計値」と明記する
• 会話メタではなく、「本事象は〜と評価する」のような判断文へ落とす

AKS

First Checks

• az aks show で cluster の provisioningState、powerState、kubernetesVersion を確認する
• az aks nodepool list で node pool の状態を確認する
• Activity Log で upgrade、rotate、scale、maintenance の履歴を確認する
• Resource Health や Service Health に AKS / Compute / Network の継続影響がないか確認する

Split

• control plane が正常で workload だけ異常: ingress、CNI、node、pod 側を優先
• node pool が不健康: VMSS、node image、quota、network を優先
• API server 到達不可: Azure 側継続影響または認証 / private cluster 経路を優先

App Service

First Checks

• az webapp show で state、hostNames、serverFarmId を確認する
• deployment slot、recent deployment、app settings の変更履歴を確認する
• Health Check、HTTP 5xx、restart、scale、certificate 更新の有無を確認する
• Activity Log で restart、config change、plan scale の履歴を確認する

Split

• App Service plan と platform が正常でアプリだけ異常: code、config、dependency、identity を優先
• slot swap 直後から異常: slot 設定差分を優先
• 全 instance で 5xx が増加: upstream dependency または platform event を確認

Database

Azure SQL / SQL MI

• az sql server show、az sql db show または SQL MI の状態を確認する
• failover、maintenance、firewall、private endpoint、connection policy を確認する
• CPU、storage、workers、sessions などの飽和を確認する

PostgreSQL / MySQL Flexible Server

• server state、HA 状態、storage 使用率、メンテナンス履歴を確認する
• firewall、private DNS、SSL/TLS、connection count を確認する

Cosmos DB

• regional failover、write region、replication、throughput、429/throttling を確認する
• hot partition や特定 container 偏りを確認する

Split

• platform state が正常で接続障害のみ継続: firewall、private endpoint、DNS、credential rotation を優先
• 稼働中だが遅い: RU、connection saturation、query regression、hot spot を優先

Entra ID

First Checks

• 影響範囲が tenant 全体か、特定 app / user / CA policy かを切り分ける
• sign-in logs、audit logs、Conditional Access 変更、federation / provisioning 変更を確認する
• Entra / M365 側の Service Health を確認する
• app registration、service principal、secret / certificate expiry を確認する

Split

• tenant-wide sign-in failure: Service Health、federation、MFA、identity provider 側を優先
• 特定アプリのみ失敗: app registration、redirect URI、secret / cert、有効な audience を優先
• 特定ユーザー / グループのみ失敗: Conditional Access、group membership、device compliance を優先

VPN Gateway / BGP

First Checks

• Connection resource の status が Connected かを確認する
• gateway の BGP peer status と learned routes を確認する
• Activity Log で control-plane の更新履歴を確認する
• diagnostic settings の有無を確認し、RouteDiagnosticLog / TunnelDiagnosticLog / IKEDiagnosticLog を後追い確認できる状態かを判定する
• BgpPeerStatus、BgpRoutesLearned、BgpRoutesAdvertised、必要なら tunnel packet drop 系メトリクスを確認する

Split

• Activity Log に write/update があるだけ: control-plane 変更は言えるが、runtime flap の有無はまだ言えない
• RouteDiagnosticLog に BgpDisconnectedEvent / BgpConnectedEvent がある: BGP flap の有無と時刻をこちらで判断する
• TunnelDiagnosticLog に同時刻の disconnect/connect がある: tunnel 側不安定が BGP flap の主因候補
• diagnostic settings 未構成: 瞬断なし ではなく 後追いで証明できる証跡がない と書く
• BgpPeerStatus が正常でも time grain が粗い場合: 短い flap 見逃しの可能性を残す

Report Notes

• Activity Log では構成変更時刻を確認、runtime event は別証跡で確認 と役割を分けて書く
• flap はなかった と断定する条件と、見えなかっただけ の条件を分けて書く
• diagnostic settings 未構成なら、その制約を明示して結論の強さを下げる

Shared Reporting Pattern

各分岐でも、レポートは以下の順で短くまとめる。

1. 一次結論 2. live で確認した current state 3. 影響が Azure 側継続か、復旧済みか、ワークロード側継続か 4. 次の確認対象