インシデントの際にどこに行くべきかと何が予想されるかを理解する
ここで "インシデント" と言う場合、それは特に Microsoft/Azure 側の問題、つまりお客様のサービスに影響を与えているプラットフォーム側の問題を指します。 このようなまれではあっても避けられない問題の際の当社の目標は、当社のエンジニアから直接定期的な更新情報を提供することにより、お客様に対して可能な限り透明性を保つことです。 当社は、適切なチャネルを通じて適切な人々に通知を行い、可能な限りの詳細を共有するように努めます。
当社は通常、憶測や内部的な一連のトラブルシューティングの作業内容は共有しませんが、インシデントに関して判明したことはすべて共有します。 お客様のサイズやセグメント、パートナー ステータス、またはサポート プランによる、情報伝達の遅延はありません (詳細な情報伝達に関しても同様です)。そのため、Microsoft パートナー組織であっても Microsoft アカウント チームであっても、影響を受けたお客様として同じタイミングで同じ更新情報の通知を受け取ります。
インシデント中
当社のエンジニアからの最新の更新情報を入手するには、Azure portal 内で Azure Service Health を確認してください。
問題に気付き、'それが自分の問題なのか Azure の問題なのか' を理解する必要がある場合、ポータルで Azure Service Health を確認することが最初に行うべきことです。 この '行くべき' 場所は認識しておく必要がありますが、あらかじめ関連するサービス正常性アラートを構成済みであれば、情報を探し回る必要はありません。 既知の問題の際には、これらのサービス正常性アラートがトリガーされ、それぞれの選択された通信チャネルを使用して通知されます。
Note
リマインダーとして、選択したチャネル (メール、SMS、Webhook) を介してポータル通信の通知を受け取るための Service Health アラートを設定してください
Service Health またはポータル自体へのアクセスに問題がある場合は、パブリックな Azure の状態ページを確認します。
万一、サービスの問題によって Azure portal の Service Health にアクセスできなくなっている場合、問題についての更新情報の投稿には azure.status.microsoft が使用されます。 このページは、通常の情報伝達パスを妨げる問題、または広範囲に及ぶまれな問題の場合に使用されます。
azure.status.microsoft は実体としては Azure Service Health のバックアップとして機能していることを忘れないことが重要です。 サービスの問題に関する伝達内容の大部分は、影響を受けるサブスクリプションまたはテナントに直接送信されるターゲット通知として提供されます。 これらは Azure portal の Azure Service Health によって配信されます。また、構成されている Azure Service Health アラートがあれば、これによってトリガーされます。 パブリック状態ページ (azure.status.microsoft) は、以下の 3 つの特定のシナリオでのサービスの問題に関する情報伝達にのみ使用されます。
シナリオ 1 - 複数のリージョン、ゾーン、またはサービスに関係する広範囲の影響 - サービスの問題が複数のサービスにまたがり、リージョン全体または複数リージョンにおける広範かつ重大な影響を顧客にもたらします。 このケースでは、高可用性やディザスター リカバリーなどのお客様側で構成された回復性は影響を回避するには不十分である可能性があるため、当社はお客様への通知を行います。
シナリオ 2 - Azure portal/Service Health にアクセスできない - サービスの問題により Azure portal または Azure Service Health にアクセスが妨げられるため、前述した障害時の標準的な通信経路に影響が生じました。
シナリオ 3 - サービスに影響があるが、誰が影響を受けるかが不明 - サービスの問題が広範かつ重大な影響を顧客にもたらしますが、影響を受ける顧客、リージョン、またはサービスを確認できていません。 このケースでは、ターゲット通信を送信できないためパブリック更新を提供します。
状態ページに問題がある場合は、X の @AzureSupport 経由で更新情報がないかを確認してください。
Azure の歴史の中で、azure.status.microsoft 上でのインシデントの更新情報の投稿を妨げる技術的な問題が発生したのは数回だけです。このような特殊な状況では、当社は X の @AzureSupport を介してインシデントの更新情報を投稿します。 ただし、問題に関係なく、問題であるかもしれない事象が確認されており、それに関する質問やサポートの質問がある場合は、ご自由に @AzureSupport に連絡をしてください。 @AzureSupport チームは通常 5 分以内に返信を行っています (当社はこれを非常に誇りに思っています)。ただし、既知の問題の場合 (たとえば、Service Health にリストアップされる停止があった場合)、適切なエンジニアがそのインシデントに既に対処中であるため、お客様を発生事象の公式のエンジニアリング更新情報へとご案内すること以外に @AzureSupport チームが支援のためにできることは、あまり多くない可能性があります。
ご自身の影響/問題がインシデントと一致しない場合 (または軽減策の後もそれらが継続する場合) は、サポートにお問い合わせください。
これは、インシデントの際に何を行うべきか (または行わないべきか) に関して理解するためにお客様にとって最も重要な注意事項です。 上で触れたように、既知の問題の場合 (たとえば、Service Health にリストアップされる停止があった場合)、適切なエンジニアがそのインシデントに既に対処中であるため、更新情報を得るためにお客様がサポートに連絡する必要はありません。 お客様は、Service Health (および各自の Service Health アラート) を介して定期的な更新情報を受け取る上、サポート エンジニアは影響を受けるお客様に提供される情報よりも詳細な情報にはアクセスできません。 お客様がエンジニアリングの更新情報を確認した上で、インシデントへの対応 (たとえば、フェールオーバー計画の実装など) のためにサポートを必要とする場合は、サポート チケットを発行できるので是非これを行ってください。
同様に、お客様が認識している現象が、問題の更新情報内で説明されている現象と "一致" しないように思われる場合 (たとえば、米国東部の Redis Cache に既知の問題があり、お客様は米国東部 2 の Redis Cache で問題を確認している場合)、その問題は関係がない可能性があり、お客様はサポート チケットを発行できるので是非これを行ってください。 最後に、サービスの問題が解決/軽減されても、お客様のサービスで依然として問題が確認されている場合、サポート エンジニアがお客様のリソースで何か特別なことが起きていないかを確認するのを支援できるので、是非サポート チケットを発行してください。