高可用系统为什么也需要维护窗口？

简化版

维护窗口不是承认系统不高可用，而是把高风险升级、数据迁移和基础设施操作放进人员、容量与回滚条件最充分的时段，限制同时变更数量和故障半径。真正高可用的系统应尽量无损滚动维护，但仍需窗口管理不可完全在线或需要强协同的操作。

窗口前冻结无关变更，确认备份/副本、N-1 容量、值班人员、监控和回滚；窗口中分批执行，每批设置成功率、P99、复制 lag 和业务指标护栏；窗口结束前完成验证或回滚，不能把未完成风险留给无人时段。

维护动作必须区分可在线滚动、需要降级和必须停机三类。对用户有影响时提前公告并给出范围；无感维护也要记录实际容量下降。窗口不能成为跳过灰度和测试的借口。

高可用依赖副本和故障域，但维护会主动减少副本、迁移数据或改变协议。此时再叠加一个真实故障，冗余可能被耗尽。窗口的价值是把人员、观察时间和风险预算集中起来，而不是简单选择“夜里流量低”。

记忆钩子：维护窗口管理的是“变更期间暂时变薄的安全余量”。

能滚动就不应默认停机，但“支持滚动”必须经过版本兼容与容量验证，而非依赖文档宣称。

检查备份可恢复、复制健康、磁盘水位、剩余容量、回滚包、权限和依赖联系人。若 10 个实例当前流量需要 8 个，滚动批次最多只能同时下线 2 个，且还没有额外故障余量；更安全的批次可能是 1 个。

maintenance_capacity = healthy_capacity - batch_removed_capacity
必须 >= peak_load + safety_margin

先 canary，再 10%、25%、50%，每批等待足够样本。错误率比基线高 0.5 个百分点、P99 高 20% 或复制 lag 超 60 秒时自动暂停。操作人和观察人分离，避免同一人忙于命令而错过指标。

并行操作要检查共同故障域。不能同时维护同一分片的多个副本，也不能在一个 AZ 做网络升级时又把流量集中到该 AZ。

数据库变更采用 expand/contract：先增加兼容结构，新旧代码共存，数据回填并校验，切读后再删除旧结构。一步 rename/drop 会让回滚代码无法运行。大规模回填独立限速，不能挤占在线事务日志和 I/O。

假设回填 1 亿行、每秒 5000 行，理论需约 5.6 小时，必须确认窗口是否容纳；若不能，就把回填设计成跨窗口可续跑任务，而不是临时提高速度。

窗口结束不等于命令执行完。需要核心交易验证、容量恢复、无异常积压、监控和告警正常、临时开关清理。无法完成时在预留的回滚截止点前退回，不能因“已经做了大半”赌博。

记录实际开始/结束、每批指标、偏差、用户影响和待办。对外公告应描述受影响能力与时间，不泄露内部敏感拓扑；内部则保留完整审计。

维护窗口按“准入—分批—护栏—截止—验证”管理。窗口前确认备份、容量和回滚，窗口中只做受控变更并避免共同故障域，截止点前果断回退，结束时恢复所有安全余量。它让维护风险可预测，而不是给停机找理由。

窗口排期还应避开大促、账务日切和上游集中变更，并预留观察期，不能把“命令执行完”直接当作维护结束。