次の方法で共有

Microsoft 365 のデータ回復性

  • [アーティクル]

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

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

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

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

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

Microsoft 365 データの回復性の原則

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

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

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