Microsoft 365 の組み込みのサービス回復性

Microsoft は、一貫して機能し、お客様が信頼できる方法で高可用性を維持するソリューションを提供する必要性を認識しています。 特定のサービスが利用できない場合は、ダウンタイムと呼ばれます。 ダウンタイムの定義は、Microsoft 365 の各サービスによって異なりますが、一般的には、ユーザーがサービスの必須機能を使用できない時間帯に重点を置いています。 たとえば、Microsoft 365 サービス レベル アグリーメントから取得した SharePoint のダウンタイムの定義を次に示します。

"SharePoint ダウンタイム: ユーザーが適切なアクセス許可を持つ SharePoint サイト コレクションの任意の部分を読み取りまたは書き込むことができない期間。

各サービスごとのダウンタイムの定義については、サービスレベル契約 を参照してください。

ダウンタイムを予期できるできないに関わらず、ダウンタイムを最小限に抑えるために、Microsoft 365 のサービスは、次の 4 つの領域に重点を置き、問題回復を実現するよう設計、展開されています。

アクティブ/アクティブ デザイン

Microsoft 365 では、回復性を高めるアクティブ/アクティブな設計ですべてのサービスを設計および運用することを目指しています。 この設計は、ユーザーの要求に応答できるサービスのインスタンスが常に複数存在し、地理的に分散したデータセンターでホストされていることを意味します。 すべてのユーザー情報は、Microsoft Front Door から入り、サービスのインスタンスを最適に配置するため、またサービスの問題によるお客様への影響を防ぐ、または減らすため、自動的に振り分けられます。

インシデント スコープを減らす

サービス インシデントのスコープは、深刻度、継続期間、および影響を受けるユーザー数によって判断されます。 すべてのインシデントのスコープを制限する方法は次の通りです。

• 各サービスの複数のインスタンスを区切る。
• リングの検証をし、管理された段階的な方法で更新プログラムを展開し、更新プログラムから発生する可能性がある問題を、展開プロセスの初期段階で検出、軽減する。 この設計により、必要に応じて更新プログラムの回帰が可能になり、最初に Microsoft (内部リング) 内の小さなグループで行われ、140,000 人の Microsoft 従業員 (リング 2) のような大規模なグループに展開される前に、早期導入リング (リング 3) と最終的にすべての顧客 (リング 4) に展開されます。
• 自動化によって監視を強化します。 Microsoft 365 は大規模なサービスであり、SLA ターゲットのアップタイムが高くなっています。 サービス インシデントの一番最初の段階で、人間が調査し、対応する必要があったとしても、SLA に対して十分な速度で対応できませんでした。 自動化は、サービス インシデントを迅速かつ効果的に検出して対応する鍵です。 あらかじめ知っておくことで、すばやく対処できるのです。

Microsoft 365 サービス アーキテクチャに組み込まれているアクティブ/アクティブな機能に加えて、これらの取り組みは、サービス インシデント中に影響を受ける顧客の重大度、期間、および数を軽減します。

完全分離

サービスがアクティブ/アクティブな方法で設計および運用され、区切られることで、一方の問題が別のサービスに影響を与えるのを防ぎます。サービスのコードベースは完全分離と呼ばれるパーティションの原則と同様の方法を使用して開発されます。 完全分離は、コードベース内で作られる増分保護で測定されます。 これらは、ある領域の問題を他の操作領域に連鎖するのを防ぐのに役立ちます。

障害分離対策は、コード開発、サービスのデプロイ、負荷分散、データベース レプリケーションなど、サービスの開発と配信の複数の段階で適用されます。

Microsoft のセキュリティ開発ライフサイクル (Security Development Lifecycle: SDL) は、回復性およびセキュリティとコンプライアンス要件のサポートをさらに増進させます。 SDL は、サービスの回復性、安全性、対応の開発を支援します。 SDL の主な要素には、 Microsoft クラウド内の、コードレビュー、脅威モデル、侵入テスト、標準化されたインシデント対応プロセスが含まれます。

Microsoft 365 サービスは高度に相互接続されていますが、その背後にあるシステムとテクノロジは、1 つのサービス インシデントが他のサービスに流出する影響を制限する方法で設計されています。 たとえば、Exchange に影響を与える問題は Teams のコア機能に影響しません。また、SharePoint の検索機能に関する問題は、ファイルをアップロードまたはダウンロードするユーザーの機能には影響しません。

継続的なサービスの向上

問題が発生した場合は、真剣に取り組みます。 この冗長クラウド アーキテクチャと厳格な社内プロセスが、サービスのアクセシビリティを高めています。 インシデントの間に、影響を受けるサービスが監視によって迅速に検出され、テナントが影響を受けた場合は、さまざまなチャネルを通じて通知されます。 同時に、エンジニアは定められたプロセスに従って問題を選別し、必要な手順を取り、可能な限り迅速に通常の運用を復元します。 サービスが正常に回復した後は、サービスの継続的な向上の一環として、インシデントの事後レビューを投稿します。 インシデントの事後レビューでは、インシデントの根本原因および、問題を修正するための必要事項について確認します。 そして、その状況から学んだことを、設計と運用に適用します。 この知識により、同じ根本原因が他のサービスや追加のお客様に影響を与えるのを防ぐことができます。