卡神写在前面：从那以后，我再没自己 SSH 过
做海外现金贷风控，网站 kas2.com 是门面，也是业务入口。以前它一抽风，我的流程是：打开宝塔面板 → 看监控 → 翻错误日志 → 百度报错 → 改配置 → 重启 → 祈祷。一套下来少则半小时，多则两小时，还经常改坏别的地方。
现在的情况是：网站出问题，我一句”帮我看下服务器为什么访问不了”，它连上去自己排查、自己修，我在微信上等它回”搞定了”就行。这篇不讲虚的，把我真实踩过、也真实修过的几类服务器活，一次性说清楚——哪些能放心交，哪些要你先划好边界。
一、第一次救援：网站 503，它连上去自己修
头一回真正让我放心的，是一次 503。那天早上打开 kas2.com，直接”Service Temporarily Unavailable”，刷新也没用。换成以前，我得自己登服务器看 PHP-FPM 是不是挂了、内存是不是爆了。
这次我直接把活交给它：给一句”网站打不开，帮我连 43.226.37.238 排查”。它干了这么几件事：
- 看进程：用 `ps` 确认到底谁在跑——是 Apache(httpd)还是 Nginx。这一步很关键，我这台机器实际跑的是 Apache，宝塔里那些 Nginx 配置是残留模板，根本不生效。它没被面板误导，直接对着 httpd 下手。
- 看日志：翻 Apache 错误日志和 PHP-FPM 慢日志，定位到是 PHP 版本太老（还停在 7.0）加上一部分配置没跟上，导致请求堆积、进程被打满。
- 动手修：把 PHP 从 7.0 升到 7.4、补齐缺失的依赖库、调好 PHP-FPM 的进程数和超时参数，最后重启服务。
前后我只在微信上等了几分钟。等它回”已恢复，你访问试试”，我刷新页面真的正常了。那一刻我意识到：只要权限给到位，常规运维它真能自己闭环。
二、PHP 7.0 → 7.4 升级：别小看版本这件事
为什么卡在 7.0 是个问题？一句话：老版本跑新代码，要么报错要么慢。我们用的 WordPress + 大前端 DUX 主题，新一点的插件对 PHP 版本有要求，7.0 经常兼容性告警，部分功能直接罢工。
升级过程看着吓人，其实有章法：
- 先备份：升级前它先确认有网站和数据库的快照，万一回滚有底。
- 切版本：在服务器上把站点绑定的 PHP 从 7.0 切到 7.4，宝塔面板里点一下的事，但命令行也能做。
- 查依赖：7.4 缺哪些扩展（比如某些 PHP 扩展没装齐），它补齐，避免”切完反而更挂”。
- 验功能：升完访问前台后台、发一篇测试、看错误日志有没有新的 warning。
这套流程我后来自己都不碰了，因为它比人稳——人升级容易漏装扩展，它按清单一项项对。升到 7.4 之后，后台明显轻快，之前偶尔的卡顿也没了。
三、MySQL 密码重置：忘了 root 密码不用慌
有次要导数据，发现 MySQL 的 root 密码一时想不起来。换成以前我得停服务、用安全模式改密码、再起服务，步骤多还怕改崩。
它处理的方式干净：先用 `skip-grant-tables` 临时绕过权限校验起一个实例，进去 UPDATE 掉 root 密码，关掉绕过、正常重启。全程记下了新密码（在我自己的密码本里，不写进任何会外泄的地方），然后我拿新密码正常连。
这里有个关键纪律：密码这类敏感信息，它只在你给的受控环境里用，不该落进文章、配置模板或日志明文。我后面会专门说边界。
四、PHP-FPM 调优：503 的根因常常在这里
为什么单独讲 PHP-FPM？因为那次 503 的根子就在这。PHP-FPM 是处理 PHP 请求的进程管理器，它的”进程数”和”超时”配得太小，并发一上来就排队，队列溢出就 503。
调优的几个核心旋钮，它帮我校过的：
- pm.max_children：最大子进程数。太小扛不住并发，太大吃光内存。它按服务器内存和单进程占用反推一个合理值，不是拍脑袋。
- pm.start_servers / min_spare_servers / max_spare_servers：空闲进程的上下限，让系统不用每次都现起进程。
- request_terminate_timeout：单个请求最长执行时间。太长占着进程不释放，太短正常请求被砍。它按站点实际接口耗时调。
调完最直观的变化：同一波流量下不再 503，慢日志里的超时记录清零。这一步是”治本”，光重启只能顶一时。
五、依赖库补齐：最容易被忽略的暗坑
升级 PHP 之后，常冒出来的问题是”某个函数不见了”或”某扩展没加载”。本质是 7.4 对应的一批扩展（如 gd、curl、mbstring、zip 等）得重新确认装齐。
它的做法很稳：先跑一段诊断，列出缺哪些；再逐个补装并重启；最后再跑一次诊断确认全绿。我之前自己手动补，经常漏一两个，导致后台传图失败、导出 zip 报错这种玄学问题。交给它之后，这种”差一个扩展”的坑基本绝迹。
六、边界：什么能交，什么要先划好线
敢让智能体碰服务器，不等于”把 root 密码一甩就完事”。我自己的几条边界，写出来给你参考：
- 用受控账号：给它能完成运维的最小权限，不无脑给所有权限。万一是破坏性操作，损失可控。
- 高危操作先确认：删库、改核心配置、批量改文件这类，我让它先报计划，我点头它再动。日常排查和重启可以放手。
- 改动可回滚：任何配置修改前，它先留备份（原文件加 .bak 或快照），出问题随时回退。这条救过我一次——某次 Nginx 配置（虽然我这台实际是 Apache，但同理）改错，靠备份三分钟还原。
- 敏感信息不落地：密码、密钥只在本会话和你的密码本里，不写进会发布的文章、不写进 git、不写进日志明文。
- 改完必验：它说”修好了”，我一定自己访问一次前台后台，再扫一遍错误日志，确认没有新 warning 才放心。
结尾
回头看，服务器运维这条线我最大的收获不是”少登几次 SSH”，而是把一套原本靠人记忆、容易遗漏的流程，固化成了”排查—修复—验证—留备份”的标准动作。它执行得比人稳，但前提是边界你先划清楚。
下一篇我讲内容创作那条线——34 篇公众号推文怎么批量发到网站、AI 配图怎么定出”有活力”的硬标准、水印怎么去。那条线和今天这条一样，核心都是”把重复活交给机器，把边界和验收留给自己”。
