Microsoft 365 のデータ回復性

  • [アーティクル]

クラウド コンピューティングの複雑な性質を考えると、Microsoft は、問題が発生した場合ではなく、いつ発生するのかという点に留意しています。 クラウド サービスは、信頼性を最大限に高め、問題が発生した場合に顧客に与える悪影響を最小限に抑えるように設計されています。 複雑な物理インフラストラクチャに依存する従来の戦略を超えて、クラウド サービスに冗長性を直接組み込んでいっています。 複雑でない物理インフラストラクチャと、データの回復性をサービスに組み込み、お客様に高可用性を提供するインテリジェントなソフトウェアの組み合わせを使用しています。

回復性と回復性が組み込まれています

回復性と回復性の構築は、基盤となるインフラストラクチャとプロセスがどこかの時点で失敗するという前提から始まります。ハードウェア (インフラストラクチャ) は失敗し、人間は間違いを犯し、ソフトウェアにはバグが発生します。 ソフトウェア開発者がクラウドの前でこれらのことを考えていなかったと言うのは間違いですが、一般的な IT 実装でこれらの問題がどのように処理されたかは、クラウドの前では異なっていました。

  • まず、ハードウェアとインフラストラクチャの保護が重要でした。 この構造は、99.99% の信頼性を持つデータセンターには大きな電源とネットワークの冗長性が必要であり、サーバーはハードウェア ベースのクラスタリング、デュアル電源、デュアル ネットワーク インターフェイスなどを使用して実装されました。
  • 2 つ目は、プロセスが最も重要でした。 運用チームは厳格な手順を維持し、変更ウィンドウが採用され、多くの場合、プロジェクト管理のオーバーヘッドが大幅に発生しました。
  • 3 つ目は、デプロイが魅力的なペースで行われました。 ソースを所有せずにコードをデプロイすることは、パッチ リリースを待機することを意味し、メジャー バージョンのリリースにはハードウェアの交換と大幅な資本支出が関係しました。 さらに、問題を修正する唯一の方法は、ロールバックすることでした。 そのため、ほとんどの IT 組織は、最新の状態に保つための作業を回避するために、メジャー リリースのみを展開します。
  • 最後に、デプロイされたシステムの規模とその相互接続性のレベルは、これまでよりずっと小さくなりました。

現在、お客様は品質を損なうことなく Microsoft からの継続的なイノベーションを期待しています。これは、Microsoft のサービスとソフトウェアが回復性と回復性を念頭に置いて構築されている理由の 1 つです。

Microsoft 365 データ回復性の原則

回復性とは、クラウド ベースのサービスが特定の種類の障害に耐え、顧客の観点から完全に機能し続ける機能を指します。 データ回復性は、Microsoft 365 内で発生した障害に関係なく、重要な顧客データはそのまま残り、影響を受けないことを意味します。 そのために、Microsoft 365 サービスは、5 つの特定の回復性原則を中心に設計されています。

  • 重要なデータと重要でないデータがあります。 重大でないデータ (メッセージが読み取られたかどうかなど) は、まれなエラー シナリオで削除できます。 重要なデータ (電子メール メッセージなどの顧客データなど) は、極端なコストで保護する必要があります。 設計上の目標として、配信されたメール メッセージは常に重要であり、メッセージが読み取られたかどうかなどのことは重要です。
  • 障害を分離するには、顧客データのコピーを異なる障害ゾーンまたはできるだけ多くの障害ドメイン (たとえば、単一の資格情報 (プロセス、サーバー、またはオペレーター) からアクセスできるデータセンター) に分離する必要があります。
  • アトミック性、整合性、分離、持続性 (ACID) の一部が失敗した場合は、重要な顧客データを監視する必要があります。
  • 顧客データは破損から保護する必要があります。 アクティブにスキャンまたは監視され、修復可能で、回復可能である必要があります。
  • ほとんどのデータ損失は顧客の操作の結果であるため、誤って削除されたアイテムを復元できる GUI を使用して、顧客が自分で回復できるようにします。

Microsoft 365 は、これらの原則に対するクラウド サービスの構築と、堅牢なテストと検証を通じて、継続的なイノベーションと改善のためのプラットフォームを確保しながら、お客様の要件を満たし、それを超えることができます。