AZ VNet SpaceAzure Networking Wiki
Home / Operations & Troubleshooting
Operations & Troubleshooting参照資料確認: 2026-09-11

Network Incident: First 15 Minutes

Azure network incident最初の15分でscope・時刻・5-tuple・DNS・effective state・recent changeを固定し、無秩序な設定変更を防ぐ初動runbook。

この記事の目次
要点証拠診断順序仕組み設計確認証明範囲切り分け変更安全CurrentSources

Network Incident: First 15 Minutesを理解するための前提

最初の15分の目的はroot causeを完全に解くことではなく、impact、time window、test vector、recent change、first failing boundaryを固定すること。 症状を「ネットが遅い」で残さず、誰が・どこから・何へ・何protocol/portで・いつから・どのexpected resultに対して失敗したかへ変換する。

known-goodとknown-badを最低1組確保する。全体障害か特定region/subnet/client/backendだけかを比較で縮める。 change freezeの範囲とexceptionを明示し、診断中に複数NSG/UDR/DNS/WAFを同時変更して証拠を壊さない。

Network Watcher/Connection Monitor/flow logsは「過去から収集されていたもの」を優先し、incident後に有効化したtelemetryで過去を推測しない。 service restorationとroot-cause analysisは分離する。emergency mitigationを行ってもbefore evidenceとrollback条件を残す。

通信や判断の流れを追う
症状を再現設定を確認能動試験ログ / packetアプリ確認

診断結果をどう読み分けるか

0-3 min

impact + time + change。誰が困っているか、最初のbad timestamp。

3-7 min

known-good/bad + DNS + tuple。比較対象を作る。

7-11 min

effective security/route + health。control planeでfailure domainを狭める。

11-15 min

Connection Troubleshoot/flow/packetへ。first evidence-based actionを決める。

判定原則あるtoolがPASSしたら、そのtoolの責任範囲だけを通過条件にします。「Allow」「Reachable」「Healthy」をnetwork/application全体の正常証明へ拡大しません。

障害が起きたときの調べ方

  1. 0-1分: incident ID、UTC/JST開始時刻、reporter、business impact、affected serviceを記録する。
  2. 1-3分: recent deployment/network/DNS/certificate/policy changeの有無を確認し、change ownerへ連絡する。
  3. 3-5分: failing clientとknown-good client、destination FQDN/IP、protocol/port、HTTP/TLS等の期待結果を固定する。
  4. 5-7分: failing sourceでDNS answer/TTLを記録し、resolved IPでnetwork test可能な状態にする。
  5. 7-9分: source/destinationのeffective security、IP Flow Verify、effective route/Next Hop、LB/AppGW/backend health等を確認する。
  6. 9-12分: Connection Monitor/flow logs/resource logsで最初のbad timestampとscopeを照合する。
  7. 12-15分: Connection Troubleshootまたは最小Packet Captureを実行し、次に調べるboundaryを1つ決める。
  8. 15分時点: confirmed facts、unknowns、mitigation候補、rollback条件、次ownerを短いcheckpointとして共有する。

仕組みと読み方

incident初動で最も高価なのは、技術的に難しいことより「条件が変わり続けること」です。ある人はFQDN、別の人はIP、別の人は別subnetから試すと、結果の差がnetwork faultなのかtest差なのか分からなくなります。first 15 minutesではtest vectorを固定し、比較可能なevidenceを作ることを優先します。

また「最後に変えたものが原因」と決め打ちもしません。recent changeは高優先の仮説ですが、change前から始まった障害、provider/platform issue、capacity、certificate expiryなどもあり得ます。timestamp correlationとbefore/after evidenceで確定します。

運用設計

判断軸運用設計
Incident templatesource/destination/tuple/time/change/impactを必須field化。
Telemetry readinessVNet Flow Logs/diagnostic settings/Connection Monitorを平時に準備。
Accessread-only diagnostic権限とbreak-glass change権限を分離。
Evidence storeJSON/CSV/pcap/query text/screenshotの保存場所をincident IDで統一。
Handoff15分checkpointでfact/unknown/action/ownerを分ける。

確認手順 / read-only first

実行前に固定する情報

  • subscription / resource group / resource ID / region
  • source IP/NIC/subnet と destination FQDN/IP
  • protocol / source port / destination port
  • UTC time window + JST表示
  • expected result と known-good comparison

Evidence to keep

  • command/query textとraw JSON/CSV
  • Portal screenshotだけでなくresource IDを含む機械可読結果
  • 変更前/変更後の同一test vector
  • negative test と adjacent critical path
  • rollback実施時の復帰確認
Azure CLI — read-only first
az account show -o jsonc
az network watcher list -o table
# 続いて対象flowに対する test-ip-flow / show-next-hop / test-connectivity を実行
PowerShell — read-only first
Get-Date -AsUTC
Get-AzContext
Get-AzNetworkWatcher

この結果で何を証明できるか

観測結果証明できることそれだけでは証明できないこと
Known-good works少なくともそのcomparison pathは生存。shared component全体が正常とは限らない。
Failure began at Tmonitor/log/reportがT付近で悪化。Tのchangeが原因という因果。
Effective route changedcontrol plane route stateがprevious baselineと差分。実packetがそのrouteで失敗したこと。
Mitigation restores servicemitigation後のjourney回復。root causeが完全確定。
No flow logs before incident過去traffic evidence欠損。後からenableして過去を復元はできない。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
全員が別testをするtest vector不統一incident leadがcanonical flowを1つ固定。
NSGをすぐ全開evidenceなしchangeIP Flow Verify/route/healthを先に取得。
時刻が合わないUTC/JST混在UTC基準に正規化しJSTを併記。
復旧したので調査終了mitigationとroot cause混同before/after diffとroot-cause follow-upを残す。
ログがないreadiness gapincident後にgapをpostmortem actionへ。

変更時の確認と rollback

  • emergency mitigationには開始時刻、owner、expiry、rollback triggerを必須にする。
  • DNS/route/security changeはcache/convergence/sessionを考慮し、new connectionで効果判定する。
  • rollback後もincident test vectorがbaselineへ戻ったことを確認する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

2026年current guidanceでNetwork Watcher、VNet Flow Logs、Traffic Analytics、Connection Monitorは互いに異なる観測目的を持ちます。本runbookは最初の15分で「どのtoolを使ったか」より「同じ条件の比較可能なevidenceを残したか」を完了条件にしています。

Packet Walk Method
同じtest vectorを別の観測面から確認する。Connection Monitor
同じtest vectorを別の観測面から確認する。Network Watcher
同じtest vectorを別の観測面から確認する。Network Change Validation
同じtest vectorを別の観測面から確認する。

Official sources

動作、support boundary、preview/GA、retirement、schemaはMicrosoft Learnのcurrent documentationを基準にしています。productionで使う際は対象subscription/region/resource provider/API/CLI versionの最新documentationを再確認してください。