Azure でのビジネス継続性管理
Azure では、業界内でとても充実した、評価の高い事業継続マネジメント プログラムが維持されています。 Azure における事業継続の目標は、サービスがお客様向け (Azure オファリングの一部) であるか、内部のサポート プラットフォーム サービスであるかにかかわらず、独立して復旧可能なすべてのサービスについて復旧性と回復性を構築し、前進させることです。
事業継続について理解するには、多くのオファリングが複数のサービスで構成されている点に注意することが重要です。 Azure では、各サービスはツールによって静的に識別され、プライバシー、セキュリティ、インベントリ、リスクの事業継続マネジメント、およびその他の機能に使われる測定単位となります。 サービスの機能を適切に測定するために、サービスの種類にかかわらず、人、プロセス、テクノロジという 3 つの要素が各サービスに含まれます。
次に例を示します。
- ヘルプ デスクやチームなどの人的な事業プロセスが存在する場合、サービスの提供が行われます。 この人員はプロセスとテクノロジを使ってサービスを実行します。
- サービスとしてのテクノロジ (Azure Virtual Machines など) がある場合、サービスの提供はテクノロジと、その運用をサポートする人員とプロセスになります。
共同責任モデル
Azure が提供するオファリングの多くは、複数のリージョンでディザスター リカバリーを設定する必要があり、Microsoft の責任ではありません。 すべての Azure サービスがデータを自動的にレプリケートするわけではありません。また、すべての Azure サービスが、障害が発生したリージョンから自動的にフォールバックし、別の有効なリージョンにクロス レプリケートするわけではありません。 このような場合は、復旧とレプリケーションを構成する必要があります。
Microsoft では、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が保証されています。 ただし、一部のシナリオでは、複数リージョンの容量でデプロイとストレージを複製する必要があります (選択した場合)。 これらの例は、共有責任モデルを示しています。 これは、事業継続とディザスター リカバリー戦略における根本的な柱となります。
責任の部署
オンプレミスのデータセンターでは、お客様がスタック全体を所有します。 クラウドに資産を移行すると、責任の一部は Microsoft に移譲されます。 次の図は、デプロイの種類に応じたお客様と Microsoft の間での責任の範囲と区分を示しています。
共有責任モデルの好例として、仮想マシンのデプロイがあります。 リージョンの障害が発生した場合に回復性のためにリージョン間レプリケーションを設定する場合は、代替有効なリージョンに仮想マシンの重複するセットをデプロイする必要があります。 障害が発生した場合、Azure によって自動的にこれらのサービスのレプリケーションが行われることはありません。 必要な資産をデプロイするのはユーザーの責任です。 プライマリ リージョンを手動で変更するプロセスが必要です。または、Traffic Manager を使用して検出して自動的にフェールオーバーする必要があります。
お客様が有効にするすべてのディザスター リカバリー サービスでは、手順を示すドキュメントが公開されています。 お客様が有効にするディザスター リカバリーに向けた公開ドキュメントの例としては、Azure Data Lake Analytics に関する記事を参照してください。
共有責任モデルの詳細については、Microsoft トラスト センターを参照してください。
事業継続のコンプライアンス: サービスレベルの責任
各サービスでは、Azure の事業継続マネージャー ツールで事業継続ディザスター リカバリーのレコードを完成する必要があります。 サービスの所有者は、ツールを使ってフェデレーション モデル内で作業し、次のような要件を完全に満たすことができます。
サービスのプロパティ: サービスおよびディザスター リカバリーと回復性の実現方法を定義し、ディザスター リカバリーの責任者を特定します (テクノロジの場合)。 復旧の所有権の詳細については、前のセクションの共有責任モデルに関する説明と図を参照してください。
事業影響度分析: この分析は、サービスの所有者が、影響度の表全体にわたって、サービスの重要度に基づく目標復旧時間 (RTO) と回復ポイントの目標 (RPO) を定義するのに役立ちます。 運用、法律、規制、ブランド イメージ、財務に関わる影響度が、復旧の目標として使われます。
Note
Microsoft ではサービスの RTO や RPO が公開されていません。これらのデータは内部測定専用であるためです。 お客様への約束と測定は、すべて SLA に基づいています。致命的な損失にのみ適用される RTO や RPO よりも、より広い範囲がカバーされるためです。
依存関係: 各サービスでは、どれほど重大な問題が発生しても運用を継続するために必要な依存関係 (他のサービス) がマップされます。それはランタイムにマップされるか、復旧のみに必要か、またはその両方です。 ストレージの依存関係がある場合は、格納されている内容を定義する別のデータがマップされます。たとえば、特定の時点のスナップショットが必要な場合などです。
人員: サービスの定義で説明したように、サービスをサポートできる人員の場所と数を把握し、単一障害点が存在しないようにすること、また重要な人員を分散させ、1 つの場所に集まることによって生じる障害を回避することが重要です。
外部サプライヤー: Microsoft では外部サプライヤーの包括的なリストが保持されており、重要と見なされたサプライヤーは機能を測定されます。 サービスの依存関係として識別されたサプライヤーの機能を、そのサービスのニーズと比較し、サードパーティの停止によって Azure サービスが中断しないようにします。
復旧評価: この評価は、Azure 事業継続マネジメント プログラムに固有のものです。 この評価では、回復性のスコアを作成するためにいくつかの主要な要素を測定します。
- フェールオーバーする意図: そのプロセスが存在していても問題ありませんが、短期間の障害に対する最初の選択肢ではない可能性があります。
- フェールオーバーの自動化。
- フェールオーバーする意思決定の自動化。
最も信頼性が高く最短でフェールオーバーできるサービスは、自動化されており、人間による決定が不要なサービスです。 自動化されたサービスでは、ハートビート監視または代理トランザクションを使ってサービスが停止していることを判断し、すぐに修復を開始します。
復旧計画とテスト: Azure では、すべてのサービスに詳細な復旧計画を設定し、致命的な停止によってそのサービスが失敗した場合を想定してその計画をテストすることが要求されます。 復旧計画は、同様のスキルとアクセス権を持った人員がそのタスクを完了できるように作成する必要があります。 作成する計画においては、対象分野の対応可能な専門家に依存することを避けます。
テストはいくつかの方法で実行されます。たとえば、運用環境または運用環境に近い環境での自己テストや、カナリア リージョン セットでの Azure リージョン全体の停止に備えた訓練の一環としてのテストなどです。 これらの有効なリージョンは運用リージョンと同じですが、サービスに影響を与えずに無効にすることができます。 すべてのサービスが同時に影響を受けるため、テストは統合されていると見なされます。
お客様の有効化: ディザスター リカバリーの設定を担当する場合、Azure には一般向けのドキュメント ガイダンスが必要です。 このようなすべてのサービスについて、ドキュメントとそのプロセスに関する詳細情報へのリンクが提供されます。
事業継続のコンプライアンスを確認する
サービスでその事業継続マネジメントのレコードを完成したら、承認を受けるために送信する必要があります。 それは事業継続マネジメントの経験豊富な専門家に割り当てられ、完全性と品質についてレコード全体がレビューされます。 レコードがすべての要件を満たしている場合は、承認されます。 そうでない場合は、修正の要求と共に却下されます。 このプロセスによって、事業継続のコンプライアンスが満たされていることと、その作業がサービス所有者によってのみ証明されることについて、両方のパーティの同意が保証されます。 Azure の内部監査チームとコンプライアンス チームでは、最適なデータを確実に送信するために、定期的なランダム サンプリングも実行されます。
サービスのテスト
Microsoft と Azure では、ディザスター リカバリーと可用性ゾーンの準備の両方に対して広範なテストが実行されます。 サービスは運用環境または運用前環境で自己テストされ、主要なプラットフォームのフェールオーバーに依存していないサービスの独立した回復性が示されます。
サービスが実際のリージョン停止シナリオでも同様に復旧できることを保証するため、運用環境と一致する完全にデプロイされたリージョンであるカナリア環境で、プラグを抜く方式のテストが実行されます。 たとえば、クラスター、ラック、電源装置の電源を文字どおり切って、リージョン全体の障害をシミュレートします。
このようなテスト中、Azure では同じ運用プロセスを使って検出、通知、応答、復旧を行います。 訓練を予期している人はいません。また、復旧作業に対応するエンジニアは、通常のオンコール ローテーションのリソースです。 実際のイベント時には対応できない可能性のある、対象分野の専門家に依存できないタイミングで行われます。
これらのテストには、Microsoft の公開ドキュメントに従ってディザスター リカバリーを設定する責任があるサービスが含まれます。 サービス チームでは、お客様に似たインスタンスを作成して、お客様が有効にするディザスター リカバリーが想定どおりに動作することと、提供される手順が正確であることを示します。
認定の詳細については、Microsoft トラスト センターとコンプライアンスに関するセクションを参照してください。