了解事件发生时该去哪里以及预期会发生什么
当我们谈论“事件”时，我们专门讨论 Microsoft/Azure 端的问题，这是影响服务的平台端问题。 在这些罕见但不可避免的问题中，我们的目标是通过直接从我们的工程师那里提供定期更新，尽可能地对你保持透明。 我们努力通过正确的渠道通知正确的人员，并尽可能多地分享细节。
尽管我们通常不会分享猜测或故障排除步骤的内部工作，但我们会分享我们所知道的关于事件的一切。 消息传递不会延迟（即使是详细的消息传递），具体取决于客户规模或细分市场、合作伙伴状态或支持计划，因此 Microsoft 合作伙伴组织甚至 Microsoft 帐户团队都会与他们所代表的受影响客户同时得到通知，并获得相同的更新。
在事件发生过程中
查看 Microsoft Azure 门户中的 Azure 服务运行状况，了解来自工程师的最新更新。
如果你注意到一个问题，需要了解“是我们还是 Azure”，则应首先在门户中检查 Azure 服务运行状况。 尽管应注意此“转到”位置，但如果事先配置了相关服务运行状况警报，则无需被动地搜寻信息。 在已知问题期间，将触发这些服务运行状况警报，并使用所选信道通知他们。
注意
提醒一下，请设置 Azure 服务运行状况警报，以便通过所选信道（电子邮件、短信、Webhook）获得门户通信通知
如果访问“服务运行状况”或门户本身时遇到问题，请检查公共 Azure 状态页。
如果服务问题阻碍你访问 Azure 门户中的“服务运行状况”，请使用 Azure.status.microsoft 发布问题更新。 此页面仅用于中断正常通信路径的问题，或用于罕见的普遍问题。
请务必提醒你，azure.status.microsoft 确实充当 Azure 服务运行状况的备份。 我们的大多数服务问题通信都是以定向通知的形式提供的，直接发送给受影响的订阅或租户。 这些通信通过 Azure 门户中的 Azure 服务运行状况传递，并触发已配置的任何 Azure 服务运行状况警报。 公共状态页 (azure.status.microsoft) 仅用于在三种特定情况下传达服务问题：
场景 1 - 影响广泛，涉及多个地区、区域或服务 - 服务问题会对整个区域或多个区域的多个服务产生广泛/重大的客户影响。 在这种情况下，我们会通知你，因为客户配置的复原能力（如高可用性或灾难恢复）可能不足以避免影响。
场景 2 - Azure 门户/服务运行状况不可访问 - 服务问题会妨碍你访问 Azure 门户或 Azure 服务运行状况，从而影响前面所述的标准中断通信路径。
场景 3 - 服务影响，但不确定具体谁受到影响 - 服务问题对客户有广泛/重大的影响，但我们尚无法确认哪些客户、区域或服务受到影响。 在这种情况下，我们无法发送有针对性的通信，因此我们提供了公共更新。
如果“状态”页出现问题，请在 X 上通过 @AzureSupport 检查是否有任何更新。
在 Azure 历史上，只有几次技术问题阻止在 azure.status.microsoft 上发布事件更新 - 在这些特殊情况下，我们在 @AzureSupport 通过 X 发布事件更新。 但是，无论问题如何，客户都应该随时联系 @AzureSupport，了解他们看到的潜在问题或与支持问题相关的任何问题。 @AzureSupport 团队通常在不到 5 分钟的时间内做出响应（我们对此感到非常自豪！），但请务必知道，在已知问题期间（例如，如果 Azure 服务运行状况中列出了中断），事件已经由合适的工程师处理，因此 @AzureSupport 团队除了指导客户了解所发生事情的官方工程更新之外，可能无法提供太多帮助。
如果影响/问题与事件不匹配（或者缓解后这些问题仍然存在），请联系支持人员。
这是客户了解事件期间要执行的操作（或不执行的操作）的最重要说明。 如上所述，在已知问题期间（例如，如果 Azure 服务运行状况中列出了中断），事件已经由合适的工程师处理，因此客户无需联系支持人员获取更新。 他们将通过 Azure 服务运行状况（及其 Azure 服务运行状况警报）接收定期更新，并且支持工程师无法访问比提供给受影响的客户更详细的信息。 如果客户阅读了工程部门的更新，但需要支持才能响应事件（例如，实施故障转移计划），则可以并应提出支持票证。
同样，如果他们注意到的症状似乎与问题更新中描述的症状不“一致”（例如，如果美国东部的 Azure Cache for Redis 存在已知问题，但他们在美国东部 2 看到了 Azure Cache for Redis 问题），那么这可能是不相关的，客户可以并且应该提出支持票证。 最后，如果服务问题得到解决/缓解，但客户仍然看到其服务有问题，则支持工程师可以帮助他们查看其资源是否有特殊问题，因此客户可以并应该提出支持票证。