Google Workspace 作为 Microsoft 365 服务中断时的业务连续性方案

当 Microsoft 365 发生故障时，大家首先会问的是如何让员工恢复工作。这是一个实际的业务连续性问题，而 Google Workspace 可以提供一个切实可行的解决方案。.

对于大多数企业而言，Microsoft 365 是支撑沟通、协作以及企业正常运营的基础设施。一旦发生 Microsoft 365 服务中断，各种疑问便会接踵而至：

人们可以收发电子邮件吗？

他们能看到自己的日历吗？

领导层是否仍可访问电子邮件和日历以开展危机应对工作？

面向客户的团队还能进行对外沟通吗？

团队成员可以访问文件吗？还是必须先等待备份恢复？

随着监管规定对运营韧性和业务连续性的要求不断提高，这些问题如今比以往任何时候都更为重要。.

无论您是正在努力实现 SOC 2 可用性控制、导航 NIS2 运营韧性要求，或与诸如……等框架保持一致 NIST CSF 2.0 和 ISO 22301, 应明确评估对 Microsoft 365 的依赖程度。仅依赖微软的服务可用性，作为业务连续性策略，其合理性正日益难以站得住脚。.

这促使技术团队越来越关注热备方案，尤其是 Google Workspace。它既不是 Microsoft 365 的替代品，也不是传统的备份工具，而是一个独立的第二云环境，可在 Microsoft 365 服务中断期间确保电子邮件、日历、文件和关键通信的正常运行。.

这与采用 Microsoft 365 备份平台（例如 Veeam、Druva 或其他恢复解决方案）的做法截然不同，后者可在发生故障后帮助恢复邮箱、文件及其他数据。 尽管这些平台再好，但如果成千上万的用户需要在接下来的两小时内恢复正常使用的收件箱和日历访问权限，仅靠备份是远远不够的。.

Google Workspace 确实可以在 Microsoft 365 服务中断期间保障业务连续性，特别是在电子邮件、日历、预约以及危机沟通方面。 Microsoft 365 仍是主要平台，而 Google Workspace 则提供了一个独立的业务连续性环境。但这种跨云业务连续性模型需要正确的架构和规划：身份认证、邮件路由、同步、安全、用户访问以及故障回退，都需要在服务中断发生之前（而非发生期间）进行设计和测试。.

尽管《网络安全指令2》（NIS2）、《数据保护条例》（DORA）以及美国国家标准与技术研究院（NIST）网络安全框架等法规和框架在适用范围、术语及法律效力方面存在差异，但它们都提高了预防和管理对基本服务以及关键或重要职能造成干扰的标准。.

多拉 将“关键或重要职能”定义为其中断可能对财务业绩、服务连续性或监管义务产生的实质性影响，而 NIS2 要求将业务连续性和危机管理措施纳入网络安全风险管理。此外，诸如 NIST CSF 通过其“治理、响应和恢复”职能来处理相关结果，包括事件响应、恢复和沟通。.

即使所用的术语并不一致，实际问题依然存在：

在贵组织中，哪些服务和依赖项是关键的？

将高层监管要求转化为业务连续性规划的一种实用方法是开展一次 关键功能评估 避免对主要云服务的过度依赖。关键问题很简单：

如果该云服务不可用长达X小时，我们会触犯法律、运营、客户服务、安全或财务方面的阈值吗？

对于 Microsoft 365，该评估应包括：

• RTO 和 RPO： 服务需要多快恢复，以及可接受的数据丢失量是多少
• 爆炸半径： 哪些职能、团队、客户或流程受到影响
• 集中风险： 具体取决于服务提供商、租户、区域或身份层
• 相互依赖关系： 身份识别、密钥管理、网络访问、系统集成以及外部通信路径

若从这一角度审视 Microsoft 365，结果往往令人不安。电子邮件、身份认证、日历和文件访问通常会被证明是运营依赖项，需要制定明确的业务连续性计划，而不仅仅是备份和恢复。.

法规和标准并未规定特定的业务连续性架构或具体供应商。不过，其要求仍会直接影响该架构的设计：

• ISO 22301 需要制定明确的恢复目标、记录在案的业务连续性流程，并定期进行测试。如果潜在的业务影响足以证明其必要性，则为 Microsoft 365 部署热备方案可能是合适的选择。.
• 如果贵组织是一家金融机构，, 多拉 要求您评估信息和通信技术（ICT）的集中风险以及供应商的可替代性。此外，还要求针对支持关键或重要功能的ICT服务制定有据可查的退出策略。根据风险评估结果，这可能支持采用替代供应商或多供应商设计，但DORA并未强制要求采用任何特定的架构。.
• NIS2 将相同的逻辑扩展到更广泛的必要且重要的实体中，并在其网络安全风险管理措施中明确纳入业务连续性、灾难恢复、危机管理以及供应链安全。这使得对主要云服务和服务的依赖成为该组织风险评估中的重要考量因素。.
• 在美国，的“治理”、“响应”和“恢复”职能 NIST CSF 2.0 这要求制定经过验证的恢复计划并加强供应链风险管理，从而引发了同样的问题：如果关键供应商出现故障，关键职能能否继续运转？

架构层面的问题在于，当主服务提供商不可用时，如何确保关键功能能够继续运行。 如果 Microsoft 365 服务中断会导致这些功能受阻，则该组织可能需要一个已经配置完毕、可访问且经过测试的备用环境。这一风险往往比乍看之下更为严重，因为 Microsoft 365 并非仅依赖于单一系统，而是由多个相互关联的系统构成的。.

Microsoft 365 整合了以下四项内容，而这四项内容中的任何一项，单独来看都足以成为制定业务连续性计划的理由：

• 沟通 (Exchange / Teams)。实际上，邮件转发或聊天功能中断会导致业务停摆，即使从技术上讲所有文件都安然无恙。.
• 日历 (Exchange / Teams)。日程安排和会议访问方面的问题与邮件类似，导致内部协调不力，甚至错过了外部会议，尽管从技术上讲并没有什么内容"丢失"。"
• 证件 (SharePoint / OneDrive)。文件必须始终可访问，而不仅仅是可恢复。.
• 身份 (Entra ID / Azure AD)。如果身份验证层出现故障，那么其他功能是否正常运行就无关紧要了：没有人能够登录任何系统，包括依赖同一身份提供商的第三方应用。.

目前阶段一个令人不安的发现是，标准备份软件通常只能保护第三项内容，而且需要经过长达24至48小时的恢复窗口期才能完成。在此期间，用户实际上没有其他地方可以继续工作。.

对此，最先想到的解决方案可能是创建一个辅助的 Microsoft 租户。遗憾的是，这一方案经不起推敲，因为一旦发生服务中断，即使这两个租户部署在不同的 Microsoft 365 或 Azure 区域中，也可能导致它们同时瘫痪。 区域托管并不意味着独立的故障域，因为 Entra ID 和核心 Microsoft 365 服务在底层仍共享全球基础设施。.

第二个租户虽然在纸面上满足了"我们有备用租户"这一要求，但并不能提供足够的独立性。.

这正是促使人们转向独立超大规模云服务商的原因。并非因为 Google Workspace 本身更可靠，而是因为它提供了一套在运营上相互独立的基础设施和身份认证体系。这种分离有助于应对 DORA 和 NIS2 中所反映的信息通信技术（ICT）集中风险及业务连续性问题。.