"服务中断之类的服务事故是科技行业不可避免的不幸。当然，我们正在不断提高微软Azure云平台的可靠性。我们满足并超过了我们为绝大多数客户制定的服务级别协议（SLA），并继续投资于不断发展的工具和培训，使您能够轻松自信地设计和操作关键任务系统。尽管作出了这些努力，但我们承认一个不幸的现实，即鉴于我们的业务规模和变革速度，我们永远无法完全避免停机。在这段时间里，我们努力做到尽可能的公开和透明，以确保所有受影响的客户和合作伙伴都了解正在发生的事情。作为我们推进可靠性博客系列的一部分，我请负责我们大修通信过程的主要项目经理Sami Kubba概述我们为继续改善这种体验而进行的投资。"—Azure首席技术官Mark Russinovich 在云计算行业，我们致力于为客户提供大规模的最新技术，确保客户和我们的平台安全，并确保我们的客户体验始终是最佳的。为了实现这一点，Azure需要进行大量的更改，在极少数情况下，正是这种变化会给我们的客户带来意想不到的影响。正如前面在这一系列博客文章中提到的，我们非常认真地对待变革，并确保我们有一个系统和分阶段的方法来尽可能仔细地实施变革。我们继续在复杂的方式中识别固有的（有时是细微的）缺陷，这些缺陷是我们的体系结构设计、操作过程、硬件问题、软件缺陷和人为因素导致服务事故（也称为停机）的原因。我们行业的现实是，变革带来的影响是一个内在的问题。当我们考虑中断通信时，我们往往不会将我们的竞争对手看作是其他云提供商，而是认为我们的竞争对手是内部环境。内部部署更改窗口由管理员控制。他们选择最好的时间来调用任何更改，管理和监视风险，并在观察到失败时将其回滚。类似地，当在内部环境中发生故障时，客户和用户会觉得他们更加"了解"。领导层会立即充分了解故障，并获得故障排除的支持，并希望他们的团队或合作伙伴公司能够提供完整的事故后报告（PIR）-以前称为根本原因分析（RCA）-一旦问题得到理解。尽管我们的数据分析支持这样一个假设，即在云中缓解事件的时间比在内部要快，但是当客户了解问题和如何应对时，云中断会给他们带来更大的压力。介绍我们的沟通原则在云中断期间，一些客户曾报告说，他们感觉好像没有及时得到通知，或者他们错过了必要的更新，因此对发生的事情和正在采取的措施缺乏全面的了解，以防止将来出现问题。基于这些认识，我们现在由五大支柱运营，这些支柱指导我们的通信战略，所有这些都影响了我们在Azure门户中的Azure服务健康体验，包括：速度粒度可发现性对等透明度速度我们必须尽快通知受影响的客户。这是我们在大修通信方面的主要目标。我们的目标是在停机后15分钟内通知所有受影响的Azure订阅。我们知道单靠人类是无法做到这一点的。当一个工程师开始调查监控警报以确认影响时（更不用说聘请合适的工程师来减轻影响了，在一系列复杂的互联关系中，包括第三方依赖关系）已经过了太多时间。任何通信延迟都会让客户问："是我还是Azure？"然后，客户可以花费不必要的时间来排除自己的环境故障。相反，如果我们决定谨慎行事，并在每次怀疑潜在的客户影响时进行沟通，我们的客户可能会收到太多的误报。更重要的是，如果他们自己的环境有问题，他们可以很容易地将这些无关的问题归因于平台发出的错误警报。重要的是，我们要进行投资，使我们的沟通既快速又准确。上个月，我们概述了我们在利用人工智能提升Azure服务质量方面的持续投资：AIOps。这包括努力改进云中断的自动检测、参与和缓解。这个更广泛的AIOps计划的元素已经在生产中被用来通知客户可能会影响他们的资源的停机。这些自动通知占上季度我们停机通信的一半以上。对于许多Azure服务，自动通知将在不到10分钟内通过服务运行状况发送到受影响的客户，以便在Azure门户中访问，或触发已配置的服务运行状况警报，更多信息请参阅下文。随着我们在这一领域的投资已经改善了客户体验，我们将继续扩大在影响开始时间后不到15分钟内通知客户的场景，所有这些都不需要人工来确认客户的影响。我们还处于扩展基于人工智能操作的早期阶段，以自动识别相关的受影响服务，并在缓解后尽快发送解决方案通信（针对支持的场景）。粒度我们知道，当停机造成影响时，客户需要确切了解他们的哪些资源受到影响。获取特定资源的健康状况的关键构建块之一是资源健康信号。资源运行状况信号将检查资源（如虚拟机（VM）、SQL数据库或存储帐户）是否处于正常状态。客户还可以创建资源运行状况警报，利用Azure Monitor，让正确的人知道特定资源是否有问题，而不管它是否是平台范围的问题。需要注意的是：由于资源不正常（例如，如果VM从来宾系统中重新启动），则会触发资源运行状况警报，而这与平台事件（如停机）不一定相关。客户可以查看按资源类型排列的相关资源运行状况检查。我们在这项技术的基础上，增加并关联每一个进入不健康状态的客户资源与平台中断之间的关联，所有这些都在服务健康范围内。我们还在研究如何将受影响的资源包括在我们的通信有效负载中，这样客户就不必登录到Service Health来了解受影响的资源当然，每个人都应该能够以编程方式使用这些资源。所有这些都将使拥有大量资源的客户能够更准确地知道他们的哪些服务因停机而受到影响，而无需对他们进行调查。更重要的是，客户可以使用与逻辑应用程序和Azure功能的本机集成来构建警报并触发对这些资源运行状况警报的响应。可发现性尽管我们支持停机通信的"推送"和"拉取"方法，但我们鼓励客户配置相关警报，以便将正确的信息自动推送到正确的人员和系统。我们的客户和合作伙伴不必去搜索，看看他们关心的资源是否受到停机的影响，他们应该能够使用我们发送的通知（以他们选择的介质）并根据需要对它们作出反应。尽管如此，我们经常发现客户访问Azure状态页来确定Azure上服务的运行状况。在引入经过身份验证的in-portal服务运行状况体验之前，状态页是发现已知平台问题的唯一方法。现在，这个公共状态页只用于传达大范围的停机（例如，影响多个地区和/或多个服务），因此，寻找可能影响他们的问题的客户在这里看不到全部情况。由于我们尽可能安全地推出平台更改，大多数问题（如停机）只会影响客户订阅的"爆炸半径"。对于这些占我们95%以上事件的事件，我们通过"服务健康"在门户中直接与受影响的客户进行通信。我们最近还将"新兴问题"功能整合到服务健康中。这意味着，如果我们在"公共状态"页面上发生了事件，而我们还没有确定受影响的客户并与之通信，那么用户可以通过"服务运行状况"在门户中看到相同的信息，从而无需访问状态页即可接收所有相关信息。我们鼓励所有Azure用户将服务运行状况作为服务事件相关信息的"一站式服务"，以便他们能够看到影响他们的问题，了解哪些订阅和资源受到影响，并避免进行错误关联的风险，例如当事件发布在状态页上时，但是不会影响他们。最重要的是，由于我们讨论的是可发现性原则，因此客户可以从服务运行状况内部创建服务运行状况警报，这是利用与Azure Monitor集成的推送通知。通过这种方式，客户和合作伙伴可以根据谁需要接收通知以及如何最好地通知他们来配置相关通知，包括通过电子邮件、SMS、LogicApp和/或通过可以集成到服务管理工具（如ServiceNow、PagerDuty或Ops Genie）的webhook。要开始使用简单的警报，请考虑路由all not