ビジネス継続計画の策定
この記事では、Microsoft 365 の依存関係を考慮したビジネス継続計画の開発に関するガイダンスを提供します。 ここでは、ビジネス機能を分析し、Microsoft 365 サービスに依存するものを特定する方法をお勧めします。 この分析は、サービスに不具合が発生することを想定し、その可能性に備えるために行うものです。
大まかには、ビジネス継続性計画の策定には、評価、計画、機能の検証、および通信と調整という 4 つの側面があります。
評価
まずは、組織の事業上の機能およびそれらをサポートしているサービスとプロセスを特定する必要があります。 これには、事業影響分析の実施が含まれます。この分析では、各事業機能をそれぞれの重要度に応じてランク付けし、各機能が依存しているプロセスとサービスを特定します。 評価を開始する際に参考になるサンプルの表を下に示します。
サンプル事業影響分析 (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 では、プロセスの依存関係を特定して調べます。 ユーザー、サプライヤー、顧客、パートナーシップ、施設を含める必要があります。 この分析のデータは、プロセスの回復要件とそれをサポートする依存関係の回復機能との間の隔たりを特定するために使用されます。
| フィールド | 説明 |
|---|---|
| プロセスの種類 | |
| ファシリテーター | |
| 完了者 | |
| 完了日 | |
| 共同作成者 |
機能の検証
ビジネス プロセスのインベントリを作成し、他のプロセスやテクノロジとの関係のマッピングを行ったら、すべてのプロセスについて検証シナリオを作成する必要があります。 基本的に、ビジネス プロセス継続性計画を検証する方法を理解します。 おそらく、プロセスにより重要度が異なることが判明します。そのため、プロセスの優先順位付けを行う必要があります。 計画が確立されたら、インシデント対応と継続性対策に関する従業員の定期的なトレーニングが重要であることを忘れないでください。 各検証またはテストから得た内容を取り込んで復旧計画を強化するために、インシデント後のレビューを活用する必要があります。
インシデントの調整と通信
サービス インシデント中は、通常の通信チャネルが影響を受けたり低下したりする可能性があるため、インシデント中に組織の接続を維持するために代替手段を事前に調整する必要があります。 通信チャネルを確立し、セキュリティとコンプライアンスを検証し、中断前にユーザーの使用をトレーニングすることが重要です。 危機の発生中に場当たり的な、未経験の解決方法をユーザーが模索することに比べ、既知の状態に問題があった場合は別の既知の状態に移行する方法の方がはるかに望ましいからです。
Microsoft では、各サービス チームが、通常の通信チャネルが利用できない場合の調整に役立つ内部代替通信チャネルを確立しています。 これには、バックアップ テレフォニーと電話会議ソリューション、Viva Engage グループ、Teams グループ、内部サービス正常性ダッシュボード、および内部インシデント管理ソフトウェアが含まれます。
BIA と DA では、重要なプロセスと、それらが依存するテクノロジまたはサービスをマッピングします。 計画のこのフェーズ内でのコミュニケーションには特に注意を向け、代替方法を検討するようにします。 以下にいくつかの例を示します。
- メールがユーザーや関係者に情報を提供する主要な方法であり、メール サービスが低下または利用できない場合は、Microsoft Teams、Viva Engage、別のサード パーティサービスなどの別のサービスをバックアップとして使用できます。 重要な点は、これらを事前に確立し、どこにアクセスすればよいかについてユーザーのトレーニングを行うことです。 Viva Engage スレッドは、そのスレッドが存在することを誰も知らない場合や、ブックマークを作成したユーザーがいない場合には役に立ちません。
- 内部インシデント管理プロセスでの応答の調整が音声通信に依存している場合、危機が発生した際に使用する代替のテレフォニー ソリューションを確立します。 このソリューションは、プライマリ サービスと完全に同等である必要はありませんが、ビジネス継続性とインシデント管理チームを調整するための最小限のレベルのコラボレーションを提供する必要があります。 また、ユーザーに各自の携帯電話番号をグローバル アドレス一覧で公開することを依頼することで、極端なケースが発生した場合の代替コミュニケーションの選択肢を広げられます。
- インシデント発生時に状況の更新を提供できるよう、カスタムのサービス正常性ダッシュボードまたはそれに似た他のサイトを作成することを推奨します。 ユーザーに対して情報の入手場所に関するトレーニングを事前に行うことで、ヘルプ デスクへの不必要な呼び出しを減らし、ユーザーに自信を植え付けることができます。これにより、状況への対処が迅速かつ効率的になります。 O365 Service Communications API を使用して、この情報を Microsoft 365 に結び付け、可視性をさらに高めます。
- ビジネス継続計画と標準運用手順の場所が既知であることが重要です。 ローカル デバイスへの自動同期用に構成された SharePoint や OneDrive など、重要なドキュメントのオンラインコピーとオフライン コピーを維持することをお勧めします。 復旧に不可欠な Service/Network Operations Center やその他の同様のチームの場合は、緊急時にハード コピーを使用できるようにしておくことも必要な場合があります。
外部との統合点を把握する
ビジネスモデルに関係なく、すべての企業は顧客、パートナー、ベンダーとの統合のポイントを持っています。 ビジネス バリュー サプライ チェーンは、外部エンティティとの統合の上に構築されています。 サービスの中断に対するビジネス継続性を向上させるには、統合の各ポイントを考慮して保護する必要があります。
サプライ チェーンを分析する際は、内部通信を分析するのと同じ方法で外部通信を評価する必要があります。 顧客は、お客様の組織への唯一の連絡方法として 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 | サード パーティのファイル共有 |