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

例行维护包含 Azure 应用服务的后台更新。 维护类型可以是性能改进、bug 修复、新功能或安全更新。 应用服务维护可以在服务本身或基础操作系统上进行。

Microsoft 服务质量和运行时间保证在维护期间继续适用。 通知会提到维护周期，以帮助客户了解平台的变化。

期望

与个人电脑、移动电话和其他设备一样，云中的计算机也需要最新的更新。 与物理设备不同，云解决方案（如 Azure 应用服务）提供了更轻松地处理例行维护的方法。 无需停止工作并等待安装补丁。 安装更新后，任何工作负载都可以在几秒钟内转移到不同的硬件。 更新每月进行一次，但可能会有所不同，具体取决于组织的需求和其他因素。

由于典型的云解决方案包含多个应用程序、数据库、存储帐户、功能和其他资源，因此解决方案的某些部分可能会在不同时间进行维护。 其中一些协调与地理位置、区域、数据中心和可用性区域有关。 这也可能是由于云的原因，并非云中的所有内容都会同时被获取。

以下屏幕截图显示了维护事件的示例。

按从上到下的顺序，此示例显示：

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

常见问题解答

为什么维护要这么久?

从根本上讲，例行维护会为平台和服务提供最新的更新。 很难预测维护在特定时间内对单个应用的影响，因此通知往往更加笼统。 通知中的时间范围并不能反映应用级别的体验，而是反映所有资源的总体操作。 接受维护的应用会立即在新更新的计算机上重新启动并继续工作。 未提供请求和流量时，计算机不会停机。

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

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

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

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

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

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

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

Azure 应用服务代表一组缩放单元，为客户提供 Web 应用程序和解决方案的托管。 每个缩放单元划分为升级域和可用性区域。 这一划分优化了更大的应用服务计划的布局并实现平稳部署，因为并非每个缩放单元中的所有计算机都会立即更新。

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

是否会反映营业时间?

是的，工作时间反映的是该地区的时区。 维护操作已优化为在上午 9 点至下午 5 点的标准工作时间之外开始。 从统计上讲，这是工作负载中断和重启的最佳时间，因为此时的系统（客户应用程序和平台本身）压力较小。 如果资源仍在给定区域中上午 9 点升级，则升级将在下一个关键步骤之前安全地暂停，直到工作时间结束。

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

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

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

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

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

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

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

后续步骤

请阅读博客文章 Azure 应用服务的例行计划内维护通知，获取有关维护通知的详细信息。