ビジネス継続計画の策定

この記事では、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 グループ、内部サービス正常性ダッシュボード、および内部インシデント管理ソフトウェアが含まれます。

ビジネス影響分析と依存関係分析では、重要なプロセスと、依存するテクノロジまたはサービスをマッピングします。 計画のこのフェーズ内でのコミュニケーションには特に注意を向け、代替方法を検討するようにします。 以下にいくつかの例を示します。

• メールがユーザーや関係者に情報を提供する主な方法であり、メール サービスが機能低下または利用できない場合は、Microsoft Teams、Viva Engage、別のサード パーティ サービスなどの別のサービスをバックアップとして使用できます。 重要な点は、これらを事前に確立し、どこにアクセスすればよいかについてユーザーのトレーニングを行うことです。 Viva Engage スレッドは、スレッドが存在することを誰も知らない場合や、ブックマークを付けたユーザーがいない場合は役に立ちません。
• 内部インシデント管理プロセスでの応答の調整が音声通信に依存している場合、危機が発生した際に使用する代替のテレフォニー ソリューションを確立します。 このソリューションは、プライマリ サービスと完全に同等である必要はありませんが、ビジネス継続性とインシデント管理チームを調整するための最小限のレベルのコラボレーションを提供する必要があります。 また、ユーザーに各自の携帯電話番号をグローバル アドレス一覧で公開することを依頼することで、極端なケースが発生した場合の代替コミュニケーションの選択肢を広げられます。
• インシデント発生時に状況の更新を提供できるよう、カスタムのサービス正常性ダッシュボードまたはそれに似た他のサイトを作成することを推奨します。 ユーザーに対して情報の入手場所に関するトレーニングを事前に行うことで、ヘルプ デスクへの不必要な呼び出しを減らし、ユーザーに自信を植え付けることができます。これにより、状況への対処が迅速かつ効率的になります。 O365 Service Communications API を使用して、この情報を Microsoft 365 に結び付け、可視性をさらに高めます。
• ビジネス継続計画と標準運用手順の場所が既知であることが重要です。 SharePoint Online または OneDrive for Business でローカル デバイスへの自動同期を構成するなどして、重要ドキュメントのコピーをオンラインとオフラインの両方で維持することをお勧めします。 復旧に不可欠なサービス/ネットワーク オペレーション センターやその他の同様のチームの場合は、緊急時にハード コピーを使用できるようにしておくこともできます。

外部との統合点を把握する

ビジネスモデルに関係なく、すべての企業は顧客、パートナー、ベンダーとの統合のポイントを持っています。 ビジネス バリュー サプライ チェーンは、外部エンティティとの統合の上に構築されています。 サービスの中断に対するビジネス継続性を向上させるには、統合の各ポイントを考慮して保護する必要があります。
サプライ チェーンを分析する際は、内部通信を分析するのと同じ方法で外部通信を評価する必要があります。 顧客は、お客様の組織への唯一の連絡方法として 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	サード パーティのファイル共有