Azureが動かないとき、どの状態を確認する？Status・Service Health・Resource Healthの違い

自分のAzure環境への影響はService Health、個々のリソースはResource Healthで確認します。Azure Statusは、広い影響など一定の条件に当てはまる問題を知らせる公開ページです。 三つは、同じ状態を別の名前で表示しているわけではありません。

この記事では「申込ページが開かない」という架空の症状から、情報を読む順番を整理します。設定を直す手順や、現在の障害速報ではありません。

三つの画面は、答える問いが違う

Microsoftの三つのサービスの概要をもとにした整理です。「リソース」がまだ曖昧なら、リソース・リソースグループ・サブスクリプションの違いから確認できます。

まずService Health。ポータルに入れないときは公開情報へ

普段の利用環境について調べるなら、AzureポータルのService Healthを入口にします。Microsoftも、利用者向けには個別の情報が得られるService Healthの利用を勧めています。Azure Statusの位置づけ

情報を読める権限があることを前提に、次の順で見てみましょう。これは確認の進め方の提案で、実画面で検証したクリック手順ではありません。

1. 対象のサブスクリプション、サービス、リージョンを手元の構成情報と照合する
2. Service Healthの「Service issues」で、対象に関係する通知を探す
3. 通知があれば、影響範囲、開始時刻、最終更新、現在の説明を読む
4. 対象のリソースが分かれば、Resource Healthも確認する

Service issuesには範囲を示すScopeやサービス・リージョンなどがあり、詳細にはTracking IDや更新情報が表示されます。Summary内の時刻は公式資料ではUTCとされています。手元の発生時刻もタイムゾーン付きで記録すると、照合しやすくなります。通知で確認できる項目

Service Healthには、現在のサービス問題だけでなく計画メンテナンスや助言もあります。通知があるだけで、今の症状の原因だとは決められません。 対象と時間が合っているかを確かめます。通知の種類と表示範囲

ポータルやService Healthにアクセスできない場合は、公開のAzure Statusが確認先になります。ただし、アクセスできない原因そのものを、この公開ページだけで特定できるわけではありません。

利用環境の通知はService Health、個別の状態はResource Health。ポータルに入れないときはAzure Statusも確認。どの表示も、症状の発生時刻や対象と照合します。

Azure Statusに問題が出ていなくても、確認を終えない

公開ページは、すべての顧客のすべての問題を載せる一覧ではありません。掲載条件には、複数サービスに及ぶ大きな影響、ポータルやService Healthへアクセスできず通常の通知経路が使えない場合、影響先がまだ特定できない大きな問題などがあります。公開する問題の条件

そのため、公開ページに問題が見当たらないことから「自分の環境にも問題はない」とは言えません。Service Healthで自分に関係する通知を確認し、必要に応じて個別リソースへ進みます。

Resource HealthのAvailableは、申込完了の保証ではない

Resource Healthでは、対象リソースの状態を読みます。公式概要の分類は次の四つです。

Unknownは「障害が確定」、Unavailableは「必ずMicrosoft側の障害」という意味ではありません。ユーザーの操作による停止などが関係する場合もあるため、状態名だけでなく詳細を読みます。状態の公式定義・UnknownについてのFAQ

また、確認対象はリソースの種類によって異なります。Webアプリの公式チェック一覧には、ホストや負荷分散の状態、データセンター内からの到達性などが挙げられています。リソース別のチェック一覧

この範囲から考えると、Availableという表示だけで、利用者の端末から申込を完了できるかまでは判断できません。表示と症状が食い違っても、症状の記録を捨てず、アプリや接続先などの確認を担当者に引き継ぎます。

架空の観察メモで「分かったこと」を分ける

ある勉強会の担当者が、次のように記録したとします。時刻・症状・表示はすべて説明用に作ったもので、実際の障害記録ではありません。

この例で次にするのは、状態表示だけで復旧を宣言することではなく、対象に関係するService Healthの通知を読むことです。それでも説明がつかなければ、「何を、いつ確認したか」を添えて、運用担当者の調査につなげます。

最後に、手元のメモへ「症状と発生時刻」「対象のリソース」「確認先と確認時刻」「通知のID・更新内容」の四つの欄を作ってみてください。確認できていない欄は、そのまま未確認にしておけば、次に調べることが見えます。

対象のリージョンの意味を整理したい場合は、リージョンと可用性ゾーンの違いへ進めます。状態を見るために、リソースの再起動や権限変更を試す必要はありません。