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
- Scope Fix: affected resource, time window, resource ID, and current user impact.
- Live Fact Collection: auth/subscription, current resource state, Activity Log, Resource Health, and dependent resources.
- Platform vs Workload Split: decide active Azure platform impact, recovered Azure event, or customer-side continuing issue.
- Service Branch: use references/service-branches.md for AKS, App Service, Database, Entra ID, Load Balancer, VPN/BGP.
- Official Grounding: verify Resource Health, diagnostic limits, and service-specific claims with Microsoft Learn URLs.
- Report Synthesis: primary conclusion, facts, current state, interpretation, next checks, and SR identifiers if needed.
- Save: troubleshooting records go to
Troubleshooting/; ordinary Q&A answers go toAnswer/.
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 --idsdirectly. - Recovered Resource Health: do not call it ongoing once
Resolvedand currentAvailableare confirmed. - Run Command RBAC: do not imply guest execution is possible without
Microsoft.Compute/virtualMachines/runCommand/actionor 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 か切り分けて