Azure Service Health

解決する課題

「自分のアプリが落ちたのか、それとも Azure 側の障害なのか」を切り分け、Azure プラットフォーム由来の問題を自分の利用範囲に絞って把握するための仕組みです。

• 今起きている障害が自分の使うリージョン/サービスに影響するかを知りたい
• 計画メンテナンスの予定を事前に把握し、ダウンタイムに備えたい
• 個々の VM やストレージなど、自分のリソース単体の不調を確認したい
• 障害情報をメールや Webhook、ITSMに自動連携し、検知を早めたい

主要概念と用語

• Service issues（サービスの問題）: 現在進行中の Azure 側の障害。影響を受けるリージョン/サービスや、軽減策・復旧見込みが表示される
• Planned maintenance（計画メンテナンス）: 事前に告知される保守作業。再起動の有無や対応の要否を確認できる
• Health advisories（正常性勧告）: 機能の非推奨化や設定変更の依頼など、対応が必要なお知らせ
• Security advisories（セキュリティ勧告）: セキュリティに関わる通知（提供範囲はサブスクリプションにより異なる）
• Resource Health（リソース正常性）: VM や SQL DB など個別リソースの正常性を、Available / Degraded / Unavailable で表示。原因がプラットフォーム側かユーザー操作かも示す
• Service Health アラート: 上記イベントを条件にして発火するアラート。アクショングループで通知や自動対応につなぐ
• Azure Status: 全世界の Azure サービス状況を示す公開ページ（サインイン不要、利用範囲に非依存）

仕様・制限・クォータ

• Service Health 自体は無料で、追加コストなく利用できる
• 対象はAzure プラットフォーム側の正常性。アプリのバグやリソースの構成ミスは対象外（それは Azure Monitor / Application Insights の領域）
• 表示・通知はサブスクリプション単位で、ユーザーが利用するサービスとリージョンに絞り込まれる
• アラートは**アクティビティ ログのカテゴリ「Service Health」**を基盤とし、アクショングループへ接続する
• 過去のイベント履歴は一定期間ダッシュボードで参照可能（保持期間は変動するため定性的に把握する）
• グローバルなサービス全体状況だけが必要なら、サインイン不要の Azure Status を見れば足りる

内部の仕組み

Azure の運用側がプラットフォーム障害や計画メンテナンスを検知/告知すると、その情報が各サブスクリプションのアクティビティ ログに「Service Health」カテゴリのイベントとして書き込まれます。Service Health ダッシュボードは、このイベントを自分が利用するサービスとリージョンで絞り込んで表示します。

Service Health アラートは、このアクティビティ ログ イベントを条件として評価し、合致したときにアクショングループを起動します。アクショングループはメール・SMS・プッシュ通知・Webhook・Logic Apps・Automation Runbook などを束ねており、ここから ITSM ツールやチャットへ連携できます。

一方 Resource Health は、個別リソースに対するプラットフォーム側のシグナル（ハードウェア障害、メンテによる再起動、ユーザー起因の停止など）を集約し、リソース単位の正常性として提示します。

設計パターン / ベストプラクティス

• Service Health アラートを必ず設定し、Service issues と Planned maintenance を最低限カバーする
• 通知はアクショングループ経由でメール/Teams/PagerDuty などへ送り、運用フローに組み込む
• 重要システムは Resource Health アラートも併用し、リソース単体の Unavailable を即検知する
• 計画メンテナンスの通知を受けたら、可用性ゾーン分散やフェイルオーバー手順の確認に活かす
• ITSM（ServiceNow 等）連携で、障害イベントを自動でインシデント起票する

運用・監視

• 通知が来ない → Service Health アラート ルールとアクショングループの宛先、対象サブスクリプションの選択を確認
• 自分のリソースだけ不調 → まず Resource Health を見て、原因がプラットフォーム側かユーザー操作かを切り分ける
• 全体障害かを素早く確認したい → サインイン不要の Azure Status ページを参照
• 障害の事後分析 → Service Health の履歴と、Microsoft が公開する PIR（事後レビュー） を突き合わせる
• 監視の主役は Azure Monitor、Service Health はプラットフォーム障害の検知レーンとして併設する

コスト

Service Health と Resource Health の閲覧・アラート機能自体は無料です。課金はアラートから起動する下流のアクション側で発生し得ます。

セキュリティ

• ダッシュボード/アラートへのアクセスは Microsoft Entra ID + Azure RBAC で制御し、最小権限で付与する
• アラートのアクショングループに使う Webhook は送信先を限定し、機密情報を本文に載せない
• 自動対応に Logic Apps / Automation を使う場合はマネージド ID を用い、資格情報のハードコードを避ける
• セキュリティ勧告は提供範囲がサブスクリプションにより異なるため、鵜呑みにせず正規の通知経路で確認する

関連サービス・比較

最も近い関連は、Azure プラットフォーム障害を扱う Service Health に対し、個別リソースの正常性を扱う Resource Health です。

ハンズオン / CLI例

# 現在進行中のサービスの問題（Service issues）を一覧表示
az rest --method get \
  --url "https://management.azure.com/subscriptions/<sub-id>/providers/Microsoft.ResourceHealth/events?api-version=2022-10-01&\$filter=eventType eq 'ServiceIssue'"

# 特定 VM のリソース正常性（Resource Health）を確認
az rest --method get \
  --url "https://management.azure.com/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.Compute/virtualMachines/demo-vm/providers/Microsoft.ResourceHealth/availabilityStatuses/current?api-version=2022-10-01"

# 通知先となるアクショングループを作成（メール宛先）
az monitor action-group create \
  --resource-group demo-rg \
  --name svchealth-ag \
  --short-name svchealth \
  --action email ops ops@example.com

# Service Health（アクティビティ ログ）アラートを作成し、アクショングループへ通知
az monitor activity-log alert create \
  --resource-group demo-rg \
  --name service-health-alert \
  --scope "/subscriptions/<sub-id>" \
  --condition category=ServiceHealth \
  --action-group svchealth-ag