/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 shared network/DNS, Azure Firewall, ExpressRoute, 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 を使う。

Support Response Translation

サポートや他ベンダーからの技術回答をそのまま顧客へ渡すと、被疑箇所が並列に並んだだけの文書になり、顧客はどこから着手するか判断できない。次の形へ読み替えてから渡す。

• 項目ごとに「どのホストで、誰が実施するか」を先に確定する。回答本文に書かれていないことが多く、ここが欠けると認識違いのまま作業が始まる。
• 回答内で「可能性は低い」と評価済みの項目は明示的に降格する。並列表記のままだと全件調査に見え、顧客の作業量が実態より膨らむ。
• 「いま実施できること」と「再現時に採取するもの」を分ける。断続事象では、再現時採取の準備を先に終わらせないと証跡そのものが取れない。
• 元回答のセクションと作業項目の対応表を付け、顧客が原文と並べて読めるようにする。
• 多段の依存関係（CNAME チェーン、経路、依存サービス）は文章ではなく図で示し、どの段で落ちているかを 1 目で分かるようにする。
• 元回答に無い推測を混ぜない。こちらの解釈は解釈として区別して書く。

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