制定业务连续性计划:Microsoft 365服务的完整指南
制定业务连续性计划:Microsoft 365服务的完整指南
业务连续性计划(Business Continuity Plan,简称BCP)是企业应对服务中断、确保关键业务功能持续运行的重要保障。本文将指导你如何制定一个全面的BCP,特别关注Microsoft 365服务的依赖关系。
评估阶段
首先,你需要识别组织中的业务功能及其支持的服务和流程。这包括完成业务影响分析(Business Impact Analysis,简称BIA),对每个业务功能的关键程度进行排名,并确定其依赖的流程和服务。
业务影响评估 (BIA) 示例表
BIA 字段 | 说明 |
---|---|
BIA 类型 | 是业务流程还是技术、服务或系统? |
BIA 名称 | 服务/系统/功能/流程的名称 |
服务说明 | 服务、流程或功能的完整描述 |
企业函数 | 例如:客户服务、法律、营销、风险管理、安全、销售、信息技术、生产、制造等 |
财年 | 当前财年,定期重新评估 |
临界 | 自定义分类,例如:任务关键、重要、可延迟 |
业务部门 | 拥有此业务功能的业务部门名称 |
进程 (服务、功能) | 进程、服务或功能的名称 |
业务组高级主管 | 拥有此业务流程的业务组的高级领导的姓名和联系方式 |
该技术是否具有已建立的内部服务级别协议 (SLA) 或操作级别协议 (OLA)? | 请尽可能详细说明 |
该技术是否已建立外部SLA 或 OLA? | 请尽可能详细说明 |
该技术是否有一个已知的管理法规要求来推动特定的流程 SLA? | 如果是,请详细说明 |
与此服务关联的数据丢失或泄露是否会触发重大事件? | 如果是,请详细说明 |
服务对某些或全部关键功能和特征是否有解决方法或替代措施? | 如果是,请详细说明 |
服务是否处理、存储或传输客户数据(例如个人身份信息 (PII))? | 如果是,请详细说明 |
BIA 状态 | 自定义状态分类,例如:计划中、已开始、进行中、已完成、暂停、已过期 |
完成日期 | 完成 BIA 的日期 |
BIA 推动者 | 负责开发和维护此 BIA 的人员或团队的名称 |
BIA 批准 | 负责批准此 BIA 的执行发起人或团队的名称 |
参与者 | 可选:参与开发此 BIA 的人员及其联系方式 |
BIA 批准位置 | 指明执行批准的位置,或在此文档中附加证明 |
计划阶段
接下来,你需要跨业务流程查看存在任何级联依赖关系的位置。根据结果,你可以确定优先级并形成弹性策略和支持策略的标准操作过程。
可以使用Microsoft 服务映射来帮助你使用此映射。 Microsoft服务映射会自动发现 Windows 和 Linux 系统上的应用程序组件,并映射所有 TCP 依赖项,标识应用所依赖的连接和远程第三方系统。 它还会将依赖关系映射到传统上黑暗的网络区域,如 Active Directory。
依赖项分析示例表
字段 | 说明 |
---|---|
进程类型 | |
主持人 | |
完成者 | |
完成日期 | |
参与者 |
功能验证阶段
在对业务流程进行盘存并将关系映射到其他流程和技术后,需要为所有流程构建验证方案。基本上,弄清楚你将如何验证业务流程连续性计划。你可能会发现某些人比其他人更重要,你希望对他们设置优先级。不要忘记,在制定计划后,定期为员工提供事件响应和连续性措施培训非常重要。应通过将学习与每个验证或测试相结合,采用事后回顾的方法来增强复原策略。
事件协调和通信
在服务事件期间,正常的通信通道可能会受到影响或降级,因此应预先安排替代方案,以帮助组织在事件发生期间保持连接。至关重要的是,必须建立通信渠道,对安全性和合规性进行审核,并在发生中断之前对用户进行使用培训。无法从一个已知状态到另一个已知状态远比用户在危机中想出临时的、未知的解决方案好得多。
在Microsoft,每个服务团队都建立了内部替代通信渠道,以帮助我们在正常通信渠道不可用时进行协调。其中包括备份电话和音频会议解决方案、Viva Engage 组、Teams 组、内部服务运行状况仪表板和内部事件管理软件。
在 BIA 和 DA 期间,你将映射关键流程及其依赖的技术或服务。在计划和考虑备选方案过程中,请特别留意有关通信的注意事项。下面是一些示例。
- 如果电子邮件是通知用户和利益干系人的主要方法,并且电子邮件服务已降级或不可用,则可以使用其他服务(如 Microsoft Teams、Viva Engage 或其他第三方服务)作为备份。 关键是事先建立这些备份,并向用户培训它们的访问位置。 如果 Viva Engage 线程不存在,或者没有人将其加入书签,则 Viva Engage 线程将不起作用。
- 如果内部事件管理流程依赖于语音通信来协调响应,请建立一个备选电话服务解决方案,以便在危机过程中使用。 此解决方案不需要与主要服务完全奇偶校验,但应提供最低级别的协作来协调业务连续性和事件管理团队。 此外,要求用户在全局地址列表中发布移动电话号码,可在极端情况下提供额外层面的备份通信。
- 你可能需要创建自定义服务运行状况仪表板或其他此类站点,从而在事件发生期间提供状态更新。 培训用户预先获取信息的位置将有助于减少对帮助台的不必要呼叫,并灌输用户群体对快速高效处理情况的信心。 使用 O365 服务通信 API 将此信息绑定到 Microsoft 365 中,以获取更高级别的可见性。
- 必须知道业务连续性计划和标准操作过程的位置。 建议维护关键文档的联机和脱机副本,例如 SharePoint 或 OneDrive 配置为自动同步到本地设备。 对于服务/网络运营中心以及对恢复至关重要的其他类似团队,你可能还希望保留硬副本,以便在发生紧急情况时使用。
了解外部集成点
无论业务模式如何,每个公司都有与其客户、合作伙伴和供应商的集成点。业务价值供应链是在与外部实体集成的基础上构建的。提高服务中断的业务连续性需要考虑和保护每个集成点。
分析供应链时,应按照与分析内部通信的相同方式来考虑外部通信。客户是否依赖 Exchange Online 服务器作为唯一联系方式?你是否已建立并让你的供应商清楚正常运行时间受到影响情况下的备选通信方法?下面是一个示例表,它针对如何组织你的想法提出了建议。
外部实体名称 | 影响事件方案 | 集成的 Microsoft 365 服务 | 选择 |
---|---|---|---|
供应商名称 | 邮件流 | Exchange Online 是与 Contoso 通信的唯一方式 | 设置外部 Microsoft Teams 频道或第三方协作软件 |
服务供应商名称 | 聊天 | Microsoft Teams | 第三方即时消息 |
合作伙伴名称 | 语音 | Microsoft Teams | 移动或公共 pstn |
供应商名称 | 文件共享 | 外部共享的 SharePoint 网站和 OneDrive | 第三方文件共享 |