豪猪网站维护：省下的时间都赔在返工上

图省事那一刻确实爽。配置改完不备份，插件一键升级不看日志，模板直接在线上编辑——当时十分钟收工，回头可能要拿一整个下午来擦屁股。豪猪网站维护这块，栽跟头的地方大多不在技术有多难，而是省了不该省的那一步。

豪猪网站维护最贵的成本就是返工

返工凭什么贵？不是那几行命令难敲，是重新把上下文捡起来太耗人。半年前谁改的、为什么改、改之前是什么样，全靠猜。猜错了就再回滚一次，来回两趟，原本十分钟的活拖成一下午。一个人管站点的感受更明显：白天被业务催，晚上才有空收拾残局，第二天状态还不好。

还有种隐性返工是没人知道。同事以为配置还是旧的，按老逻辑又改了一遍，两份改动叠在一起，最后谁也说不清是哪一步出的问题。查起来比从头做一遍还费劲。

一键按钮按下去，坑也跟着下去

插件升级、主题升级、一键迁移、一键优化，面板上这些按钮，作者只保证正常路径能跑通，你站上那堆自己改过的模板、自己加过的函数，人家没法替你想。升级前把主题目录、插件目录、上传目录打包一份，土是土，出事的时候真能救命。配置文件也一样，nginx.conf、php.ini 手改之前先复制一份带日期后缀的，这个习惯成本就几分钟。

备份做完不算完，能恢复才算数

备份放在同一台机器上，或者同一个对象存储账号里，机器一挂全没，这种不少见。更常见的是文件从来没打开过，真出事一解压就报错。稳妥点的做法是留一份在异地或者另一家账号里，隔段时间挑一份真恢复一次，看能不能跑起来。数据库那边尤其容易糊弄：命令行导出看着成功了，中间断了你不知道，导回去才发现缺表。数据量大的站点最好用工具来做，顺带验证一下校验值。

日志留一份，能省掉大量瞎猜

很多站点出事后的第一反应是到处问人，却没人去看错误日志。PHP 的 error log、nginx 的 access.log 和 error.log、面板自己的操作日志，这几处基本能定位大半问题：是脚本报错、是上游超时、还是有人拿工具在扫后台。要做的只是别让日志攒成一坨。写得勤的站点，日志按天切开、留个十来天够用，别等到磁盘被写满才发现。改配置之前顺手记一下当前日志路径和切割规则，别回头找不到日志写哪儿了。

真出事那天你会发现，日志比任何人的记忆都可靠。谁在几点改了文件、哪个 IP 疯狂请求同一条地址、报错从哪一分钟开始密集出现，翻两页就有线索。平时花几分钟看一眼错误日志里反复出现的几条，往往能在它们变成故障之前就掐掉。

回滚的路要在动手之前就想好

改之前先问一句：这步要是错了，怎么回去？文件类的改动好办，备份覆盖回去就行；麻烦的是数据库和配置。加字段、删表、改字符集这类操作，回滚基本靠事前导出的那份数据，所以顺序不能反，先备份再动手。代码上线也一样，留一份上一版的完整目录，出问题直接换回去，别在线上现场调试，那时候手是抖的。

有条件就做个简单的灰度：先在测试站点跑，或者先让一部分流量走新版本，看着稳定再全量。回滚方案不用写得多复杂，写清楚哪几个文件、哪几条命令、大概多久能恢复，就够用了。

改动没留痕，等于给半年后的自己挖坑

加一条 crontab，改一处伪静态，动一下防火墙端口，微信里说一声就干了，谁也没记。过几个月站点出问题，第一反应是“以前好好的”，第二反应是“到底改过啥”。弄个 changelog 的纯文本文件丢在仓库或者运维目录里，一行写日期、一行写改了啥、为什么改，前后不超过一分钟。翻记录这件事，平时看着没用，出事那天能省下大量瞎猜的时间。

换人接手之前，先把资产登记清楚

换人接手或者外包做维护的时候，交接最能看出平时的底子。域名在哪家注册、解析在哪个账号、服务器和面板怎么登录、证书怎么续、备份放在哪儿，这些写成一张纸，谁来接手都不慌。不少人图省事，全塞在自己脑子里，人一走站点就像断了线的风筝，找回来要花的功夫比当初省的多得多。

测试和线上混着用，出事只是早晚

图快的时候最容易干的事，就是拿线上当试验田：直接改模板文件，拿生产库跑测试脚本，删数据忘了加条件。一次没出事不代表下次不出，运气这东西会用完。预算允许就开一台最小的测试机，把站点和数据拷一份过去，改完在那边先跑，看着没问题再上线。实在没条件，至少上线前把要改的文件备份好，改完立刻动一动首页、列表页、后台登录这几处，冒烟测试别省。

维护清单别写太长，能坚持才算真的

网上那些上百项的维护清单，看着专业，写完就吃灰。留几条自己能天天做到的：证书到期时间、磁盘剩余、备份能不能恢复、依赖有没有安全公告、日志里有没有反复出现的报错。用日历提醒，别指望脑子记。维护不是做给谁看的，是给自己省麻烦。

维护做得糙，不会立刻出事，这才是最坑的地方——它安静得让你以为没事。想改的话，下次动配置前先做三件小事：打包一份、记一行字、先在测试机跑一遍。省下来的时间，才算真省下来了。