了解复原能力工程
Microsoft 将复原能力定义为“业务流程或服务在遇到正常运营故障和挑战时满足客户期望的能力”。在 Microsoft Online Services 的规模中，复原能力对于维护联机服务的可用性至关重要。 我们致力于构建具有韧性的服务，因为我们深知：
- 硬件会发生故障。 假设硬盘驱动器的平均故障前时间 (MTFB) 为 100,000 小时。 对于单块硬盘，这看起来像是每 11.5 年出现一次的可管理故障。 但是，如果你有 10,000,000 块硬盘，则大约每 30 秒就会发生一次故障。 针对常见硬件组件故障的韧性是我们设计和构建联机服务的关键功能。
- 人非圣贤，孰能无过。 假设典型 IT 实施中的一个人每天在 100 台服务器的系统中执行 100 次操作。 准确度为 99%，每天仍会犯一个错误。 放大到 250,000 台服务器，那就是每天 2,500 个错误。
- 软件都会有 bug。 必须持续部署软件更新才能使服务保持最新状态。 有韧性的服务必须能够保护自己免受软件中新的和以前未发现的 bug 的侵害。
我们使用 Microsoft 的超大规模云并采用服务自动化来应对这些挑战，使我们的服务能够应对多种故障模式，以此应对这些挑战。
主动/主动服务设计
我们尽可能确保我们的服务设计和部署具有主动/主动韧性。 这意味着如果服务的一个关键组件出现故障，则可以使用相同组件来代替，而不会损失可用性。 主动/主动部署取代了较旧的主动/被动模型，在这种情况下，如果活动组件失败，被动组件需要一些时间来接管工作负荷，从而暂时中断服务可用性和数据完整性。 主动/主动服务设计相比其他部署模式的改进十分显著，并可针对多种服务故障提供韧性。
故障隔离
故障隔离通过防止一个组件中的故障导致其他组件发生故障来提高服务弹性。 故障隔离通过减少从组件故障中自动恢复所需的范围来补充主动/主动服务设计。 Microsoft 不断努力减少云服务中故障区域的大小，以防止故障蔓延并影响其他系统组件。
我们用于故障隔离的一些策略包括：
- 在服务组件内部和之间实施精细的故障控制：例如，Exchange Online 数据库可用性组将服务内故障的影响限制在特定的可用性组中。
- 服务可用性的多协议管理：例如，SharePoint Online 的文件可访问性可以缓解影响访问 Teams 中文件的事件。
- 区域化和精细系统设计：我们的服务设计将逻辑和物理服务基础结构划分为更小的单元。 这使得我们能够使用小型和大规模服务管理的灵活性，根据事件的范围对事件做出适当响应。
- 负载均衡和限制：在正常服务操作过程中，我们的服务会定期在系统组件之间对流量和数据进行随机排序。 非必要的服务端流量会受到限制，以支持邮件传递等关键流量。 这使得我们的系统能够在发生组件故障或服务事件时自动确定关键服务的优先级。
减少波及半径
与故障隔离密切相关的是事件的“爆炸半径”概念。发生事件时，爆炸半径是指该事件对我们的在线服务的影响程度。 Microsoft 不断努力减少潜在事件的波及半径。 当事件响应事后分析发现具有不可接受的波及半径的事件时，我们通过投资旨在减少未来类似事件影响的服务更新来做出响应。
持续改进
事件发生时，事件响应过程会确保每个事件都得到解决。 我们使用标准化指标来跟踪事件对服务可用性和性能的影响。 对客户具有重大影响的事件会接受事后回顾。 事后回顾生成的关键发现和缓解措施，将发布到服务运行状况仪表板，以供受影响的客户查看。
事后回顾有助于确定韧性改进方向，这些改进可能会阻止或限制未来类似问题的波及范围。 团队之间会共享从事件中学到的经验教训，因此每个团队都可以实现改进，而无需直接遇到类似事件。