「障害情報はどこを見る?」
「Status と Service Health の違いは?」
Azure Service Health とは、Azure側の障害や計画メンテを自分のサービスに絞って知らせる機能です。対象は、あなたが使うサービスとリージョン。世界中の全障害ではなく、自分に関係する情報だけが届きます。動いていたシステムが急に落ちたとき、自分の変更を疑ってコードを見直しても、原因がAzure側なら直りません。だからまず、事実をここで確かめます。
この記事では、まず障害が起きた朝の動きを追い、よく混同される3つのビューを表で切り分けます。次にアラートで通知を先回りして受け取る設定を示し、最後に「自分の障害か、Azure側か」を見誤らない勘所まで整理します。AZ-900の管理とガバナンス対策に効きます。
1. 障害の朝、まずどこを開くか
あなたのアプリが応答しなくなったとき、切り分けは「自分側か、Azure側か」の二択から始まります。デプロイした覚えがなく、監視のメトリクスにも異常が出ていない。それでも落ちている——このとき最初に開くのが、Azureポータルの Service Health です。
ここで大事なのは、Service Health が知らせるのはAzure基盤側の出来事だという点です。あなたのコードのバグや設定ミスは、ここには出てきません。だからこそ、Service Health に何も出ていなければ「原因は自分側」と当たりをつけられ、逆に障害情報が出ていれば「待つ・回避する」判断へ切り替えられます。個々のリソースの状態をさらに深掘りする時は、Azure Monitorとは と組み合わせると調査が速くなります。
2. 混同しやすい3つのビューを切り分ける
「正常性を確認する場所」は、実は3つあります。名前が似ていて混同しやすいので、見る範囲の広さで並べて整理してください。
| ビュー | 見る範囲 | 使う場面 |
|---|---|---|
| Azure Status | Azure全体（公開ページ・誰でも見られる） | 大規模障害が話題のとき全体状況を確認 |
| Service Health | 自分のサブスクリプション・リージョン・使用サービスに絞った通知 | 自分に関係する障害・計画メンテを知る |
| Resource Health | 個々のリソース（このVM・このDB）単位の正常性 | 特定リソースが不調な原因を切り分ける |
この3つは、広い方から狭い方へ絞り込む階段だと捉えると迷いません。全体を見る Azure Status、自分ごとに絞る Service Health、1リソースまで降りる Resource Health。障害対応では、まず Service Health で「自分に影響があるか」を見て、影響があれば Resource Health で「どのリソースか」を特定する流れが素直です。
3. アラートで「気づく前に知る」
Service Health の本当の価値は、ポータルを開いて眺めることではありません。アラートを設定して、障害が起きた瞬間にメールやTeamsへ通知を飛ばすところにあります。ユーザーから「落ちてます」と連絡が来る前に、あなたが先に知っている状態を作れます。
設定の勘所は、対象を絞ることです。あらゆる障害を受け取ると通知が多すぎて埋もれます。あなたが本番で使うサービスとリージョンだけに条件を絞れば、届く知らせは「自分ごと」だけになります。通知先も、深夜対応が要る重大障害はオンコール担当へ、計画メンテはチームのチャットへ、と分けておくと運用が回ります。
4. 計画メンテナンスは「予定」として扱う
Service Health の知らせのうち、見落とされがちなのが計画メンテナンスです。障害は突発ですが、メンテナンスは日時が予告されます。つまり、あなたが備えられる数少ない停止です。
たとえばVMが再起動を伴うメンテの対象になると、その時間帯に一時的なダウンが起きることがあります。事前に知っていれば、重要な処理を避ける・冗長構成で影響を吸収する、といった手を打てます。リソースグループ単位で影響対象を把握しておくと、どのシステムに関わる予定かを素早くつかめます。「知らないうちに再起動されて驚く」のと「予定として織り込む」のとでは、運用の落ち着きがまるで違います。
5. やりがちな失敗 と AZ-900での問われ方
切り分けで時間を溶かす典型が、Azure側の障害を、自分のバグだと思い込んで延々コードを追うことです。逆に、自分の設定ミスなのに「どうせAzureの障害だろう」と待ち続けるのも失敗です。どちらも、最初にService Healthを開いて事実を確認していれば避けられます。
あなたが手を止めて確認すべき順序は、こうです。
- Service Health に自分の影響が出ているか → 出ていれば「待つ・回避」、無ければ「自分側を疑う」
- Resource Health で該当リソースの状態 → 特定のVM・DBだけが不調か切り分ける
- それでも原因が見えない → 監視のログとメトリクスで自分側を深掘り
AZ-900では、「Azureサービスの障害や計画メンテナンスを確認する場所はどれか」という形で問われます。答えは Service Health。全体公開の Azure Status、個別リソースの Resource Health との役割の違いを、範囲の広さで押さえておけば、選択肢に引っかかりません。管理とガバナンスの分野では、こうした「運用を支える機能の役割」がよく狙われます。
次のステップ
Azureの管理・ガバナンスが試験全体でどう問われるかを俯瞰したいなら、AZ-900（Azure Fundamentals）の試験範囲と勉強法ガイド で学習の順序を組み立てるのが近道です。
知識を得点に変えたいなら、AZ-900 管理とガバナンスの問題集 で、正常性の確認まわりの設問に手を動かして慣れておくと定着します。