如何为意外做好准备（在事件发生前）
为了确保做好准备并最大限度地减少事件的影响，必须遵循本单元中概述的主动建议。 这些操作将帮助你了解我们的事件通信过程、查找相关信息并配置通知以及时接收更新。 此外，评估应用程序的复原能力并实施建议措施将有助于创建更可靠的工作负载，从而减少事件的潜在影响。 最后，查看和实施安全最佳做法将强化环境并降低风险。
若要保持知情、缓解影响和保护投资，建议采取以下五项操作：
操作 #1：熟悉 Microsoft Azure 门户中的 Azure 服务运行状况
与公共 azure.status.microsoft 页面不同（其仅提供有关广泛中断的一般状态信息），Azure 服务运行状况提供了针对特定资源定制的个性化详细信息。 它可帮助你预测和准备计划内维护和可能影响资源可用性的其他更改。 可以参与服务事件并管理操作，以保持受影响应用程序的业务连续性。 它提供对 Azure 服务级别的平台漏洞、安全事件和隐私违反的重要见解，能够及时采取行动来保护 Azure 工作负载。
现在，让我们探索 Azure 服务运行状况中提供的一些关键功能，以增强事件准备：
“资源运行状况”窗格（涵盖的新体验）
Azure 资源运行状况位于 Microsoft Azure 门户的“服务运行状况”边栏选项卡中，可帮助诊断和解决影响 Azure 资源的服务问题。 资源（如虚拟机、Web 应用或 SQL 数据库）根据来自不同 Azure 服务的信号评估其运行状况。 如果资源标识为不正常，则 Azure 资源运行状况会进行详细分析以确定问题的根本原因。 它还提供有关 Microsoft 操作的信息，以解决与事件相关的问题，并建议可以采取的步骤来解决该问题。
“服务问题”窗格（涵盖的新体验）
“服务问题”窗格显示可能影响资源的持续服务事件。 它使你能够跟踪问题何时开始，并确定受影响的服务和区域。 通过查看最新更新，可以深入了解 Azure 为解决该事件所做的努力。
“服务问题”窗格的主要功能：
实时见解：服务问题仪表板提供对影响订阅和租户的 Azure 服务事件的实时可见性。 如果你是租户管理员，则可以看到与订阅和租户相关的活动事件或公告。
资源影响评估：“事件详细信息”部分中的“受影响的资源”选项卡显示哪些资源已确认或可能受到影响。 单击资源即可直接访问“资源运行状况”窗格。
链接和可下载说明：为要在问题管理系统中使用的问题生成链接。 还可以下载 PDF，有时可下载 CSV 文件，以便与无权访问 Microsoft Azure 门户的利益干系人共享全面的说明。 此外，可以请求发布事件评审 (PIR) 来查找任何影响资源的问题，以前称为根本原因分析 (RCA)。
“安全公告”窗格
“安全公告”窗格侧重于影响订阅和租户运行状况的紧急安全相关信息。 它提供平台漏洞、安全事件和隐私违反的见解。
“安全公告”窗格的主要功能：
实时安全见解：立即了解与订阅和租户相关的 Azure 安全事件。
资源影响评估：“事件详细信息”部分中的“受影响的资源”选项卡突出显示确认受影响的资源。
获得以下角色授权的用户可以查看安全事件影响的资源的信息：
查看订阅级别资源 查看租户级别资源 订阅所有者 安全管理员/安全读取者 订阅管理员 全局管理员/租户管理员 Azure 服务运行状况安全读者 Azure 服务运行状况隐私读者 此外，还可以下载解释性 PDF 文档，以便与无权直接访问 Microsoft Azure 门户的利益干系人共享。
以下示例显示了一个安全事件以及包含来自订阅和租户范围的受影响资源。
除了熟悉 Azure 服务运行状况之外，另一个关键步骤是设置 Azure 服务运行状况警报，这将确保及时通知并让你了解可能影响工作负载的事件和重要信息。 下一部分将详细介绍本主题。
操作 #2：设置 Azure 服务运行状况警报以随时了解情况
配置服务运行状况警报通知对于主动事件管理至关重要，也是最重要的行动号召。 通过 Azure 服务运行状况警报，你可以通过各种通道（如电子邮件、短信、Webhook 等）及时接收通知。 这些警报提供有关服务事件、计划内维护活动、安全事件和其他可能影响工作负载的关键信息的更新。
可以从 Microsoft Azure 门户的“服务运行状况”边栏选项卡中的任何“活动事件”窗格配置服务运行状况警报，方法是单击“服务运行状况”窗格中的“运行状况警报”，或者利用 Azure Resource Graph。
在这里，可以找到 Azure 服务运行状况的 Azure Resource Graph 示例查询。
Azure 服务运行状况跟踪可能影响资源的不同类型的运行状况事件，包括服务问题、计划内维护、运行状况公告和安全公告。 配置服务运行状况警报时，你可以灵活地选择发送这些警报的方式和对象。 可以根据服务运行状况通知、受影响的订阅、服务和区域类自定义警报。
Azure 服务运行状况通知类
| Azure 服务运行状况事件类型 | 说明 |
|---|---|
| 服务问题 | Azure 服务中目前影响你的问题（也称为服务事件）。 |
| 计划内维护 | 即将进行的维护，将来可能会影响服务的可用性。 |
| 运行状况公告 | Azure 服务中需要注意的更改。 示例包括何时需要执行操作、何时弃用 Azure 功能、升级要求或是否超出使用配额。 |
| 安全公告 | 处理订阅和租户级别的平台漏洞和安全与隐私违反（也称为安全和/或隐私事件）的安全相关通知。 |
我们知道，当存在影响服务的问题时，你需要收到通知，服务运行状况警报可以让你选择如何以及向谁发送这些警报。 可以根据服务运行状况通知类、受影响的订阅、受影响的服务以及/或者受影响的区域来配置警报。 可以设置警报以触发电子邮件、短信、逻辑应用、函数等。
触发警报时，可以定义使用操作组执行的操作。 操作组是通知首选项的集合，用于确定如何以及向谁发送警报。
可用通知类型的完整列表
| 通知类型 | 描述 | 字段 |
|---|---|---|
| 向 Azure 资源管理器角色发送电子邮件 | 根据订阅成员的角色向其发送电子邮件。 通知电子邮件仅发送给为 Microsoft Entra 用户配置的主电子邮件地址。 电子邮件仅发送到所选角色的 Microsoft Entra 用户成员，而不是发送给 Microsoft Entra 组或服务主体。 |
输入为 Microsoft Entra 用户配置的主电子邮件地址。 请参阅电子邮件。 |
| 电子邮件 | 确保正确配置电子邮件筛选和任何恶意软件/垃圾邮件防护服务。 电子邮件从以下电子邮件地址发送： - azure-noreply@microsoft.com - azureemail-noreply@microsoft.com - alerts-noreply@mail.windowsazure.com |
输入应在其中发送通知的电子邮件。 |
| SMS | 短信通知支持双向通信。 短信包含以下信息： - 此警报发送到的操作组的短名称 - 警报的标题。 用户可以回复短信，以： - 取消订阅所有操作组或单个操作组的所有短信警报。 - 重新订阅警报 - 请求帮助。 有关支持的短信回复的详细信息，请参阅短信回复。 |
输入短信收件人的国家/地区代码和电话号码。 如果无法在 Azure 门户中选择国家/地区代码，则你所在的国家/地区不支持短信。 如果你的国家/地区代码不可用，则可以在分享看法中投票以请求添加你的国家/地区。 在支持你的国家/地区之前，作为一种解决方案，可配置操作组以向支持你所在国家/地区的第三方短信提供商调用 Webhook。 |
| Azure 应用推送通知 | 将通知发送到 Azure 移动应用。 要启用 Azure 移动应用的推送通知，请提供有关 Azure 移动应用的详细信息（请参阅 Azure 移动应用）。 | 在“Azure 帐户电子邮件”字段中，输入配置 Azure 移动应用时用作帐户 ID 的电子邮件地址。 |
| 语音 | 语音通知。 | 输入通知收件人的国家/地区代码和电话号码。 如果无法在 Azure 门户中选择国家/地区代码，则你所在国家/地区不支持语音通知。 如果你的国家/地区代码不可用，则可以在分享看法中投票以请求添加你的国家/地区。 在支持你的国家/地区之前，作为一种解决方案，可配置操作组以向支持你所在国家/地区的第三方语音呼叫提供商调用 Webhook。 |
可以触发的操作的完整列表
| 操作类型 | 详细信息 |
|---|---|
| 自动化 Runbook | 有关自动化 runbook 有效负载的信息，请参阅自动化限制。 |
| 事件中心 | 事件中心操作会将通知发布到事件中心。 有关事件中心的详细信息，请参阅 Azure 事件中心 - 大数据流式处理平台和事件引入服务。 你可以订阅来自事件接收器的警报通知流。 |
| 函数 | 调用函数中的现有 HTTP 触发器终结点。 有关详细信息，请参阅 Azure Functions。 定义函数操作时，函数的 HTTP 触发器终结点和访问密钥保存在操作定义中，例如 https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key>。 如果更改函数的访问密钥，则必须在操作组中移除并重新创建函数操作。终结点必须支持 HTTP POST 方法。 函数必须有权访问存储帐户。 如果它没有访问权限，则密钥不可用，并且无法访问函数 URI。 了解如何还原对存储帐户的访问权限。 |
| ITSM | ITSM 操作需要 ITSM 连接。 若要了解如何创建 ITSM 连接，请参阅 ITSM 集成。 |
| 逻辑应用 | 可以使用 Azure 逻辑应用来生成和自定义集成工作流，以及自定义警报通知。 |
| 安全 Webhook | 使用安全 Webhook 操作时，必须使用 Microsoft Entra ID 来保护操作组与终结点（即受保护的 Web API）之间的连接。 请参阅为安全 Webhook 配置身份验证。 安全 Webhook 不支持基本身份验证。 如果使用的是基本身份验证，请使用 Webhook 操作。 |
| Webhook | 如果使用 Webhook 操作，则目标 Webhook 终结点必须能够处理不同警报源发出的各种 JSON 有效负载。 无法通过 Webhook 操作传递安全证书。 若要使用基本身份验证，必须通过 URI 传递凭据。 如果 Webhook 终结点需要特定的架构（例如 Microsoft Teams 架构），请使用逻辑应用操作类型来控制警报架构以满足目标 Webhook 的预期。 有关用于重试 Webhook 操作的规则的信息，请参阅 Webhook。 |
请记住，大多数服务事件会影响几个订阅，因此这些事件不会显示在 status.azure.com 等位置。 可以从门户配置服务运行状况警报 - 如果要自动创建，还可以通过 PowerShell 或 ARM 模板配置这些警报。
通过有效地配置服务运行状况警报和操作组，可以确保接收及时通知并采取适当的措施来缓解事件对 Azure 资源的影响。
注意
在监视什么以及应该为什么配置哪些警报方面寻求帮助？ 查看“Azure Monitor 基线警报”解决方案。 它提供全面的指导和代码，用于通过 Azure 环境中的策略和计划实现平台警报以及服务运行状况警报基线，并提供自动部署或手动部署选项。 该解决方案包括预定义的策略，用于为所有服务运行状况事件类型（服务问题、计划内维护、运行状况公告和安全公告）、操作组和各种 Azure 资源类型的警报处理规则创建警报。 虽然重点是监视 Azure 登陆区域 (ALZ) 架构环境，但它还为目前与 ALZ 体系结构棕色地带不一致的棕色地带客户提供指导。
操作 #3：考虑 Azure 资源运行状况警报或计划事件，以通知资源特定的问题
设置服务运行状况警报后，请考虑同时采用资源运行状况警报。 无论原因如何，当这些资源的运行状况发生变化时，Azure 资源运行状况警报会几乎实时地发出通知。
“服务运行状况”警报和“资源运行状况”警报的主要区别在于，前者是在已知平台问题期间触发的，例如 Microsoft 正在调查的持续中断（服务事件）。 相比之下，当特定资源被视为不正常时，会触发后者，而不考虑根本原因。
可以从 Microsoft Azure 门户的“服务运行状况”边栏选项卡中的“资源运行状况”窗格配置资源运行状况警报。
还可以使用 Azure 资源管理器模板和 Azure PowerShell 以编程方式创建资源运行状况警报。 通过编程方式创建资源运行状况警报，可以批量创建和自定义警报。
虚拟机的计划事件，避免影响
计划事件是另一个很好的工具，上面的“警报”类型都会通知人员或系统，计划事件会通知资源本身。 这可以让应用程序有时间为虚拟机维护或我们的自动服务修复事件做准备。 它提供关于即将发生的维护事件（例如，即将进行的重启）的信号，以便应用程序能够知道这一点，然后采取行动限制中断，例如，通过运行自动化将其从池中退出或以其他方式正常降级。 计划事件可用于 Windows 和 Linux 上的所有 Azure 虚拟机类型（包括 PaaS 和 IaaS）。
注意
尽管资源运行状况警报和计划事件都是有用的工具，但最重要的操作要求是配置服务运行状况警报。 这一点对于确保了解资源发生的情况、我们正在执行的操作以及缓解时间至关重要。
操作 #4：提高投资的安全性以保护环境
通过查看和实施操作安全最佳做法，确保保护 Azure 中的数据、应用程序和其他资产。 这些最佳做法源自使用 Azure 平台的当前功能和特性的人员的集体知识和经验。 这篇文章会定期更新，以反映不断发展的观点和技术。
作为起点，请考虑以下最重要的实施建议：
要求所有用户进行双重验证。 这包括组织中的管理员和其他人员，如果他们的帐户泄露，可能会产生重大影响（例如，财务官员）。 强制实施多重身份验证，以缓解这种暴露的担忧。
在租户上配置和启用风险策略，以便在环境中存在“任何人”时收到警报。 这将针对匿名 IP 地址使用、非典型旅行、不熟悉的登录属性等风险事件创建警报，并进一步触发修正工作，例如多重身份验证、重置密码等，从而确保客户保持安全。
控制订阅在目录中的移动作为一项主动措施，以便为环境中的“任何人”做好准备并通知相关情形。 这可确保组织能够充分了解所使用的订阅，并阻止将可能转到未知目录的订阅移动。
定期轮换所有全局和订阅管理员的凭据，以帮助防止潜在的安全违反、泄露的帐户或未经授权使用特权权限。 定期轮换凭据会为环境添加额外的安全层，并帮助维护数据和资源的完整性和机密性。
查看并定期更新租户内所有全局管理员用户的电子邮件和电话号码
操作 #5：提高关键 Azure 工作负载的复原能力，以可能避免或最小化影响
为了确保工作负载的可靠性，必须通过 Microsoft Azure 架构良好的框架评审使用 Microsoft Azure 架构良好的框架 (WAF) 的原则来评估它们。 WAF 还提供复原能力测试建议，包括采用混沌工程方法。
应用程序应接受测试，以确保可用性和复原能力。 可用性是指应用程序在没有显著故障时间的情况下运行的持续时间，而复原能力衡量应用程序从故障恢复的速度。
若要补充 WAF 的工作，请考虑实施以下最重要的建议，并利用提供的工具来帮助检查和构建应用程序中的复原能力：
利用 Microsoft Azure 门户中的“Azure 顾问”边栏选项卡下的集成“可靠性”工作簿来评估应用程序的可靠性状况，识别潜在风险，并规划和实施改进。
通过跨多个区域部署工作负载和资源来增强业务连续性和灾难恢复 (BCDR)。 有关最佳跨区域部署选项，请参阅 Azure 区域对的综合列表。
通过跨可用性区域分布工作负载/资源部署，最大程度地提高区域中的可用性。
请考虑将 Azure 中的隔离虚拟机大小用于需要高度隔离的业务关键型工作负载。 这些大小保证虚拟机专用于特定硬件类型，并独立运行。 有关详细信息，请参阅此处：Azure 中 VM 的隔离 - Azure 虚拟机 | Microsoft Learn。
请考虑利用维护配置更好地控制和管理 Azure 虚拟机的更新。 此功能允许你计划和管理更新，确保对敏感工作负载造成最小中断，这些工作负载不能容忍维护活动期间的故障时间。
通过实施区域间或区域内部冗余来增强冗余。 有关指导，请参阅高可用性区域冗余 Web 应用程序的示例。
利用 Azure Chaos Studio 增强应用程序的复原能力。 借助此工具，可以故意向 Azure 应用程序引入受控故障，从而评估其复原能力，并观察它们如何响应各种中断，例如网络延迟、存储中断、机密过期和数据中心故障。
利用 Microsoft Azure 门户中的“Azure 顾问”边栏选项卡下提供的“服务停用”工作簿。 此集成工具可帮助你随时了解可能影响关键工作负载的任何服务停用情况，使你能够有效地规划和执行必要的迁移。
注意
具有顶级/统一支持协议的客户可以利用客户成功团队来制定和实施架构良好的框架评估 (WAF)。