お客様のアクティビティが必要
インシデント前
Azure サービスの場合
- Azure portal で Azure Service Health の詳細を確認してください。 このページは、インシデント発生時に "ワンストップ ショップ" として機能します。
- Azure インシデントが発生したときに通知を自動的に生成するように構成できる、 Service Health アラートの使用を検討してください。
Power BI の場合
- Microsoft 365 管理センターで Service Health の詳細を確認してください。 このページは、インシデント発生時に "ワンストップ ショップ" として機能します。
- Microsoft 365 管理モバイル アプリを使用してサービス インシデントアラートの自動通知を取得することを検討してください。
インシデント中
Azure サービスの場合
- Azure 管理ポータル内の Azure Service Health は、最新の更新プログラムを提供します。
- Service Health へのアクセスに問題がある場合は、「 Azure の状態」ページを参照してください。
- [状態] ページへのアクセスで問題が発生した場合は、X (以前の Twitter) の @AzureSupport に移動します。
- 影響/問題がインシデントと一致しない場合 (または軽減策の後に保持される) 場合は、サポートサービス サポート チケットを発行します。
Power BI の場合
- Microsoft 365 管理センター内の [Service Health] ページで、最新の更新プログラムが提供されます
- Service Health へのアクセスに問題がある場合は、Microsoft 365 の状態ページを参照してください
- 影響/問題がインシデントと一致しない (または軽減策後も問題が持続する) 場合は、サービス サポート チケットを発行してください。
Microsoft の復旧後
この詳細については、以下のセクションをご覧ください。
インシデント後
Azure サービスの場合
- Microsoft は、レビューのために、 Azure ポータル - Service Health に PIR を発行します。
Power BI の場合
- Microsoft は、レビューのために、Microsoft 365 管理 - Service Health に PIR を発行します。
Microsoft を待機するプロセス
"Microsoft を待機する" プロセスでは、影響を受けたプライマリ リージョン内のすべてのコンポーネントとサービスを Microsoft が復旧させるのをただ待機します。 復旧したら、データ プラットフォームのエンタープライズ共有またはその他のサービスへのバインドと、データセットの日付を検証し、システムを現在の日付まで更新するプロセスを実行します。
このプロセスが完了すると、技術およびビジネスにおける対象分野の専門家 (SME) による検証が完了し、サービス復旧の利害関係者の承認が可能になります。
災害発生時の再配置
"災害に再デプロイする" 戦略では、次の高度なプロセス フローを記述できます。
Contoso のエンタープライズ共有サービスとソース システムを復旧する
- この手順は、データ プラットフォームの復旧の前提条件です。
- この手順は、エンタープライズ共有サービスと運用ソース システムを担当するさまざまな Contoso 運用サポート グループによって完了します。
Azure サービスの復旧 Azure サービスとは、Azure クラウド オファリングを構成するアプリケーションとサービスを指し、セカンダリ リージョン内で配置に使用できます。
Azure サービスとは、Azure クラウド オファリングを構成するアプリケーションとサービスを指し、セカンダリ リージョン内で配置に使用できます。
- この手順は、データ プラットフォームの復旧の前提条件です。
- この手順は、Microsoft およびその他のサービスとしてのプラットフォーム (PaaS)/サービスとしてのソフトウェア (SaaS) パートナーによって完了します。
データ プラットフォーム基盤の復旧
- この手順は、プラットフォーム回復アクティビティのエントリ ポイントです。
- 再デプロイ戦略では、必要な各コンポーネント/サービスが調達され、セカンダリ リージョンにデプロイされます。
- コンポーネントとデプロイ戦略の詳細な内訳については、このシリーズの Azure サービスとコンポーネントのセクション を参照してください。
- このプロセスには、エンタープライズ共有サービスへのバインド、アクセス/認証への接続の確保、ログ オフロードが機能していることを検証するなどのアクティビティも含める必要があります。同時に、アップストリームプロセスとダウンストリーム プロセスの両方への接続も確保します。
- データ/処理を確認する必要があります。 たとえば、復旧されたプラットフォームのタイムスタンプの検証などです。
- データの整合性に関する質問がある場合は、新しい処理を実行してプラットフォームを最新の状態に保つ前に、さらに時間的にロールバックすることを決定できます。
- (ビジネスへの影響に基づいて) プロセスの優先順位を付けるのは、復旧の調整に役立ちます。
- この手順は、ビジネス ユーザーがサービスと直接やり取りする場合を除き、技術的な検証によって締めくくる必要があります。 直接アクセスできる場合は、ビジネス検証手順が必要です。
- 検証が完了すると、個々のソリューション チームに引き継ぎ、独自のディザスター リカバリー (DR) 復旧プロセスを開始します。
- このハンドオーバーには、データとプロセスの現在のタイムスタンプの確認を含める必要があります。
- コア エンタープライズ データ プロセスを実行する場合は、個々のソリューションでこれを認識する必要があります 。たとえば、受信/送信フローです。
プラットフォームによってホストされている個々のソリューションの復旧
- 個々のソリューションには、独自の DR Runbook が必要です。 Runbook には、少なくとも、サービスの復旧が完了したことをテストして確認する、指名されたビジネス利害関係者が含まれている必要があります。
- リソースの競合や優先順位によっては、主要なソリューション/ワークロードが他のソリューションよりも優先される場合があります。たとえば、アドホック ラボよりもコア エンタープライズ プロセスです。
- 検証手順が完了すると、DR 復旧プロセスを開始するためのダウンストリーム ソリューションへの引き継ぎが行われます。
ダウンストリームの依存システムへの引き継ぎ
- 依存サービスが復旧されると、E2E DR 復旧プロセスが完了します。
Note
E2E DR プロセスを完全に自動化することは理論的には可能ですが、イベントのリスクと、E2E プロセスをカバーするために必要な SDLC アクティビティのコストが考えられる可能性はほとんどありません。
プライマリ リージョンへのフォールバック フォールバックとは、データ プラットフォーム サービスとそのデータが平常業務で使用可能になったときに、それをプライマリ リージョンに戻すプロセスです。
ソース システムとさまざまなデータ プロセスの性質によっては、データ プラットフォームのフォールバックを、データ エコシステムの他の部分とは別個に行うことができます。
適切な決定を行うために、お客様自身のデータ プラットフォームの依存関係 (アップストリームとダウンストリームの両方) を確認することをお勧めします。 次のセクションでは、データ プラットフォームを別個に復旧することを想定しています。
- 必要なすべてのコンポーネント/サービスがプライマリ リージョンで利用できるようになったら、お客様は Microsoft の復旧を検証するためのスモーク テストを完了します。
- コンポーネント/サービス構成が検証されます。 差分は、ソース管理からの再デプロイによって対処されます。
- プライマリ リージョンのシステム日付が、ステートフル コンポーネント間で確立されます。 確立された日付とセカンダリ リージョンの日付/タイムスタンプの間の差分は、その時点からデータ インジェスト プロセスを再実行または再生することによって対処する必要があります。
- ビジネスと技術の両方の利害関係者からの承認により、フォールバック ウィンドウが選択されます。 理想的には、これはシステムのアクティビティと処理の小康状態の間に発生する必要があります。
- フォールバック中は、システムが切り替えられる前に、プライマリ リージョンがセカンダリ リージョンと同期されます。
- 並列実行の期間が経過すると、セカンダリ リージョンはシステムからオフラインになります。
- セカンダリ リージョン内のコンポーネントは、選択した DR 戦略に応じて削除または削除されます。
ウォーム スペア プロセス
"ウォーム スペア" 方法の場合、おおまかなプロセス フローは "災害発生時の再配置" のものと非常に類似しています。主な違いは、セカンダリ リージョンでコンポーネントが既に調達されていることです。 この方法では、そのリージョンで独自の DR を実行しようとしている他の組織からのリソース競合のリスクがなくなります。
ホット スペア プロセス
「ホット スペア」戦略とは、セカンダリ システムがプライマリ システムと連携して実行されるため、PaaS やサービスとしてのインフラストラクチャ (IaaS) システムを含むプラットフォーム サービスが、障害発生に関係なく存続することを意味します。 "ウォーム スペア" 方式の場合と同様方法に、この方法では、そのリージョンで独自の DR を実行しようとしている他の組織からのリソース競合のリスクがなくなります。
ホット スペアのお客様は、プライマリ リージョンのコンポーネント/サービスの Microsoft の復旧を監視します。 完了すると、お客様はプライマリ リージョン システムを検証し、プライマリ リージョンへのフォールバックを完了します。 このプロセスは、DR フェールオーバー プロセスに似ています。つまり、使用可能なコードベースとデータを確認し、必要に応じて再配置します。
Note
ここで、システム メタデータが 2 つのリージョン間で一貫していることを特に注意して確認する必要があります。
- プライマリへのフォールバックが完了したら、システム ロード バランサーを更新して、プライマリ リージョンをシステム トポロジに戻すことができます。 使用可能な場合は、カナリア リリース アプローチを使用して、システムをプライマリ リージョンに段階的に切り替えることができます。
DR プランの構造
効果的な DR プランには、Azure 技術リソースによって実行できるサービス復旧のステップ バイ ステップ ガイドが示されます。 このような DR プランに推奨される MVP 構造を次に示します。
- プロセス要件
- DR の開始に必要な正しい承認、必要に応じて復旧に関する重要な決定 ("完了の定義" を含む)、サービス サポートの DR チケット参照、戦争室の詳細など、顧客の DR プロセス固有の詳細。
- DR のリードと実行者の予備を含むリソースの確認。 すべてのリソースは、プライマリとセカンダリの連絡先、エスカレーション パス、および休暇カレンダーを含めて文書化する必要があります。 DR の重大な状況では、名簿システムを考慮する必要がある場合があります。
- DR Executor、DR バックアップ、エスカレーション ポイントに関するノート PC、電源パックまたはバックアップ電源、ネットワーク接続と携帯電話の詳細。
- いずれかのプロセス要件が満たされていない場合に従うプロセス。
- 連絡先リスト
- DR リーダーシップとサポート グループ。
- 技術的復旧のテスト/レビュー サイクルを完了するビジネス中小企業。
- 影響を受けるビジネス所有者 (サービス復旧承認者を含む)。
- 影響を受ける技術所有者 (技術回復承認者を含む)。
- プラットフォームによってホストされる主要なソリューションを含め、影響を受けるすべての領域で SME がサポートされます。
- 影響を受けるダウンストリーム システム – 運用サポート。
- アップストリーム ソース システム – 運用サポート。
- エンタープライズ共有サービスの連絡先。 たとえば、アクセスと認証のサポート、セキュリティの監視、ゲートウェイのサポートなどです。
- クラウド プロバイダーのサポート連絡先を含む、外部またはサード パーティベンダー。
- アーキテクチャの設計
- エンド エンド (E2E) シナリオの詳細を説明し、関連するすべてのサポート ドキュメントを添付します。
- 依存関係
- すべてのコンポーネントのリレーションシップと依存関係を一覧表示します。
- DR の前提条件
- アップストリーム ソース システムが必要に応じて使用可能であることを確認します。
- スタック全体の昇格されたアクセスは、DR Executor リソースに付与されています。
- Azure サービスは必要に応じて利用できます。
- 前提条件のいずれかが満たされていない場合に従うプロセス。
- 技術的な回復 - 詳細な手順
- 実行順序。
- 手順の説明。
- 手順の前提条件。
- URL を含む、個別の各アクションの詳細なプロセス手順。
- 必要な証拠を含む検証手順。
- コンティンジェンシーを含め、各ステップの完了に予想される時間。
- ステップが失敗した場合に従うプロセス。
- エラーまたは SME サポートの場合のエスカレーション ポイント。
- 技術的な回復 - 前提条件の後
- キー コンポーネント間でシステムの現在の日付タイムスタンプを確認します。
- DR システムの URL と IP を確認します。
- システム アクセスの確認や、検証と承認を完了したビジネス中小企業を含む、ビジネス利害関係者レビュー プロセスに備えます。
- ビジネス利害関係者のレビューと承認
- ビジネス リソースの連絡先の詳細。
- 上記の技術的復旧に従ったビジネス検証手順。
- 復旧をサインオフするビジネス承認者に必要な証拠証跡。
- 回復後の必要条件
- 運用サポートに引き継ぎ、システムを最新の状態に保つデータ プロセスを実行します。
- ダウンストリームのプロセスとソリューションを引き継ぎ、DR システムの日付と接続の詳細を確認します。
- DR リードで復旧プロセスが完了したことを確認します。証拠証跡と完了した Runbook を確認します。
- 管理者特権を DR チームから削除できることをセキュリティ チームに通知します。
吹き出し
- 各手順のプロセスのシステム スクリーンショットを含めることをお勧めします。 これらのスクリーンショットは、タスクを完了するためのシステム中小企業への依存関係に対処するのに役立ちます。
- 急速に進化するクラウド サービスに対応するには、AZURE とそのサービスに関する現在の知識を持つリソースによって、DR プランを定期的に見直し、テストし、実行する必要があります。
- 技術的な復旧手順には、組織に対するコンポーネントとソリューションの優先順位が反映されている必要があります。 たとえば、コア エンタープライズ データ フローは、アドホック データ分析ラボの前に復旧されます。
- 技術的な復旧手順は、Key Vault などの基盤コンポーネントまたはサービスが復旧されたら、ワークフローの順序 (通常は左から右) に従う必要があります。 この戦略により、アップストリームの依存関係が使用可能になり、コンポーネントを適切にテストできるようになります。
- ステップ バイ ステップのプランが完了したら、余裕を含めたアクティビティの合計時間を取得する必要があります。 この合計が合意された目標復旧時間 (RTO) を超えている場合、いくつかのオプションを使用できます。
- 選択した復旧プロセスを自動化します (可能な場合)。
- 選択した復旧手順を並列で実行する機会を探す (可能な場合)。 ただし、この方法には追加の DR の実行者リソースが必要になる場合があります。
- 主要コンポーネントを PaaS などのより高いレベルのサービス レベルに引き上げ、Microsoft はサービス復旧アクティビティに対してより大きな責任を負います。
- 関係者と共に RTO を拡張します。
DR テスト
Azure クラウド サービス オファリングの性質により、いずれの DR テスト シナリオにも制約が生じます。 そのため、セカンダリ リージョンで使用できるように、データ プラットフォーム コンポーネントに DR サブスクリプションを立ち上げることをお勧めします。
このベースラインから、DR プラン Runbook を選択的に実行することで、配置および検証できるサービスとコンポーネントに特化して注意を払うことができます。 このプロセスにはキュレーションされたテスト データセットが必要です。これにより、プランに従って技術面とビジネス面の検証チェックを確認できます。
DR プランは、最新の状態であることを確認するだけでなく、フェールオーバーと復旧アクティビティを実行するチームが "身体で覚える" ために、定期的に試運転する必要があります。
- データと構成の予備も定期的に検査して、復旧アクティビティをサポートする "目的に適合している" ことを確認する必要があります。
DR テスト中に注目する主要な領域は、定められた手順が今も正しく、予測されたタイミングが引き続き妥当であることを確認することです。
- 手順にコードではなくポータル画面が示されている場合は、クラウドでの変更の頻度により、少なくとも 12 か月ごとに手順を検証する必要があります。
目標は完全に自動化された DR プロセスを持つことですが、イベントがめったに発生しないために、完全な自動化は現実的ではない可能性があります。 そのため、プラットフォームの提供に使用される Desired State Configuration (DSC) のコードとしてのインフラストラクチャ (IaC) を使用して復旧ベースラインを確立し、ベースラインに基づいて新しいプロジェクトが構築されるときにアップグレードすることをお勧めします。
- 時間の経過とともにコンポーネントとサービスが拡張されて、NFR の適用が必要になると、運用環境への配置パイプラインをリファクタリングして DR に対応する必要があります。
Runbook のタイミングが RTO を超える場合は、次のようにいくつかの選択肢があります。
- 関係者と共に RTO を拡張します。
- 自動化、タスクの並列実行、または上位のクラウド サーバー層への移行によって、復旧アクティビティに必要な時間を短縮します。
Azure Chaos Studio
Azure Chaos Studio は、Azure アプリケーションに障害を挿入することで回復性を向上させるマネージド サービスです。 Chaos Studio を使用すると、実験を使用して、安全かつ制御された方法で Azure リソースでのフォールト挿入を調整できます。 現在サポートされている障害の種類の説明については、製品ドキュメントを参照してください。
Chaos Studio の現在のイテレーションでは、Azure コンポーネントとサービスの サブセットのみが対象となります。 より多くの障害ライブラリが追加されるまで、Chaos Studio は、全システムの DR テストではなく、分離された回復性テストに推奨されるアプローチです。
Chaos Studio の詳細については、Azure Chaos Studio のドキュメントを参照してください。
Azure Site Recovery
IaaS コンポーネントの場合、Azure Site Recovery は、サポートされている VM または物理サーバーで実行されているほとんどのワークロードを保護します
次の強力なガイダンスがあります。
関連資料
- 回復性と可用性を考慮した設計
- 事業継続とディザスター リカバリー
- Azure アプリケーションのバックアップとディザスター リカバリー
- Azure の回復性
- サービス レベル アグリーメント (SLA) の概要
- 障害を予測するための 5 つのベスト プラクティス
次のステップ
シナリオを展開する方法を学習したので、Azure データ プラットフォーム シリーズの DR のまとめを読むことができます。