TL;DR – 执行摘要
"电子邮件业务连续性"对不同的人来说有着不同的含义。 从历史上看，这并不是大多数组织会为此辗转难眠的问题。如果几年前你问一位 Exchange 或 Microsoft 365 管理员，他们会告诉你电子邮件中断的问题通常会自行解决，而他们的说法确实没错。微软的基础设施确实很出色，SMTP 会将邮件暂存队列中，而且大多数中断都只是短暂的。.
这已不再是全部情况。即使停电时间不长，问题也不再仅仅是：
“电子邮件最终会到来吗？”
相反，它变成了：
“如果没有电子邮件，组织还能继续运作吗？”
Microsoft 365 的任何服务中断都会导致生产力下降、沟通延迟以及错失商业机会，而在大型组织中，这种影响尤为明显。.
此外，诸如 NIS2, 多拉和 SOC 2 正在强化这一向业务连续性转变的趋势。此类框架是更广泛监管趋势的一部分，该趋势推动组织不仅要进行备份和恢复，还要在系统故障、网络安全事件和服务中断期间维持运营能力。.
想直接了解 Google Workspace 与 Microsoft 365 并行运行如何保障业务连续性吗？
探索e Google Workspace for Business Continuity 由 Connecting Software 提供支持，这是使 Google Business Continuity Plus SKU 能够正常运行的技术层。.
备份可保护数据。电子邮件业务连续性有助于保障运营韧性。.
当您考虑微软 365 备份方案时，通常会关注数据恢复问题 之后 一起事件。.
另一方面，电子邮件业务连续性解决方案旨在确保通信、日历和协作功能正常运行 在……期间 该事件。.
在以下情况下，这种区别很重要：
- Microsoft 365 服务中断，,
- 租户被锁在门外，,
- 勒索软件事件，,
- 身份识别失败，,
- 或网络攻击。.
真正的问题是：
当主环境不可用时，用户如何继续进行操作？
正是在这里，任何关于业务连续性计划（BCP）和灾难恢复（DR）的讨论最终都会涉及的两项指标便派上了用场： RTO 和 RPO.
在传统的备份讨论中，RTO通常指恢复受影响系统或数据所需的时间，而RPO则反映了恢复点的时效性（换言之，即可能丢失了多少近期数据）。.
在关于业务连续性的讨论中，通常会在业务职能层面采用相同的指标：RTO 关注组织在用户恢复通信前能容忍多长时间的中断，而 RPO 则关注备用通信环境需要保持多高的实时性。.
这一区别对于NIS2、DORA、SOC 2以及类似的韧性与合规性讨论至关重要，因为关键在于业务功能能否在中断期间继续运行。.
微软 365 电子邮件业务连续性方案对比
一旦需求转变为 “在混乱期间保持人们之间的沟通，” 对于IT领域而言，架构方面的问题变得更加引人入胜。.
仅提供轻量级的应急邮箱服务是否足够？是否需要考虑不同地区的情况？是否应该使用我们自己的本地基础设施？
为了达到业务实际所需的连续性水平，需要考虑多种方法和权衡取舍。下表对比了主要方法，我们将在下文中进行更详细的探讨。.
| 方法 | 主要思想 | 工具和供应商示例 | 优势 | 常见问题 |
|---|---|---|---|---|
| 基于云的业务连续性服务 | 由第三方托管的应急业务连续性平台 | Mimecast、Retarus、趋势科技 | 快速部署 降低运营成本 |
紧急网络邮箱之外的连续性有限 |
| 第二个 Microsoft 365 租户 | 已为故障转移准备好一个独立的 Microsoft 365 环境 | 微软 365 | 熟悉的微软生态系统 云原生架构 |
对单一供应商生态系统的依赖、集中度风险 |
| Exchange 本地服务器 | 与 Microsoft 365 同步的独立 Exchange 环境 | 微软，CB Exchange Server Sync | 运营独立性与控制权 对最终用户而言熟悉的微软生态系统 |
额外的基础设施和维护 |
| Google Workspace 作为热备系统 | 与 Microsoft 365 同步的独立 Google Workspace 环境 | Google Workspace 业务连续性，Google Workspace 的 CB Exchange Server Sync | 跨云独立性 可扩展至 SharePoint/Google Drive |
不同的用户体验、身份和映射 |
选择哪种模式取决于组织的运营风险状况、合规义务以及对系统停机时间的容忍度。下面让我们更详细地探讨每种选项。.
选项 1：基于云的电子邮件业务连续性服务
这是传统方法之一。Mimecast、Retarus 和 Trend Micro 等供应商提供基于云的业务连续性平台，可提供紧急邮箱访问、邮件路由和临时通信服务。.
其优点是部署迅速且运营成本较低。.
然而，企业团队常常质疑，除了临时访问网络邮件外，这些平台究竟能提供多少真正的业务连续性。用户是否还能协调日历、使用共享邮箱，并在事件结束后顺利恢复到 Microsoft 365？
选项 2：辅助 Microsoft 365 租户
一些组织会使用一个用于故障转移的备用 Microsoft 365 租户（有时位于不同的区域），以降低因区域性服务中断而带来的风险。.
这可以提高系统韧性，特别是当辅助租户在设计时具备独立的管理、路由、访问策略和恢复流程时。不过，跨区域部署并不能消除对微软云生态系统的整体依赖。.
还有一个更微妙的问题：如果二级租户通过与生产环境相同的身份提供商进行身份验证（通常是同一个 Entra ID 租户），那么基于身份的事件或服务中断可能会同时影响这两个环境。.
方案 3：与 Microsoft 365 同步的本地部署 Exchange 服务器
第三种方法是维护一个与 Microsoft 365 保持同步的独立 Exchange 服务器环境。.
一个例子是使用与 Microsoft 365 同步的本地 Exchange 服务器。.
在此模型中：
- Microsoft 365 仍是主要的运营平台，,
- Exchange 服务器是一个独立的业务连续性环境，,
- 通过将 BCP 的 CB Exchange Server Sync 设置为 Connecting Software，可确保二者之间保持同步。.
同步可能包括：
- 邮箱，,
- 日历，,
- 联系人，,
- 公共文件夹，,
- 分发组，,
- 以及GAL同步。.
由于该环境在本地运行并拥有自己的 Active Directory，因此无需与 Microsoft 365 租户共享身份平面。 这与方案 2 存在一个重要的区别：针对云租户的基于身份的攻击不会自动波及本地 Exchange 环境，这一点对于上述"身份验证失败"和"租户锁定"场景具有直接影响。.
在本地部署也意味着，如果贵组织需要在物理隔离网络中使用此类解决方案，这是最合适的选择。本地部署版本可与数据二极管配合使用，以实现该场景。.
为什么有些组织更倾向于采用这种架构
对于对运营韧性要求更高的组织而言，这种方法可以提供：
- 在运营上独立于 Microsoft 365，,
- 熟悉的 Outlook 和日历连续性，,
- 对基础设施和故障转移拥有更大的控制权，,
- 对受控或隔离环境的支持，,
- 与生产租户的身份独立性，,
- 并降低了云浓度的风险。.
同样依赖 SharePoint 及文档协作的组织，还可以通过 Connecting Software 提供的“Secure Sync for SharePoint”功能实施文档同步策略，从而在独立或隔离的环境中实现安全的 SharePoint 同步。.
方案 4：将 Google Workspace 用作热备
第四种方法遵循与方案 3 相同的逻辑，但更换了备用平台：不再使用本地部署的 Exchange Server，而是将 Google Workspace 作为独立环境，并通过……与 Microsoft 365 保持持续同步。 .
这为组织提供了一种跨云故障转移方案，完全不依赖于微软生态系统。这对缓解集中风险的担忧具有重要意义，也深受那些已将部分业务运行在 Google Workspace 上的组织的欢迎。即使对于尚未采用 Google Workspace 的组织，用户通常也通过个人使用经验对 Google Workspace 较为熟悉，这在故障转移过程中会非常有帮助。.
我们将在后续文章中详细探讨这一架构、其身份模型以及其中的具体权衡。.
了解如何通过 Google Workspace 实现热备，以确保业务连续性（作者：Connecting Software）
故障转移：取消恢复窗口
传统的备份与恢复方法意味着，一旦发生故障，必须有人先执行恢复操作，其他人才能重新开始工作。.
这存在两个问题：一是需要人工干预，二是恢复所需的时间与需要恢复的数据量成正比。对于大型租户而言，恢复时间目标（RTO）以天为单位的情况并不少见。.
基于云的电子邮件业务连续性服务虽然可以作为这一问题的权宜之计，但其功能有限。.
同步备用环境省去了这一步。由于您拥有邮件箱、日历以及最终文档的持续更新副本，用户只需被引导至该环境即可继续工作。这是一种无需恢复窗口的故障转移方案。该环境始终处于就地且最新状态，因此从 RTO 计算中消除了恢复窗口。.
您需要权衡这一成本与用户无法使用电子邮件、日历及其他邮箱内容所带来的成本——包括生产力损失、交易未能达成以及（如适用）合规成本。.
故障回退：避免手动对账
故障转移只是整个过程的一半。在某个时刻，主环境将恢复在线，用户需要迁回主环境。这就是故障回退阶段，此时真正的关键在于：如何处理在备用环境中发送和接收的邮件、日历更改以及文档编辑操作，既要确保数据不丢失，又要避免产生重复数据。.
新的电子邮件、日历变更和已编辑的文档是否需要手动同步回生产环境？这绝非任何人乐意做的工作，因为这正是容易引发错误、版本混淆和延误的那类手动操作。.
借助双向同步，这种数据核对会自动进行：一旦主环境恢复，中断期间所做的更改将无需 IT 部门干预即可回传至 Microsoft 365。 唯一存在风险的数据是最近一次同步轮询间隔内（即两次同步之间的时间间隔）所发生的变化。如果该间隔为五分钟，则实际的恢复点目标（RPO）大约相当于五分钟内的变更量，而非整个中断期间的全部数据。您可以根据轮询间隔来安排故障回退的时间，从而将 RPO 降至零
值得注意的是，轮询间隔存在权衡：缩短间隔会降低RPO，但；延长间隔则会减少开销，但会扩大潜在的数据丢失时间窗口。.
并不存在唯一“正确”的电子邮件架构。.
正确的解决方案取决于：
- 对 Microsoft 365 的运营依赖，,
- 可接受的停机时间，,
- 监管要求，,
- 内部IT能力，,
- 以及运营韧性目标。.
对于需求适中的组织而言，基于云的业务连续性服务或许能完全满足其需求。.
受《NIS2》或《DORA》规范约束，或面临严格韧性要求的组织，可能需要更强的运营独立性和故障转移能力。.
最后的思考
Microsoft 365 提供了出色的可用性。.
但仅靠可用性并不能保证运营韧性。.
各组织越来越认识到，电子邮件服务的连续性、日历访问以及协作的连续性，对于在业务中断期间维持运营至关重要。.
因为在真正发生停电时，最重要的问题并不是：
“我们稍后再补上好吗？”
它是：
"我们还能继续运营吗？"
了解如何通过 Google Workspace 实现热备，以确保业务连续性（作者：Connecting Software）
关于作者
作者 Ana Neto, 技术顾问 于 Connecting Software。
"自 1997 年以来，我一直是一名软件工程师，最近开始喜欢写作和公开演讲。您对本文有任何问题或评论吗？欢迎在下方留言！"
