Microsoft では、必要なときにサービスがいつでも使用できるように取り組んでいますが、 ただし、計画外のサービス中断が発生する場合があります。 この記事では、そのような場合に何が起こるかについて説明します。
Microsoft は、稼働時間と接続に関するコミットメントとして、サービスの多くにサービス レベル アグリーメント (SLA) を提供しています。 個々の Azure サービスの SLA については、 Azure サービス レベル アグリーメントに関するページを参照してください。
インシデントのスコープを理解する
インシデントが発生した場合、そのインシデントのスコープを理解していれば、最善の行動方針を判断できます。
インシデントのスコープを理解するには、次の手順を実行します。
Azure Service Health に移動します。次の機能があります。
サービスに影響を与える可能性がある問題やイベントに関する情報。
自動インシデント更新アラート。インシデントの状態が更新されたときに自動的に通知を受け取ることができます。 Microsoft がインシデントのスコープを理解した場合、インシデントの状態を更新します。 このような状態更新が Azure Monitor アクション グループに送信されるように構成できます。こうすることで、メール アドレスや独自のインシデント管理システムなどのさまざまな場所にアラートを送信できます。
Azure portal へのアクセスに問題がある場合は、「Azure の状態」に移動します。
状態ページに問題がある場合は、ソーシャル プラットフォーム X で @AzureSupport からの投稿を確認してください。
可用性ゾーンとデータセンターのインシデント
多くの問題は、1 つの可用性ゾーンに限定されています。 可用性ゾーンは、同じリージョン内の他の可用性ゾーンから分離されたデータセンター、またはデータセンターのグループを表します。 可用性ゾーンで問題が発生した場合、その影響はサービスのデプロイ方法によって異なります。
- 影響を受ける可用性ゾーンに固定されている "ゾーン サービス" が影響を受ける可能性があります。
- "ゾーン冗長サービス" が影響を受ける可能性は低いでしょう。 ゾーン冗長リソースに対して修復アクションを実行する必要はありません。
- "リージョン (非ゾーン) サービス" は、影響を受ける可用性ゾーンを使用する可能性があるため、影響を受ける可能性があります。
Azure サービスでの可用性ゾーンのサポートと、ゾーン、ゾーン冗長、リージョン (非ゾーン) サービスの違いの詳細については、「可用性ゾーンをサポートする Azure サービス」を参照してください。
影響を受ける可用性ゾーンにデプロイされているゾーンまたはリージョンのリソースに問題がある場合は、ビジネス継続性およびディザスター リカバリー (BC/DR) 計画を開始することを検討してください。
論理と物理の可用性ゾーン
各 Azure サブスクリプションには、異なる可用性ゾーンの一覧が表示されます。 各サブスクリプションで使用される "論理" ゾーンは、異なる "物理" ゾーンに対応する場合があります。 論理ゾーンと物理ゾーン間をマップして、影響を受ける物理可用性ゾーンで実行されているリソースを確認できます。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。
リージョン全体のインシデント
場合によっては、問題がリージョン全体に影響することがあります。 リージョンに可用性ゾーンがない場合、リージョン全体の問題が発生する可能性があります。 リージョン全体のインシデントが発生した場合は、必要に応じてディザスター リカバリー計画の開始を検討してください。 別のリージョンへのフェールオーバーを計画することもできます。
ビジネス継続性を優先する
インシデントに直面した場合、最優先事項は業務を継続することです。 問題の原因の切り分けや修正に重点を置きすぎると、ソリューションの運用を復元することやビジネス継続性を維持することから注意が逸れてしまう可能性があります。
次のような要因は、ビジネス継続性を維持するために必ずしも何かする必要がない状況を示しています。
運用リソース、ユーザーまたはワークロードに対する問題の "実際の影響"。 たとえば、標準の営業時間外に発生した問題では、すぐに何か対応する必要がない場合があります。
インシデントのスコープ。 1 つの可用性ゾーンに分離された問題の場合、ゾーン冗長リソースを使用している場合、または使用するリソースが影響を受けない物理可用性ゾーンにある場合は、何もする必要がない場合があります。
"推定解決時間" (可能な場合)。 Microsoft は、復旧に向けた明確なタイムラインをできるだけ早く提供するよう努めています。 復旧手順の実行にかなりの時間がかかる場合は、その手順が完了するまでに問題が解決する見込みがあるかどうかを検討してください。
影響を受けるワークロードのユーザーとの間で規定されている "サービス レベル目標 (SLO)" (存在する場合)。 SLO は、このような状況での意思決定の指針となります。 たとえば、状況によっては、サービスが正常になるまで手動操作に切り替えることができます。そして、この決定がシステムの SLO に反映されることがあります。 SLO とその定義方法の詳細については、Azure Well-Architected フレームワークの「信頼性目標を定義するためのレコメンデーション」を参照してください。
ただし、ビジネス継続性のために何らかの対応が必要であり、ディザスター リカバリー計画を既に策定している場合、次の手順はその計画を開始するかどうかを検討することです。
ディザスター リカバリー計画を検討する
ディザスター リカバリー計画では、重大なインシデントが発生した場合に想定される実行内容について説明します。 通常、ディザスター リカバリー計画には、次のようなアクションが含まれます。
- 可用性ゾーン内に分離された停止が発生した場合、可能であればリソースをスケールアウトします。
- ゾーン サービスを使用するときに可用性ゾーンが停止した場合は、別の可用性ゾーンにデプロイし、別の可用性ゾーンにフェールオーバーします。
- ゾーン冗長サービスを使用しているときに可用性ゾーンが停止した場合、何もする必要がない場合があります。 パフォーマンスの問題が発生した場合は、残りのゾーンのインスタンスが受けるトラフィックの急増を処理できるように、リソースをスケールアウトすることを検討してください。
- リージョンが停止した場合は、別のリージョンにデプロイしてフェイル オーバーします。
重要
よく考えずに行動を起こさないでください。 急いで決断を下すと、状況が悪化することがあります。 このシナリオに対応するディザスター リカバリー計画を既に作成している場合は、通常、場当たり的に計画を作成するのではなく、それを使用することをお勧めします。
フェールオーバーは複雑なプロセスになる場合があります。 コストとリスクを正当化できる場合にのみ、フェールオーバーをトリガーするようにしてください。 ダウンタイムが始まる前に最近の変更がリージョン間でレプリケートされなかった場合など、状況によってはデータ損失が発生する可能性があります。 また、特にトラフィックを別のリージョンのデプロイにリダイレクトする必要がある場合には、ダウンタイムが発生する可能性があります。 ソリューションの設計方法によっては、DNS レコードを更新し、状況に応じてそれが反映されるまで待つ必要があります。
Microsoft が開始するフェールオーバー
一部の Azure サービスは、インシデントの発生時に自動的に代替リージョンにフェールオーバーします。 これらのサービスのフェールオーバー プロセスは Microsoft が管理します。 ただし、Microsoft が開始するフェールオーバーは、通常、復旧の試行にかなりの時間を費やした後、最後の手段として実行されます。 一般に、Microsoft のポリシーは、たとえ復旧時間が長くなったとしても、データ損失を最小限に抑えることです。 自分のソリューションで、特に復旧時間を最小限に抑える必要がある場合は、Microsoft が開始するフェールオーバーだけに頼らないでください。 可能であれば、Azure Storage などのサービスには顧客が開始するフェールオーバーを使用してください。
Azure サポート
サービス インシデントが Azure Service Health で既に通知されている場合は、すべての最新情報がここで提供されるため、サポート リクエストを開く必要はありません。
ただし、次の場合にはサポート ケースを開くことを検討してください。
Azure Service Health のインシデントの説明に記載されていない問題が発生している。
復旧作業の一環として Microsoft の支援が必要。
ヒント
サービス中断の影響を受けた場合は、問題が軽減されてから最長 72 時間以内は、無料のサポート チケットを発行して、復旧に必要な手順の支援を受けることができます。
サポート ケースを開くときは、影響を受けるリソースと問題の影響を明確に説明してください。 Azure サブスクリプション ID と問題が発生しているリージョンを指定します。 ビジネスへの影響に基づいてサポート ケースの重大度を設定します。 Azure サービスの中断時には、ここで説明した条件以外でも、多くのお客様が事後対応的に Azure サポートに問い合わせる可能性があることに注意してください。 Azure サポート リソースに対してこのような追加の負荷があると、残念ながらサポート ニーズへの対応が遅れる可能性があります。
インシデント後
Microsoft がそのインシデントから把握した内容については、Azure Service Health の [正常性の履歴] ペインから、またはお客様が構成した Service Health アラートを通じて、インシデントの事後レビュー (PIR) をお読みください。 インシデントが異なれば、取得される PIR の種類も異なる場合があります。 通常、暫定的な PIR はインシデントの数日後に公開され、より包括的な PIR は数週間後に公開されます。
公開状態ページに掲載された重大なインシデントについては、Azure インシデントの振り返りライブストリームに参加して質問に答えてもらうか、録画をご覧ください。
SLA クレジットの対象となる可能性があると思われる場合は、問題の種類が "払い戻しリクエスト" の新しいサポート リクエストを作成し、インシデント追跡 ID を含めます。
回復性とプロセスを改善するために、インシデントから何を学べるかを検討します。 次のような質問を検討しましょう。
ディザスター リカバリー計画はどの程度うまく機能しましたか? 改善できる点はありますか? 詳細については、ディザスター リカバリー戦略に関する Azure Well-Architected フレームワークのガイダンスのページを参照してください。
そのインシデントへの対応は、その重大度に適していましたか? そうでない場合、より適切な情報を入手して、実行すべきことについてより適切な判断を下す方法はあるでしょうか?
使用しているサービスに対する Azure サービスの信頼性ガイドはありますか? 信頼性ガイドには、いくつの Azure サービスを構成すれば回復性要件を満たすことができるかについての情報が記載されています。
この種の問題に対する将来の回復性を向上させるために、設計上のトレードオフはありますか? 詳細については、Azure Well-Architected フレームワークの信頼性の柱に関するページを参照してください。
このような計画外の停止が発生した今でも、ユーザーに提供している SLO または SLA は適切ですか? このインシデントから学んだことと期待を一致させるには、今がユーザー ベースに対する取り組みを見直す良い機会です。
今後のインシデントが自動的に通知されるように、Azure Service Health アラートを構成する必要はありますか?
インシデント応答を改善する方法についてフィードバックがある場合は、お客様の Microsoft 担当者を通じて、または Azure フィードバック サイトを通じてお知らせください。