为什么要预估
补丁排期要算三笔账：单机执行时间、回滚与返工成本、窗口内可用人力。低估的后果不是『做得慢』，而是每次窗口都排满、每次都收尾不了，台账永远落后于计划。预留 10%-20% 的容量留白是常态做法，不是执行不积极。
基本信息
| 排期批次 | 高危快速通道、常规月度批、大版本专项 |
|---|---|
| 常见瓶颈 | 业务确认与变更窗口，而非技术执行 |
| 预算口径 | 大版本升级按项目立项，含测试与培训成本 |
| 公开程度 | 预估与容量缺口同步给业务方 |
典型使用场景
- 月度例行批：估算总机数能否在一次窗口内完成，决定是否拆批
- 紧急漏洞响应：单独拉快速通道窗口，不与常规批混排
- 大版本升级专项：涉及兼容性测试与停机时间，需与业务方协商
- 容量汇报：用数据说明为什么需要更多窗口或人手，而不是凭感觉
- 年度计划：按历史返工率修正下一年的排期模板
估算模型示例
估算模型示例
单机耗时 = 检查 5m + 安装 10-40m + 重启 2-10m + 验证 10m
窗口容量 = 可用时长 x 执行人数 x 并行系数 / 单机耗时
返工预留 = 总量 x 10%~20%（按历史回滚率修正）
# 例：4 小时窗口、2 人、并行 4 台、单机 40 分钟 → 约 48 台，再扣返工预留
# 验证阶段必须算进去：只统计『安装完成』会系统性高估产能容量测算要素
| 要素 | 取值来源 | 常见错误 |
|---|---|---|
| 单机耗时 | 上一批次的实耗记录 | 直接抄厂商文档理论值 |
| 并行系数 | 实测：重启风暴、共享存储瓶颈 | 按人数做线性外推 |
| 可用时长 | 业务确认的停机窗口 | 乐观按整夜或全天计算 |
| 返工预留 | 历史回滚率 | 完全不留，全靠现场加班 |
把预估公开给业务方：排期不是 IT 的黑盒，只有把容量缺口摆出来，才可能换来更多窗口或人手。
同一台机器在一次窗口里既做系统补丁又做中间件升级，故障时无法区分诱因；高风险的改动尽量单独成批，便于回滚与定位。