小王刚接手公司内部CRM系统的日常维护，领导甩来一句话：“下周交一份维护计划表”。他翻了翻同事留下的旧文档，全是空洞的“定期检查”“及时响应”，根本没法照着干。其实，一份能落地的维护计划表，根本不是写出来的，而是跑出来的。
从“抄模板”到“真能用”的三步法
别急着打开Excel填表格。先问自己三个问题：
• 这个软件谁在用？哪些模块出过故障？
• 上次崩溃是什么时候？日志里反复出现哪类报错？
• 现有备份多久做一次？恢复测试过吗？
比如财务系统每月初结账前必须稳定运行，那维护窗口就得避开这个时段；又比如某第三方API接口上周连续三天超时，那计划里就得单列一条“每日10:00检查API健康状态”。问题越具体，计划越不飘。
动手填表：四栏够用，别堆花架子
我们用最简化的四栏表格启动（Excel或在线协作文档都行）：
维护项 | 执行频率 | 具体动作 | 责任人
--------|----------|----------|---------
数据库备份 | 每日23:00 | 执行mysqldump + 上传至NAS，校验MD5 | 小王
缓存清理 | 每周一9:00 | redis-cli FLUSHDB，查看内存使用率 | 小李
日志归档 | 每月1日 | 压缩/var/log/app/上月日志，保留6个月 | 小王
安全补丁 | 发布后48小时内 | 检查CVE公告，测试补丁兼容性，灰度上线 | 小李注意：所有“具体动作”必须是动词开头、可验证的动作。像“加强监控”这种描述直接删掉——你没法对着它打勾。
让计划活起来的关键动作
定完表不是结束。每周五下午抽出15分钟做两件事：
• 对照计划表，把已完成项打钩，没完成的旁边写清原因（如“未执行：周三服务器宕机2小时”）；
• 把本周新发现的问题加进下月计划（比如用户反馈导出功能卡顿，就新增“每两周压测导出模块”）。
有次小王发现定时备份脚本在磁盘满时静默失败，他立刻在计划表“数据库备份”动作后追加一句：“执行后检查/var/backup目录剩余空间，＜5GB触发企业微信告警”。这比写一百句“重视稳定性”管用。
维护计划表不是挂在墙上的装饰画，是贴在屏幕边、随鼠标一起滚动的活页纸。今天改一行动作描述，明天少一次半夜救火。