Microsoft 365 中的数据监视和自我修复

鉴于 Microsoft 365 的规模，如果没有全面的内置监视、智能警报和快速可靠的自我修复功能，就不可能使客户数据具有复原能力并免受恶意软件的侵害。 以 Microsoft 365 的规模监视一组服务具有挑战性。 需要引入新的思维模式和方法，并需要创建新的技术集，以在互联的全球环境中运行和管理服务。 我们已从传统的数据收集和筛选监视方法转向基于数据分析的方法创建警报：获取信号并建立对数据的信心，然后使用自动化来恢复或解决问题。 此方法有助于将人类从恢复等式中解脱出来，这反过来又使操作成本更低、速度更快且不易出错。

Microsoft 365 监视的基础是组成 Data Insights 引擎的技术集合，该引擎基于 Azure、SQL Azure 和 开源流式处理数据库技术构建。 它旨在收集和聚合数据并得出结论。 目前，它每小时处理来自 100,000 多个服务器的 5 亿多个事件， (大约每天 15 TB，) 分布在许多区域的数十个数据中心，这些数字还在不断增加。

Microsoft 365 使用 外部监视，这涉及到创建综合事务来测试所有重要内容。 例如，在 Exchange 中，每个方案每五分钟以分散的方式测试一次全球每个数据库，从而几乎连续地覆盖系统中的所有内容。 从多个位置，每天执行 2.5 亿个测试事务，为服务创建可靠的基线或检测信号。

Microsoft 365 还使用 红色警报的概念，它将数据中心内所有计算机的所有监视信号缩小到可由人类管理的内容。 概念很简单：如果跨多个信号发生某种情况，则必须发生一些事情。 它不是关于在一个信号中建立置信度，而在于为每个信号提供合理的保真度，以便获得更高的准确度。 此监视系统非常强大，以至于我们没有全天候的工作人员观看我们的监视器：我们拥有的只是一个机制，如果它检测到问题，它就会唤醒，在这种情况下，它将页面相应的待命人员，或者更常见的情况，它只会继续解决问题。 开始收集信号并生成红色警报后，即可开始跨所有服务分区进行三角分析。

根据故障警报和红色警报的组合，此警报准确指示哪些组件可能有问题，并且系统将尝试通过重启邮箱服务器来自行更正问题。

除了自我修复功能（如单页还原）外，Exchange 还包括一些功能，这些功能采用监视和自我修复方法，这些功能侧重于保留最终用户体验。 这些功能包括提供内置监视和恢复操作的 托管可用性，以及 AutoReseed，后者在磁盘故障后自动还原数据库冗余。

托管可用性

托管可用性提供本机运行状况检查和恢复解决方案，通过面向恢复的操作监视和保护最终用户的体验。 托管可用性是内置监视和恢复操作与 Exchange 高可用性平台的集成。 它设计用于在问题出现后立即被系统检测到以检测并恢复。 与 Exchange 之前的外部监视解决方案和技术不同的是，托管可用性不会尝试识别或沟通问题的根本原因。 相反，它侧重于解决最终用户体验的三个关键领域的恢复方面：

• 可用性 - 用户可以访问服务吗？
• 延迟 - 用户体验如何？
• 错误 - 用户能否完成所需的操作？

托管可用性是一项内部功能，可在每个运行 Exchange 的 Microsoft 365 服务器上运行。 它每秒轮询和分析数百个运行状况度量。 如果发现错误，大多数情况下会自动修复。 但始终存在托管可用性无法自行修复的问题。 在这些情况下，托管可用性通过事件日志记录将问题上报给 Microsoft 365 支持团队。

自动种子重新设定

Exchange 服务器部署在将多个数据库及其日志流存储在同一非 RAID 磁盘上的配置中。 此配置通常称为 一组磁盘 (JBOD) ，因为没有存储冗余机制（如 RAID）用于复制磁盘上的数据。 当某个磁盘在 JBOD 环境中发生故障时，该磁盘上的数据将丢失。

鉴于 Exchange 的大小以及其中部署有数百万个磁盘驱动器的事实，在 Exchange 中经常发生磁盘驱动器故障。 事实上，每天有 100 多个失败。 当磁盘在本地企业部署中发生故障时，管理员必须手动替换失败的磁盘并还原受影响的数据。 在云部署中，大小为 Microsoft 365，让操作员 (云管理员) 手动更换磁盘既不实用也不经济可行。

自动 Reseed 或 AutoReseed 是一项功能，可替换通常由操作员驱动的操作，以响应磁盘故障、数据库损坏事件或其他需要重新设定数据库副本的设定期的问题。 AutoReseed 旨在当磁盘故障发生后通过使用系统提供的备用磁盘自动还原数据库冗余。 如果磁盘发生故障，则存储在该磁盘上的数据库副本将自动重新设定到服务器上的预配置的备用磁盘，从而还原冗余。