问题描述
在日常运维 Azure Container Apps（ACA）时，可能会观察到副本重启、实例滚动更新或短暂连接中断等现象。遇到这类情况时，第一反应通常是平台异常，但实际也可能是底层平台正在执行例行升级或维护。
此时常见的疑问是：
- ACA 是否会通过 Service Health 提前通知每一次维护？
- 如果没有逐次通知，是否可以控制维护发生的时间？
根据官方文档，Azure Container Apps 是托管服务，平台和基础设施更新会定期自动执行。对于常规非关键维护，平台不会针对每次维护单独发送提前通知，而是通过滚动更新等方式尽量降低对业务的影响。可行的控制方式是：为 Container Apps Environment 配置 Planned Maintenance Window，将非关键更新尽量安排在业务低峰期开始。
问题解答
ACA 的维护更新主要分为两类：
- 关键更新（Critical）：涉及安全性和稳定性的紧急修复，可能在任何时间执行，不受维护窗口限制。
- 非关键更新（Noncritical）：包括例行安全补丁、Bug 修复和新功能引入。如果配置了维护窗口，这类更新只会在窗口内开始；如果没有配置，则可能在任意时间开始。
因此，维护窗口并不是“禁止维护”，而是控制非关键更新的开始时间。需要注意的是，维护可以保证在窗口内开始，但不保证一定在窗口内完成。
配置方法（Azure CLI）
示例：每周日 UTC 18:00 开始，持续 8 小时，对应北京时间周一凌晨 02:00 - 10:00。
az containerapp env maintenance-config add --resource-group <group name> --environment <environment name> --weekday Sunday --start-hour-utc 18 --duration 8
命令执行截图：
查看当前维护窗口：
az containerapp env maintenance-config list --resource-group <group name> --environment <environment name>
更新维护窗口：
az containerapp env maintenance-config update --resource-group <group name> --environment <environment name>--weekday Saturday --start-hour-utc 18 --duration 8
注意事项
维护窗口仅适用于非关键更新，关键安全或稳定性修复仍可能在窗口外执行。
每个 Environment 只能配置一个维护窗口，持续时间范围为 8 到 24 小时。
该功能是可选能力，并会产生 Dedicated Plan Management 相关费用。
另外，维护窗口并不替代应用自身的高可用设计，建议将窗口设置在业务低峰期，并确保应用具备多副本、无状态化、重试和熔断等能力，以降低滚动更新期间的影响。
官方文档也说明，该能力不适用于运行在 consumption workload profiles 上的 Container Apps 和 Jobs。
参考资料
Azure 容器应用计划内维护 ：https://docs.azure.cn/zh-cn/container-apps/planned-maintenance
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
