azure-troubleshooting

name	azure-troubleshooting
description	Investigate Azure incidents and service degradations with a read-only workflow using Azure CLI, Resource Health, Activity Log, metrics, resource logs, and official Microsoft docs. Use when troubleshooting Azure outages, Resource Health alerts, Azure Firewall or DNS failures, ExpressRoute or BGP instability, VM availability problems, AKS incidents, App Service failures, database connectivity issues, Entra ID sign-in problems, load balancer issues, platform-vs-workload cutover, or drafting a troubleshooting report. Triggers on 'Azure トラブルシューティング', '障害調査', '切り分け', 'Resource Health', '復旧確認', 'Azure Firewall', 'DNS', 'ExpressRoute', 'VPN Gateway', 'BGP', 'AKS', 'App Service', 'SQL', 'PostgreSQL', 'Cosmos DB', 'Entra ID', 'incident', 'degraded', 'unavailable'.
argument-hint	subscription ID, resource ID(s), symptom, occurrence time, and current user impact
user-invocable	true
license	CC BY-NC-SA 4.0
metadata	{"author":"yamapan (https://github.com/aktsmm)"}

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