この記事では、Microsoft 365 の依存関係を考慮したビジネス継続計画の開発に関するガイダンスを提供します。 ここでは、ビジネス機能を分析し、Microsoft 365 サービスに依存するものを特定する方法をお勧めします。 この分析は、サービスエラーが発生する可能性があり、それらの可能性に備える必要があることを期待して実行します。
大まかに言えば、ビジネス継続性計画には、評価、計画、機能検証、コミュニケーションと調整の 4 つの側面が含まれます。
料金の考え方の案内
まず、organizationのビジネス機能と、それらをサポートするサービスとプロセスを特定します。 この手順には、ビジネスへの影響分析の完了が含まれます。ここで、各ビジネス機能を重要度に応じてランク付けし、それぞれに依存するプロセスとサービスを特定します。 評価を開始する際に参考になるサンプルの表を下に示します。
サンプル事業影響分析 (BIA)
これは name of the service, system, process, or function に関する BIA ドキュメントです。
| BIA フィールド | 説明 |
|---|---|
| BIA の種類 | is it a business process or technology, service or system? |
| BIA 名 | name of the service/system/function/process |
| サービスの説明 | give a full description of the service, process, or function |
| エンタープライズ関数 | some examples: customer services; legal; marketing; risk management, security, sales, information technology, production, manufacturing |
| 会計年度 | the current fiscal year, re-evaluate these on a regular basis |
| 臨界 | develop your own classifications, but here are some examples: mission critical, important, deferrable |
| 部署 | name of the business unit that owns this business function |
| プロセス (サービス、機能) | the name of the process, service, or feature |
| ビジネス グループのシニア リーダー | the name and contact information of the senior leader of the business group that owns this business process |
| テクノロジには、 内部 サービス レベル アグリーメント (SLA) または運用レベル アグリーメント (OLA) が確立されていますか? | please explain in as much detail as possible |
| このテクノロジには、確立された外部 SLA または OLA はありますか? | please explain in as much detail as possible |
| このテクノロジには、特定のプロセス SLA を牽引する既知の取締役命令はありますか? 「はい」の場合は、詳細を説明します。 | details here |
| このサービスに関連付けられているデータの損失または侵害によって、大きなイベントがトリガーされますか? 「はい」の場合は、詳細を説明します。 | details here |
| このサービスには、主要機能の一部またはすべての代わりとなる回避策や代替方法が用意されていますか? 「はい」の場合は、詳細を説明します。 | details here |
| サービスは、個人を特定できる情報 (PII) などの顧客データを処理、保存、または送信しますか? 「はい」の場合は、詳細を説明します。 | details here |
| BIA の状態 | develop your own status classification, here are some examples: planned, started, in-progress, complete, on-hold, expired |
| 完了日 | the date this BIA was completed |
| BIA ファシリテータ | name of the person or group who is responsible for developing and maintaining this BIA |
| BIA 承認 | name of the person or group who is the executive sponsor of this BIA and who has responsibility for approving it. |
| 共同作成者 | optional list of the people who helped develop this BIA and their contact information |
| BIA 承認の保管場所 | indicate where the executive approval is located, or attach proof to this document |
計画
次に、ビジネス プロセス全体を見て、カスケード依存関係が存在する場所を確認します。 結果に基づいて、回復性戦略の優先順位を付けて形成し、戦略をサポートする標準的な運用手順を作成します。
Microsoft Service Map を使用すると、このマッピングに役立ちます。 Microsoft Service Map は、Windows および Linux システム上のアプリケーション コンポーネントを自動的に検出し、すべての TCP 依存関係をマップし、接続を識別し、アプリが依存するリモートサード パーティシステムをマッピングします。 また、ネットワーク内の、これまでは依存関係のマッピングがされてこなかった場所 (Active Directory など) に対する依存関係もマッピングされます。
ここから始めることができるサンプルの依存関係分析 (DA) を次に示します。 DA で、プロセスの依存関係を特定して調べます。 ユーザー、サプライヤー、顧客、パートナーシップ、施設を含める必要があります。 この分析のデータを使用して、プロセスの回復要件と、依存関係をサポートする回復機能の間のギャップを特定します。
| フィールド | 説明 |
|---|---|
| プロセスの種類 | |
| ファシリテーター | |
| 完了者 | |
| 完了日 | |
| 共同作成者 |
機能の検証
ビジネス プロセスをインベントリし、他のプロセスやテクノロジとの関係をマップしたら、すべてのプロセスの検証シナリオを構築します。 ビジネス プロセス継続性計画を検証する方法を理解します。 一部のプロセスが他のプロセスよりも重要である場合があります。 これらのプロセスに優先順位を付けます。 計画の策定後は、インシデント対応および持続性対策に関して定期的に従業員のトレーニングを行うことが重要である点を忘れないでください。 インシデント後のレビューを使用して、各検証またはテストからの学習を組み込むことで回復性戦略を強化します。
インシデントの調整と通信
サービス インシデント中に、通常の通信チャネルが影響を受けたり低下したりする可能性があります。 インシデント発生時にorganization接続を維持するのに役立つ代替手段を事前に準備します。 通信チャネルを確立し、セキュリティとコンプライアンスを確保し、中断前にユーザーの使用をトレーニングすることが重要です。 危機の発生中に場当たり的な、未経験の解決方法をユーザーが模索することに比べ、既知の状態に問題があった場合は別の既知の状態に移行する方法の方がはるかに望ましいからです。
Microsoft では、各サービス チームが内部の代替通信チャネルを確立し、通常の通信チャネルが利用できない場合の調整に役立ちます。 これらの代替手段には、バックアップ テレフォニーと電話会議ソリューション、Viva Engage グループ、Teams グループ、内部サービス正常性ダッシュボード、および内部インシデント管理ソフトウェアが含まれます。
BIA と DA の間に、重要なプロセスと、それらが依存するテクノロジまたはサービスをマップします。 計画のこのフェーズ内でのコミュニケーションには特に注意を向け、代替方法を検討するようにします。 以下にいくつかの例を示します。
- メールがユーザーや関係者に情報を提供する主な方法であり、メール サービスが機能低下または利用できない場合は、Microsoft Teams、Viva Engage、別のサード パーティ サービスなどの別のサービスをバックアップとして使用します。 重要なのは、これらの代替手段を事前に確立し、どこに移動するユーザーをトレーニングすることです。 Viva Engageスレッドは、スレッドが存在することを誰も知らない場合や、ブックマークを作成したユーザーがいない場合には役に立ちません。
- 内部インシデント管理プロセスでの応答の調整が音声通信に依存している場合、危機が発生した際に使用する代替のテレフォニー ソリューションを確立します。 このソリューションは、プライマリ サービスと完全に同等である必要はありませんが、ビジネス継続性とインシデント管理チームを調整するための最小限のレベルのコラボレーションを提供する必要があります。 さらに、グローバル アドレス一覧で携帯電話番号を公開するようにユーザーに依頼すると、極端な場合にバックアップ通信の追加レイヤーが提供される可能性があります。
- インシデント中に状態の更新を提供できるカスタム サービス正常性ダッシュボード、またはその他のサイトを作成する必要がある場合があります。 事前に情報を入手する場所をユーザーにトレーニングすることで、ヘルプ デスクへの不要な呼び出しを減らし、状況が迅速かつ効率的に処理されていることをユーザー ベースに確信させることができます。 O365 Service Communications API を使用して、この情報を Microsoft 365 に結び付け、可視性をさらに高めます。
- ビジネス継続計画とStandard運用手順の場所が既知であることが重要です。 ローカル デバイスへの自動同期用に構成された SharePoint や OneDrive など、重要なドキュメントのオンラインとオフラインのコピーを維持します。 復旧に不可欠なサービス/ネットワーク オペレーション センターやその他の同様のチームの場合は、緊急時にハード コピーを使用できるようにしておくことも必要な場合があります。
外部との統合点を把握する
ビジネスモデルに関係なく、すべての企業は顧客、パートナー、ベンダーとの統合のポイントを持っています。 ビジネス バリュー サプライ チェーンは、外部エンティティとの統合の上に構築されています。 サービスの中断に対するビジネス継続性を向上させるには、統合の各ポイントを考慮して保護する必要があります。
サプライ チェーンを分析するときは、内部通信を分析するのと同じ方法で外部通信を検討してください。 顧客は、お客様の組織への唯一の連絡方法として Exchange Online サーバーに依存していますか? 稼働時間が影響を受けている際に使用する代替通信方法を確立し、そのことをサプライヤーに通知しましたか? 次のサンプルの表では、考慮点を整理する方法を提案しています。
| 外部エンティティ名 | インシデント シナリオに影響を与える | 統合されている Microsoft 365 サービス | 選択肢 |
|---|---|---|---|
vendor name |
メール フロー | Exchange Online は、Contoso と通信する唯一の方法です。 | 外部の Microsoft Teams チャネルまたはサード パーティ製の共同作業ソフトウェアを設定します。 |
service supplier name |
チャット | Microsoft Teams | サード パーティのインスタント メッセージング |
partner name |
音声 | Microsoft Teams | モバイルまたはパブリック pstn |
supplier name |
ファイル共有 | 外部共有 SharePoint サイトと OneDrive | サード パーティのファイル共有 |