Service Health / Resource Health for Network Incidentsを理解するための前提
Azure Service HealthはAzure Status、Service health、Resource Healthの3つのserviceから構成される。 Azure Statusは全Azure service/regionのglobal view、Service Healthは利用中service/regionにpersonalizedされたissue/maintenance/advisoryを提供する。
Resource Healthは個別resourceのcurrent/past healthを示し、Available/Unavailable/Degraded/Unknown等の状態で診断材料になる。 ServiceHealthResourcesをAzure Resource Graphでqueryすると、複数subscriptionのactive Service Health eventを横断取得できる。
Service Health eventがないことはtenant configurationの正常性を証明しない。route/NSG/DNS/service healthをそれぞれ別に確認する。
Control plane と Data plane
仕組みと設計上の意味
「Azure側の障害ですか？」に答えるには、publicなAzure Statusだけを見るのでは不十分です。Service Healthは自分のsubscription/region/serviceへの影響をpersonalizedして表示し、planned maintenanceやhealth advisoryも扱います。Resource Healthはさらに個々のresourceへ降ります。
ネットワークincidentでは、platform eventが見つかった場合も、affected region/service/timeが自分のflowと一致するかを確認します。逆にService Healthがgreenでも、NSG/UDR/DNS/Firewall policyやbackend healthなどtenant側のfailureは残ります。
Operational / decision path
対象scopeと時刻を固定し、read-only evidence → 判断 → change → same testで再検証の順を崩さない。
- incidentのaffected service・region・subscription・resource IDsを固定する。
- Azure Statusで広域eventを確認する。
- Service Healthでsubscription-specific eventとtracking ID、impact windowを確認する。
- Resource Healthで対象resourceのhealth historyを確認する。
- platform evidenceとtenant-side effective route/security/DNS/application evidenceを同一timelineへ並べる。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Alerting | Service Health alertを事前構成 | Portalを見に行く前にimpactを受け取る |
| Evidence | tracking ID / event type / impact timeを保存 | support caseとincident timelineを接続 |
| Scope | service+region+subscriptionで照合 | 無関係なglobal outageへ誤帰属しない |
| Tenant checks | platform event有無に関係なくlocal pathも検証 | 複合障害/設定障害を見落とさない |
確認手順
Azure Portal
- Service Health → Service issues / Planned maintenance / Health advisoriesを確認。
- Resource Healthでaffected resourceのcurrent/past statusを確認。
- event detailsのtracking ID、affected services/regions、impact start/mitigationをincident recordへ保存。
Evidence contract
Read-only first: 以下のCLI/PowerShellは原則として参照系から開始します。コメントでMUTATINGと示した操作は、必要性・scope・rollbackを確認した後にのみ実行します。
# Resource Graph extension/query: all active service issues
az graph query -q "ServiceHealthResources | where type =~ 'Microsoft.ResourceHealth/events' | extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = properties.ImpactStartTime, impactMitigationTime = properties.ImpactMitigationTime | where eventType == 'ServiceIssue' and status == 'Active'" -o tableSearch-AzGraph -Query "ServiceHealthResources | where type =~ 'Microsoft.ResourceHealth/events' | extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = properties.ImpactStartTime, impactMitigationTime = properties.ImpactMitigationTime | where eventType == 'ServiceIssue' and status == 'Active'"障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Azure Statusはgreen、通信不可 | tenant-specific issueまたはconfig | Service Health + effective path | Service Health/Resource Healthへ降りる |
| Service Health eventあり | affected scope一致未確認 | tracking ID + region/service | 自分のresource/timeと照合 |
| Resource Health Unknown | monitoring signal不足/transition | health history + service logs | data-plane testと並行確認 |
| 復旧通知後も失敗 | tenant側state/connection cache/backend recovery | same test vector + effective state | platform復旧とapplication recoveryを分離 |
変更・rollback
- platform incident中のemergency workaroundは、復旧後に恒久configとして残さない。temporary route/DNS/failover changeへexpiry/rollback条件を付ける。
- region failoverはtarget regionのquota、DNS TTL、route propagation、certificate/backend dependenciesを事前に確認する。
- Service Health eventを理由にchangeする場合もbefore snapshotを取り、tracking IDとchange ticketを相互参照する。
- rollback後はAzure Status/Service Healthではなく、同じuser journey/packet pathでend-to-end recoveryを確認する。