Microsoft Azure 事件就绪情况 - 统一

  • 项目

声明 Azure 事件后，我们会（在 Azure 门户内）通过 Azure 服务运行状况中的“服务问题”边栏选项卡将更新传达给受影响的订阅或租户。

在事件之前

建议准备好以下步骤，并帮助保护组织：

获取通知并随时了解影响 Azure 服务的事件

  1. 熟悉 Azure 门户中的 Azure 服务运行状况 - 出现问题时的“转到”位置。

  2. 配置服务运行状况警报警报，以通过电子邮件、短信、Webhook 等方式在订阅级别按服务和/或按区域通知你存在的任何问题。

    • 服务问题通知类型会提醒组织服务受到服务事件的影响。

    • 安全通报通知类型会提醒组织服务受到安全事件或隐私事件的影响。

    以下是基本警报配置建议：

    • 对于“服务问题、计划维护和运行状况咨询”类型：

      • 关键工作负载 – 为用于支持关键工作负载的订阅和服务设置警报。
      • 为 Azure Stack 中的基础服务设置警报：
        • “网络基础结构”服务 – 在 Azure Stack 中，从 IaaS 到 SaaS 的所有类型工作负载和应用程序都依赖的基础层。
        • “Microsoft Azure 门户”服务 – 用于管理 Azure 资源的基础服务。 多功能性使其成为一种“包罗万象”的服务，涵盖各种场景，影响将在该服务下交流的摘要体验。

    • 对于安全通报类型：

      • 所有 Azure 订阅和服务 – 通常恶意参与者针对较少使用的资源，因此这种类型的警报必须涵盖所有 Azure 资源

    此外，Azure Monitor 基线警报解决方案提供了全面的指导和代码，用于通过 Azure 环境中的策略和计划实现平台警报和服务运行状况警报的基线，并提供自动或手动部署的选项。

  3. 确保以下角色具有正确的联系信息，并定期查看以保持最新状态。 有关详细信息，请查看随时了解 Azure 安全问题 - Azure 服务运行状况 | Microsoft Learn）

    • 订阅管理员和订阅所有者 - 将用于（通过 Azure 门户和/或电子邮件，具体取决于通信要求）接收通知的联系人，以确定影响订阅级别的安全问题。

    • 租户全局管理员和技术联系人 - 将用于（通过 Azure 门户和/或电子邮件，具体取决于通信要求）接收通知的联系人，以确定影响租户级别的安全问题。

    • 安全管理员 – 可以查看和更改安全策略、应用建议以及查看和消除警报。

  4. 请考虑使用运行状况警报或计划事件来随时了解特定于资源的问题，以便用户和系统能够了解特定于资源的问题和即将发生的维护事件。

要了解 Azure 的通信原则，请查看推进中断体验 - 自动化、通信和透明度 | Azure 博客和更新 | Microsoft Azure。

提高安全性和复原能力，尽可能避免或最大程度减少事件的影响

  1. 查看并实施用于保护数据、应用程序和其他资产的操作安全最佳做法，尤其是以下方面：

    • 强制执行多重身份验证，以减轻对风险的担忧。

    • 为高风险用户实现警报。 配置条件访问，确保在环境中存在“风险用户”时收到通知。

    • 控制订阅在其与目录间的移动。 出于治理目的，全局管理员可以允许或禁止目录用户更改其组织中未知的目录。 这可确保组织完全了解组织目录下使用的订阅，并防止可能转到未知目录的订阅移动。

  2. 使用 Azure Well-Architected Framework (WAF) 和审查优化关键工作负载可靠性、安全性等。 另外，请考虑这些操作来对 WAF 中的工作进行补充。

    • 利用集成到“Azure 顾问”边栏选项卡下 Azure 门户的可靠性工作簿来查看应用程序的可靠性状况、评估风险和计划改进。

    • 跨区域扩展工作负载/部署，实现业务连续性和灾难恢复 (BCDR)。 使用已发布的 Azure 区域对的完整列表。

    • 跨可用性区域扩展区域中的工作负载/部署。

    • 考虑对 Azure 中的 VM 进行隔离 - Azure 虚拟机 |适用于业务关键型工作负载的 Microsoft Learn。

    • 考虑使用维护配置，以便能够控制和管理许多 Azure 虚拟机的更新

    • 使用 Azure Chaos Studio 评估 Azure 应用的复原能力。 使 Azure 应用经历受控故障（真实或模拟），以观察应用程序复原能力以及对网络延迟、存储中断、即将过期的机密和数据中心中断等中断的响应。

    • 利用集成到 Azure Advisor 边栏选项卡下 Azure 门户的服务停用工作簿，作为服务停用的单一集中式资源级别视图。 它可帮助你评估影响、评估选项以及计划从停用的服务和功能迁移。

请关注 Azure 的推进可靠性博客，以随时了解 Azure 在持续复原方面所做的工作。

在事件期间

当关键订阅受到事件影响时，重要的是要知道在何处以及如何查找有关此事件的通信内容：

  1. 查看 Azure 门户中的 Azure 服务运行状况警报，了解工程师的最新更新。

    • 请务必注意，在“事件之前”部分中提到的特定角色联系人（即订阅管理员/所有者、技术/隐私联系人、租户管理员）也可能获得安全或隐私事件的电子邮件通知。

  2. 如果访问门户时遇到问题，请检查公共 Azure 状态页 azure.status.microsoft 作为备份。

  3. 如果“状态”页出现问题，请通过 X（前 Twitter）上的 @AzureSupport 检查是否有任何更新。

为什么使用“服务运行状况”而不是公共“状态”页？

许多客户在最初发现潜在问题时就会查看我们公开访问的状态页面（如 azure.status.microsoft），以便了解云服务是否存在已知问题。 这些页面仅显示满足特定条件的普遍问题，而不是影响较少客户的较小事件。

（Azure 门户中）的 Azure 服务运行状况知道你管理哪些订阅和租户，因此它可以更准确地查看影响停机的任何已知问题。 它还允许配置警报，以便可以自动收到通知。

何时可以打开支持案例？

如果已通过服务运行状况传达服务事件，则将在此处提供所有最新信息，并且无需提出支持请求。 如果认为自己受到服务事件的影响，但看不到“服务运行状况”页中显示的问题，请提出支持请求。

如果收到的安全问题材料未涵盖问题，请提出引用跟踪 ID 的支持请求。

事件发生后

  1. 从 Azure 服务运行状况的“运行状况历史记录”窗格或通过客户配置的服务运行状况警报阅读事后回顾 (PIR)，以了解我们学到的内容。

  2. 对于符合我们公开的状态页条件的重大事件，请加入 Azure 事件回顾实时流以获取任何问题的解答，或观看录制内容。

  3. 如果你认为你可能有资格获得 SLA 额度，请创建一个支持请求，问题类型为“退款请求”，并包括事件跟踪 ID。