Azure 应用服务的例行计划内维护

常规维护包括对 Azure 应用服务的幕后更新。 这些更新可能包括性能改进、bug 修复、新功能或安全更新。 维护可以应用于应用服务平台或底层操作系统。

Microsoft的服务质量和运行时间保证在维护期间继续适用。 我们通知客户以提高对平台更改的了解。

期望

与个人电脑、移动电话和其他设备一样，云中的计算机需要定期更新。 与物理设备不同，Azure 应用服务处理日常维护，且中断最少。 工作负载可以在几秒钟内转移到更新的硬件，这样更新就可以在不停机的情况下继续。

维护通常每月发生，但可能会因组织的需求和其他因素而异。

由于典型的云解决方案由多个应用程序、数据库、存储帐户、函数和其他资源组成，因此解决方案的某些部分可能会在不同的时间进行维护。 这种变化可能是地理、区域、数据中心和可用性区域造成的。 有关详细信息，请参阅安全部署做法。

若要查找维护事件，请在 Azure 门户中搜索 服务运行状况 。 在 “活动事件”下，选择 “计划内维护”。

Azure 门户提供以下信息：

• 维护事件的描述性标题。
• 受影响的区域和订阅。
• 预期的维护时段。

以下屏幕截图显示了通过 “受影响的资源 ”选项卡提供的信息：

示例从左到右显示：

• 选择 “受影响的资源 ”选项卡。
• “更多信息”选项。

此示例显示：

• 维护的状态，可以为“挂起”、“已启动”或“已完成”。
• 维护启动后，可以在 “详细信息”下查看时间戳。

常见问题

为什么维护要这么久?

例行维护为平台和服务提供最新更新。 很难预测维护如何影响各个应用。 通知提供大致时间范围。 这些区间反映了所有资源的总体操作，而不是特定的应用层级体验。 在更新的计算机上，经过维护重启的应用会继续运行。 如果不提供请求和流量，则不会出现停机。

为什么我收到这么多通知?

客户通常有多个在不同时间升级的应用程序。 为了避免就其中每项发送通知，我们将发送一个捕获多个资源的通知。 我们将在维护开始和整个维护时段发送通知。 如果维护时段很长，你可能会收到针对同一推出的多次提醒，以便你更轻松地关联任何重启、中断或其他问题。

例行维护与 SLA 有什么关系?

平台维护不应影响应用程序的运行时间或可用性。 在进行平台维护时，应用程序会继续保持联机状态。

平台维护可能会导致应用程序在新虚拟机上冷启动，这可能会导致延迟。 当应用程序处于冷启动状态时，应用程序仍被视为处于联机状态。 若要最小化或避免冷启动，请考虑使用 Windows 应用的本地缓存和运行状况检查。

我们不希望站点在维护时段内发生任何服务级别协议 (SLA) 冲突。

升级如何保证我的应用顺利运行？

Azure 应用服务代表一组缩放单元，为客户提供 Web 应用程序和解决方案的托管。 每个缩放单元划分为升级域和可用性区域。 此划分优化了大型应用服务方案的位置，并实现了平滑的部署，因为并不是每个缩放单元中的所有计算机都一次更新。

当应用服务监视机群的运行状况时，维护操作会迭代升级计算机。 如果出现问题，系统可以停止推出。 有关此过程的详细信息，请参阅博客文章揭示应用服务 OS 更新背后的秘密。

是否会反映营业时间?

是的，工作时间反映的是该地区的时区。 维护操作已优化为在上午 9 点至下午 5 点的标准工作时间之外开始。 从统计上说，这是任何暂停和任务重启的最佳时机。 客户应用程序和平台本身对系统的压力较小。

应用服务维护旨在最大程度地减少工作时间的中断。 如果给定区域的任何升级仍在上午 9 点进行，则它们会尝试在达到关键阶段之前暂停。 某些底层实例的移动可能会继续，但会进行协调以确保它们能够安全地重叠并保持站点的可用性。

我有哪些控制例行维护的选项?

如果使用应用服务环境 v3 在独立产品中运行工作负荷，可以根据需要计划升级。 有关此功能的详细信息，请参阅博客文章控制和自动执行应用服务环境 v3 的计划内维护。

我可以更好地为重启准备应用吗?

如果应用程序在重启期间需要额外的时间才能联机，请考虑使用运行状况检查。 一种需要额外时间的典型模式是在应用程序预热或启动期间严重依赖外部资源。

可以使用运行状况检查通知平台应用程序尚未准备好接收请求。 系统可以使用该信息将请求路由到应用服务计划中的其他实例。 对于此类情况，建议在计划中至少有两个实例。

我的应用程序一直处于联机状态，但开始出现这些通知以后，情况变得更糟了。 有何变化？

自平台建立以来，升级和维护事件从未间断。 更新频率随时间推移而减少。 中断次数也减少，运行时间增加。 但是，现在可以更深入地了解所有更改。 增加可见性可能会造成正在发生更多更改的感觉。

相关内容

• Azure 应用服务的例行计划内维护通知