每月一个固定修补窗口，站点怎么排自己的维护计划
每月一个固定修补窗口，站点怎么排自己的维护计划？把窗口对齐上游的固定节奏，再按「窗口前一周准备、窗口当天只处理命中的条目、窗口后复验并留记录」三段排。上游之所以能对齐，是因为它们自己也是固定的：当天复核到的 Drupal 核心排期页写着，每月的第三个周三（协调世界时）是安全版本发布窗口。计划固定下来之后，维护从「被公告追着跑」变成「按日历执行」。
上游为什么选固定窗口
固定窗口的作用是让依赖方能够预留人力。除 Drupal 的每月第三个周三，WordPress 的大版本节奏同样提前公布：当天复核到的发布页写着 Beta 1 在十月二十日、候选版本在十一月十七日、正式版本在十二月八日发布，并且会随新版本附带一套新的默认主题。这两条节奏一条按月、一条按年，但都是可以先写进日历的，站点没必要用临时加班去应对可预期的事件。
窗口前一周该准备什么
准备阶段只做三件事：清单、备份、分组。
| 阶段 | 动作 | 完成标准 |
|---|---|---|
| 窗口前一周 | 导出程序版本与扩展组件清单，比对上游公告的影响区间 | 能明确列出「命中条目」与「不命中条目」两份名单 |
| 窗口前一周 | 跑一次完整备份并演练恢复 | 记录恢复耗时，确认数据（含静态文件）真的能回来 |
| 窗口前三天 | 把站点按暴露面分组，确定本窗口动哪一组 | 每组都有回滚点与负责人 |
| 窗口当天 | 只升级命中条目，不改功能、不换主题 | 每项动作可单独回退 |
| 窗口后两天 | 复验版本、缓存、响应头与关键流程 | 复验记录归档，异常条目回到跟踪清单 |
备份演练经常被跳过，而它恰恰是窗口能否守住的前提：没有可恢复的备份，任何人都会在窗口当天选择「这次先不动」。
窗口当天做什么、不做什么
当天只做命中条目。三个禁止动作：不顺手升级未命中的组件、不做模板改版、不合并功能发布。原因是同一天里两类变更混在一起，出问题就分不清归因，回滚也要连带撤掉无关改动。
内容排期要提前避让。用定时发布把营销内容排到窗口之外，别把批量上线和维护挤在同一时段；待发布状态的稿件在窗口期先按住，等复验通过再放行。窗口当天顺手把维护记录用邮件提醒发给相关人，比事后在群里补叙要可靠。
窗口后的验证与记录
复验按四步走：核对版本是否真落在修复区间；清程序缓存与外部缓存；检查关键地址的响应头是否还是可公共缓存；跑一遍核心业务流程（提交表单、登录后台、生成页面）。记录格式固定成三列：动了什么、验证结果、回滚点位置。
部署方式决定这一步的速度。用 Docker 镜像部署的站点，回滚是指回上一个标签再拉起，分钟级；用宝塔面板或 LNMP 命令部署的，回滚要连带数据库与站点目录，所以窗口前那次恢复演练格外重要。窗口安排得再稳，也得有能退回去的路。
常见问题
上游临时发紧急通告，还要守窗口吗？ 紧急通告按分级处理：匿名可触发且已在野的，当天单独走一次小窗口；其余仍并入最近的常规窗口。
一个月一次会不会太疏？ 对没有命中条目的小站够用。风险高的站点可以把「核对清单」提到每周一次，但升级动作仍然集中在固定窗口。
多个站点共用一台机器怎么排？ 按暴露面分组，先小站后主站，每组之间留复验时间；共用进程组的部署会让恢复耗时相互影响，排期时要把这一点算进窗口长度。