Microsoft では、必要なときにサービスがいつでも使用できるように取り組んでいますが、 ただし、計画外のサービス中断が発生します。 この記事では、その場合の動作について説明します。
Microsoft は、アップタイムと接続のコミットメントとして、多くのサービスにサービス レベル アグリーメント (SLA) を提供しています。 個々の Azure サービスの SLA については、 Azure サービス レベル アグリーメントに関するページを参照してください。
インシデントスコープを理解する
インシデントがある場合、そのインシデントの範囲を理解している場合は、最適なアクション のコースを決定できます。
インシデントのスコープを理解するには、次の手順に従います。
次の機能を提供する Azure Service Health に移動します。
サービスに影響を与える可能性のある問題またはイベントに関する情報。
インシデントの自動更新アラートにより、インシデントの状態の更新を自動的に通知できます。 Microsoft がインシデントの範囲を理解すると、インシデントの状態が更新されます。 これらの状態の更新を構成して Azure Monitor アクション グループに移動できます。これにより、電子メール アドレスや独自のインシデント管理システムなど、さまざまな場所にアラートを送信できます。
Azure portal へのアクセスに問題がある場合は、 Azure の状態に移動します。
ステータス ページに問題がある場合は、ソーシャル プラットフォーム X で @AzureSupport からの投稿を確認します。
可用性ゾーンとデータセンターのインシデント
多くの問題は、1 つの 可用性ゾーンに制限されています。 可用性ゾーンは、同じリージョン内の他の可用性ゾーンから分離されたデータセンターまたはデータセンターのグループを表します。 可用性ゾーンで問題が発生した場合、表示される影響は、サービスのデプロイ方法によって異なります。
- 影響を受ける可用性ゾーンに固定されているゾーン のサービスが影響を受ける可能性があります。
- ゾーン冗長サービス が影響を受ける可能性はほとんどありません。 ゾーン冗長リソースに対して修復アクションを実行する必要はありません。
- リージョン (ゾーン以外) のサービス は、影響を受ける可用性ゾーンを使用する可能性があるため、影響を受ける可能性があります。
Azure サービスでの可用性ゾーンのサポートの詳細と、ゾーン、ゾーン冗長、リージョン (非ゾーン) サービスの違いについては、 可用性ゾーンのサポートがある Azure サービスを参照してください。
影響を受ける可用性ゾーンにデプロイされたゾーンまたはリージョンのリソースに問題がある場合は、 ビジネス継続性 と ディザスター リカバリー (BC/DR) 計画を開始することを検討してください。
論理可用性ゾーンと物理可用性ゾーン
各 Azure サブスクリプションには、異なる可用性ゾーンの一覧が表示されます。 各サブスクリプションで使用される 論理 ゾーンは、異なる 物理 ゾーンに対応している場合があります。 論理ゾーンと物理ゾーンの間でマップして、影響を受ける物理可用性ゾーンで実行されているリソースを確認できます。 詳細については、 物理可用性ゾーンと論理可用性ゾーンに関するページを参照してください。
リージョン全体のインシデント
場合によっては、問題がリージョン全体に影響を与えることがあります。 リージョン全体の問題は、リージョンに可用性ゾーンがない場合に発生する可能性があります。 リージョン全体のインシデントが発生した場合は、 ディザスター リカバリー計画の開始を検討することが必要になる場合があります。 計画には、別のリージョンへのフェールオーバーが含まれる場合があります。
ビジネス継続性に優先順位を付ける
インシデントに直面した場合、最優先事項は、ビジネス操作を実行し続けることです。 問題の原因を特定または修正することに重点を置きすぎると、ソリューションの運用の復元やビジネス継続性の維持から注意を奪う可能性があります。
次の要因は、ビジネス継続性を維持するために必ずしも何もする必要がない状況を示しています。
運用環境 のリソースと、ユーザーまたはワークロードに対する問題の実際の影響。 たとえば、標準の営業時間外に発生する問題では、すぐに何もする必要がない場合があります。
インシデントのスコープ。 単一の可用性ゾーンに分離された問題については、ゾーン冗長リソースを使用している場合や、使用するリソースが影響を受けない物理可用性ゾーンにある場合は、何もする必要がない場合があります。
使用可能な場合の推定解決時間。 Microsoft は、できるだけ早く復旧するための明確なタイムラインを提供するよう努めています。 復旧手順の実行にかなりの時間がかかる場合は、完了までに問題が解決されることが予想されるかどうかを検討してください。
影響を受けるワークロードのユーザーと共に確立されたサービス レベル目標 (SLO) (ある場合)。 この種の状況では、SLO が意思決定の指針となります。 たとえば、状況によっては、サービスが正常になるまで手動操作に切り替えることができる場合があり、この決定がシステムの SLO に反映される場合があります。 SLO とその定義方法の詳細については、「Azure Well-Architected Framework で 信頼性ターゲットを定義するための推奨事項 」を参照してください。
ただし、ビジネス継続性に何らかのアクションが必要で、ディザスター リカバリー計画が実施されている場合は、次の手順では、その計画を開始するかどうかを検討します。
ディザスター リカバリー計画を検討する
ディザスター リカバリー計画では、大規模なインシデントが発生した場合に行うことを想定して説明します。 ディザスター リカバリー 計画には、通常、次のようなアクションが含まれます。
- 可用性ゾーン内で分離された停止が発生した場合は、可能であればリソースをスケールアウトします。
- ゾーン サービスを使用するときに可用性ゾーンが停止する場合は、別の可用性ゾーンにデプロイし、別の可用性ゾーンにフェールオーバーします。
- ゾーン冗長サービスを使用する場合の可用性ゾーンの停止については、何もする必要がない場合があります。 パフォーマンスの問題が発生した場合は、残りのゾーン内のインスタンスが受信したトラフィックの流入を処理できるように、リソースをスケールアウトすることを検討してください。
- リージョンの障害が発生した場合は、別のリージョンにデプロイしてフェールオーバーします。
Important
考え抜かなくても何も行動を取らないでください。 急いで決定すると、状況が悪化することがあります。 シナリオに対応するディザスター リカバリー 計画を既に開発している場合は、通常、現時点で計画を作成するのではなく、それを使用することをお勧めします。
フェールオーバーは複雑なプロセスになる可能性があります。 フェールオーバーは、コストとリスクを正当化できる場合にのみトリガーする必要があります。 場合によっては、ダウンタイムが開始される前にリージョン間で最近の変更がレプリケートされなかった場合など、データが失われる可能性があります。 また、特に別のリージョンのデプロイにトラフィックをリダイレクトする必要がある場合は、ダウンタイムが発生する可能性があります。 ソリューションの設計方法によっては、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 Incident の振り返りライブストリームに参加して質問に回答するか、 記録を視聴してください。
SLA クレジットの対象になると思われる場合は、問題の種類が "払い戻し要求" である 新しいサポート要求を作成 し、インシデント追跡 ID を含めます。
インシデントから学習して、独自の回復性とプロセスを改善できることを検討します。 次のような質問を検討してください。
ディザスター リカバリー計画はどのくらいうまく機能しましたか? 改善点はありますか? 詳細については、 ディザスター リカバリー戦略に関する Azure Well-Architected Framework ガイダンスを参照してください。
インシデントへの対応は、その重大度に適していましたか? そうでない場合は、より良い情報を得て、何をすべきかについてより良い意思決定を行うことができる方法はありますか?
使用する サービスの Azure サービス信頼性ガイド はありますか? 信頼性ガイドでは、回復性の要件を満たすように構成できる Azure サービスの数に関する情報を提供します。
この種の問題に対する将来の回復性を向上させるために、設計上のトレードオフはありますか? 詳細については、 Azure Well-Architected Framework の信頼性の柱を参照してください。
この計画外の停止が発生したので、ユーザーに提供される SLO または SLA は引き続き適切ですか? ここで、ユーザー ベースに対して行っているコミットメントを見直して、このインシデントから学習した内容に期待値を合わせます。
今後のインシデントが自動的に通知されるように Azure Service Health アラート を構成する必要がありますか?
インシデント対応を改善する方法に関するフィードバックがある場合は、割り当てられた Microsoft の担当者または Azure フィードバック サイトからお知らせください。