网站日常维护做啥？一份巡检清单

做站年头长一点的朋友都明白一个道理：网站维护这活儿，真不是等它挂了才动手。绝大多数事故在爆发前都留过信号，磁盘是慢慢涨满的，证书是一天天逼近到期的，备份是某天悄悄就不再生成却没人发现。我自己的做法是把它拆成日、周、月三层，每天花五分钟，每周半小时，每月一小时，既不折腾人，又能把大部分坑提前踩掉。下面这份清单是我这些年根据踩坑经验反复修出来的，命令都能直接复制，你按自家情况改改就能用。

每天第一件事：看可用性监控，别等用户来通知你

可用性监控是清单里最省事也最要紧的一条。没条件上商业监控的，两台机器上写个定时任务，用curl请求首页取状态码就够用，重点是有人收得到告警。我踩过最大的坑不是没有监控，而是监控挂在那儿却没接线，连续几天报错谁都没看见，直到客户打电话来才知道。另外提醒一句，别拿GET去刷首页做探活，次数多了统计和缓存都会被带偏，用HEAD请求更干净；检查项也别只盯首页，登录页、搜索页这类走数据库的页面更能反映真实状态。

每天顺手两行命令：df -h 与 df -i 都要看

磁盘是网站的头号杀手，而且它涨起来通常是无声无息的。每天敲一遍df -h，重点不是看百分比数字高低，而是看增速：昨天七成今天八成，这种趋势比绝对值危险得多，说明日志或者缓存正疯长，得当天挖出来。更常被忽略的是df -i，它看的是inode占用，也就是文件数量。磁盘明明还剩好几个G，网站却写不进文件、报No space left on device，十有八九是inode先满了，小文件堆成山造成的。

看到inode告警也别急着删，先定位是谁在疯狂生成文件。缓存目录、会话文件、邮件队列、上传临时目录都是重灾区，用find按时间筛出最近一天内新增的文件，按目录一层层数数量，很快就能揪出源头。顺手把该目录下的过期缓存清掉，再从配置层面把生命周期改短一点，比每次手删靠得住。另外看一眼/tmp和系统日志目录，很多主机默认好几周不清理。

每周必做：确认备份真的生成了，还要抽一个恢复试试

备份这件事最坑的地方在于：任务显示执行成功，文件却在落地时出了问题。所以每周固定一天，去备份目录ls -lh看文件大小，重点看体积跟上周比有没有明显缩水，几百K的「数据库备份」基本可以判定是空壳。更狠一点的做法是随机挑一个备份包，解出来恢复一个文件或者一张表，扔到测试库里看看数据能不能读。恢复没验过，就等于没备份，这条规矩请刻在脑子里。

每周翻日志：Nginx的error.log和PHP错误日志

日志不用天天逐行看，每周集中翻一遍就够。Nginx的error.log里，connect failed和upstream timed out这两类最值得警惕，它们往往是502的前奏，出现密度上来就说明后端进程扛不住了。PHP错误日志里重点搜Fatal error和Allowed memory size exhausted，前者多是插件或主题代码写崩了，后者说明内存上限卡得太紧。用grep配tail把最近几天的段落捞出来，比从头读整个文件高效得多。

每周看证书剩余天数，顺便扫一眼登录失败记录

证书过期是少数能百分之百提前预知的故障，却总有人栽在上面。登录服务器执行openssl x509 -enddate，把证书文件路径接在后面，就能看到具体到期时间；想省事就写进脚本换算成剩余天数。以Let’s Encrypt的九十天证书为例，常规做法是剩三十天就该自动续期，如果那时候还没动作，就该人工介入查为什么续不上，而不是等到剩三天再手忙脚乱。

登录失败记录也建议每周扫一次，lastb命令能列出最近失败的登录尝试。看到某个IP连着几千次失败，基本可以判定是在爆破SSH，处理思路很简单：改掉默认端口、禁用密码登录只留密钥、必要时用fail2ban之类工具自动封禁。这里要说句实话，lastb只能看系统层面的登录尝试，网站后台的爆破它完全记不到，那部分得去Nginx访问日志里按请求频率统计。

每月复盘一次：慢查询、收录与排名变化

每月的活儿不是为了救火，而是为了看清趋势。MySQL的慢查询日志是重点材料，看的时候别只盯着耗时最长的那条，执行次数多、扫描行数大的查询往往才是拖慢整站的元凶，它们通常来自某个插件的写法或者缺少索引。收录和排名这块，拿site语法自查一下大致收录量，再结合搜索资源平台里的点击和展现数据看走向。顺带提醒：如果展现涨了点击没涨，问题多半出在标题和描述，别一看到数字波动就改标题，一次只动一个变量，观察两周再下结论。

每月动手做：内核与插件升级、过期账号与权限清理

升级这件事别攒着，但也不能瞎点。固定一个时间窗，先把文件和数据库备份做掉，再动手：内核升级完记得确认是否需要重启才生效，不少补丁不重启等于没打；插件不要图省事全开自动更新，久未维护的插件更要先看兼容说明，能先在测试环境跑一遍最好。更新完立刻回前台点几个页面，确认没有白屏和样式错乱，发现问题可以及时从备份回滚。

账号和权限清理是最容易被跳过的一项，也是安全事故的重灾区。每月过一遍后台用户列表，把离职人员、废弃测试号、不知道谁建的账号处理掉，尤其要盯住管理员角色有没有多出陌生面孔。目录权限也顺手核一遍，网站目录一般755、文件644，上传和缓存目录不要给到777，配置文件比如wp-config.php要更严；装过phpMyAdmin之类工具的，用完最好直接删掉，别长期留在服务器上给人当靶子。

最后一步：把清单写成带阈值的定时检查，别靠人记

清单写在纸上迟早会被忘，真正靠得住的做法是把每条都变成脚本加定时任务。核心有两点：一是要有明确阈值，比如磁盘超过百分之八十五、证书剩余不足三十天、备份文件小于上周的八成、同IP登录失败超过五十次，达到条件才报警；二是要有人真的收到，光往一个没人看的邮箱发信等于没有告警。经验之谈是，没有阈值的检查跑一周就沦为噪音，随手被忽略；阈值定得太松又会天天响，人一样会麻木。

维护这件事说到底，就是把救火变成例行公事。日清单保命，周清单防患，月清单调优，三层都转起来，你对站点的状态心里就有底了。我自己的习惯是把检查结果记在一个简单的表格里，出问题时回头一翻，什么时候开始异常一目了然。先从今天的两条命令和一次备份验证开始，比收藏十篇教程都实在。