窗口怎么定
选窗口看四个条件：业务低谷（按监控里的真实曲线，不按经验）、资源不叠加（备份、统计、发布、同步不要挤在同一时段）、依赖方就绪（上游供数、下游采集、数据库备份窗口）、长度够用（执行时间加失败重试、回滚与人工验证的余量）。当业务形态决定没有整段低谷时，改用削峰思路：把作业拆成小批分散到全天，或限制并发与带宽让它在峰值也能跑完。
基本信息
| 判据 | 业务低谷、资源不叠加、依赖方就绪、长度含重试与验证余量 |
|---|---|
| 常见误区 | 默认凌晨一定空闲；忽略跨境业务与其他批处理同窗 |
| 替代手段 | 限速与限制并发、把作业拆小分散、按地区分窗执行 |
| 关键约束 | 窗口结束前必须留出验证时间，否则故障延后暴露 |
典型使用场景
- 全量统计与报表：读放大明显，需避开在线查询高峰
- 大批量备份与快照：与主库写操作叠加时影响明显
- 版本发布与重启：需要人工在位，窗口不宜落在无人值守时段
- 数据迁移与历史回填：长事务与大流量并存，通常安排在长窗口
- 索引重建与大表变更：锁与 IO 影响大，需窗口加超时保护
- 跨机房同步：按各地时区分别选窗，避免全球同时跑
测低谷、错峰与窗口保护
测低谷、错峰与窗口保护
# 1 先量化真实低谷：按小时看过去一周的 CPU 与连接数曲线
# sar -u | tail -24 # 视发行版与采集工具差异而定
# 结合业务侧请求量曲线，找出稳定低谷区间
# 2 错峰：同批作业在分钟维度拉开，避免同一时刻齐发
# 10 3 * * * /opt/jobs/report.sh # 03:10 报表
# 40 3 * * * /opt/jobs/cleanup.sh # 03:40 清理，错开半小时
# 3 窗口保护：超过上限即中止，避免拖进早高峰
timeout --signal=TERM 5400 /opt/jobs/report.sh \
|| echo "$(date -u +%FT%TZ) 作业超时或失败" >> /var/log/jobs/err.log
# 4 窗口结束前验证：确认业务指标回到基线，再看是否放行后续作业作业类型与窗口特征
| 作业类型 | 窗口特征 | 资源特征 | 主要风险 |
|---|---|---|---|
| 全量统计 | 业务低谷且上游供数完成后 | 读 IO 与 CPU 高 | 拖到高峰影响在线查询 |
| 备份与快照 | 与主库写峰错开 | IO 与网络占用明显 | 与同步任务叠加压垮存储 |
| 发布与重启 | 有人值守并留验证时间 | 短时不可用 | 回滚超窗，业务停在旧版本 |
| 数据迁移 | 长窗口，分阶段执行 | 带宽与存储持续占用 | 中途失败留下不一致状态 |
| 清理与归档 | 低峰且晚于备份 | IO 与目录操作密集 | 误删与备份重叠 |
排窗前先做测量：从监控里取业务请求量与资源使用的分时曲线，用数据确认低谷区间。经验下限在高并发业务里往往已经不平坦，压测和生产曲线差别很大。
窗口长度只按「正常执行时间」估算，是批量作业最常见的翻车点：首次执行更慢、失败重试更慢、回滚更慢。给重试与人工处置留出余量，并设置硬超时。