是什么
切换窗口的选择本质是找业务最不受影响的时段：用访问日志统计请求量低谷，再与批处理、对账、结算、营销活动的时间表交叉核对，避开这些时段。窗口时长要覆盖三段：执行操作的时间、追平与重试的缓冲、切换后验证业务的时间。窗口定得太短，追平一慢就直接挤压验证环节，风险最大的部分反而没有时间做完。
基本信息
| 数据依据 | 访问日志的请求量曲线加批任务时间表 |
|---|---|
| 避开时段 | 结算、对账、月结、月底月初与营销活动 |
| 时长构成 | 操作时间、追平缓冲与验证时间三段相加 |
| 沟通 | 提前与业务方确认窗口并公告，明确影响范围 |
| 值守 | 窗口内执行、验证与决策角色同时在线 |
典型使用场景
- 数据库割接：选在写入量最低的时段，缩短停写时长
- 跨机房切换：结合两端业务的访问高峰分布挑交叉低谷
- 版本发布与迁移合并：避免同一天同时做两件有风险的事
- 跨部门协调：窗口需要业务、运维与厂商三方共同确认
- 海外业务：按目标用户所在时区的低谷确定窗口，而不是按本地作息
从访问日志找低谷
从访问日志找低谷
# 按小时统计请求量，定位低谷段
awk '{print $4}' access.log | cut -d: -f2 | sort | uniq -c | sort -k2n | head
# 与批任务时间表交叉核对，确认低谷段里没有定时作业
crontab -l | grep -v '^#'
# 核对消息队列的消费速率与积压，确认停写不会造成积压雪崩
# 最后把窗口起止时间、影响范围与回滚时限写进公告窗口要素核对
| 要素 | 判断依据 | 常见失误 |
|---|---|---|
| 低谷时段 | 访问日志按小时的请求量统计 | 只看工作日，忽略月末与活动期 |
| 批任务冲突 | 作业调度表与报表产出时间 | 窗口与对账任务重叠，两边都慢 |
| 三段时长 | 操作加工缓冲加验证的实际耗时 | 只算操作时间，验证被压缩 |
| 公告与值守 | 业务方确认加值班表 | 值班人员不到位，出问题没人决策 |
窗口结束时间要明确写“最晚决策点”：到了这个时间仍未通过验证，就按预案回滚，而不是继续等下去。这条规则要在窗口开始前与业务方确认。
把窗口选在批处理时段，迁移与批任务争抢磁盘与网络，双方都变慢，追平时间被拉长，容易演变成超时回滚。