项目上线以后，网站已经挂了几个小时，你却一点都不知道。
等用户找上门，你才发现：自己只会把项目部署上去，根本不知道上线以后还要管什么。
写代码时出了问题，你还能让 AI 慢慢改。
可线上真出事，碰到的是真实用户、真实数据和真钱。
项目能打开，只代表部署成功。
能不能一直稳定跑下去，才是上线以后真正要解决的问题。
一天一个 vibe coding 小技巧。
这一篇，也是部署篇的最后一篇，我们把项目上线以后最基础的维护补上。
最后还有一张能长期照着做的维护清单，连让 AI 生成它该说的原话，我一起给你。
一、得知道它还活着，别让日志把硬盘撑爆
上线之后的第一件事，是让网站出问题以后主动通知你，而不是等用户找上门。
所以你得有基础的监控，还有健康检查。
健康检查，就是留一个专门的小接口，随时能看出服务还活不活着。
这事后端骨架篇里讲过，没看过也不影响你先记住这一条。
但只留一个接口，它不会自己跑来告诉你网站挂了。
还得让一个不和网站跑在同一台服务器上的监控工具，从外面定时访问它。
可以用云服务商提供的监控，也可以使用专门的网站可用性监控。
连续几次访问失败，就给你常看的邮箱或者手机发消息。
配置完成以后，还要测试一次告警能不能真的收到。
有测试告警功能就直接用。
没有的话，就拿一个专门的测试地址模拟失败，别为了试告警把生产服务真停了。
除了“活没活着”，还要盯几个身体指标：CPU、内存、还有硬盘。
其中硬盘尤其要盯。
这是新人翻车榜上的常客，偏偏最不容易想到。
你的程序天天都在记日志、攒文件。
日志本是好东西，出了事靠它查原因。
可要是没人管，它就一直往硬盘里写，越积越多。
时间一长，硬盘悄悄就满了。
硬盘一满，网站说挂就挂：数据库写不进、新文件存不下，整个服务当场瘫掉。
最坑的是，你满世界找原因，压根想不到罪魁祸首竟是日志把硬盘塞爆了。
用 Docker 的更要当心：容器要是反复崩溃、无限重启，日志会疯了一样往外冒，硬盘撑爆得更快。
所以除了“盯”，还得“防”。
让 AI 帮你配好两样。
一是给日志设个“上限”，写满就自动滚动、只留最近几份，别让它无限长。
这事有个专门的名字，叫日志轮转。
二是配个基础的硬盘告警，快满了提前提醒你。
这两样，用面板的最省事。
CPU、内存、硬盘这些指标它本来就能看，设成到了某个值就提醒你，点几下就配好了。
日志上限面板里不一定有，没有就让 AI 帮你配上。
挂了、或者快撑不住了，你能第一时间知道，这是底线。
二、出事了得能救
线上迟早会出问题，关键是出了事你能不能救回来。
三件事最重要。
一是，出了问题，别把生产服务器直接交给 AI 处理。
这是很多纯靠 AI 敲代码的人，最容易犯的一个错：一出问题，图省事，直接把服务器丢给 AI，让它自己连进去边查边改。
可你的项目已经在跑生产、真有用户在用了。
AI 连进去，一条命令就可能把线上的数据或配置改坏，出了事你连它动过什么都不知道。
所以记住一条铁规矩：只要项目已经正式上线，就别让 AI 连进服务器，一边排查一边修改。
那出了问题怎么查？两招，都不用把服务器交出去。
第一招，靠日志。
日志，就是你的项目自己记的“流水账”，出了事去翻它，往往就能找到原因。
程序自己的日志想派上用场，最好上线前就在关键功能上记好。
没提前加，也不等于完全没法查。
服务器、容器和面板本身，通常也会留下运行记录。
所以出了事，先把现有的日志交给 AI。
具体做法是：把日志文件下载下来，发给它分析，别让它自己进服务器看。
在可视化面板里下载日志，就跟在自己电脑上找个文件一样简单。
走原生环境的，就直接问 AI：我的日志在哪、怎么下载下来。
发的时候，最好加一句“这是线上生产环境的日志”。
因为 AI 默认会把你本地的代码当成线上那份，你提前说明白，省得它判断错。
要是现有的日志证据还不够，再让它在开发环境补上必要日志，按正常流程部署以后重新复现。
别为了补一条日志，直接在线上文件里临时乱改。
还有那句老话：日志里别把密码、密钥这些敏感信息直接打进去。
第二招，靠命令查。
有些问题光看日志不够，得跑几条命令，看看服务器现在什么状况。
这时候同样别让 AI 自己上，让它给你几条排查用的命令，你自己复制到服务器上跑，再把结果贴回去给它分析。
命令你来敲、结果它来看，服务器的控制权始终攥在你手里。
最后退一步：要是这两招你实在都搞不定，非让 AI 连进去不可，那也一定要先把话说死：只许它用不会修改任何数据和配置的命令排查，先列出发现的问题和处理方案，然后停下来等你确认。
删除、覆盖、重启、修改配置这些操作，一律不能边查边做。
二是能回滚。
回滚，就是当新版本出问题时，能马上退回到上一个好用的版本。
所以每次上线前，都要留好那个还能用的版本，别上了新的就把旧的覆盖没了。
上线前你可以让 AI 先讲清楚两件事：旧版怎么留、坏了怎么退回去。
你确认方案以后，再让它帮你落到项目里。
正式跑稳之后，还要把当前这一版封成正式的生产版本，具体怎么封，后面讲版本管理时再说。
有了明确的生产版，回滚才有落点。
三是，让服务在重启后能自己爬起来。
这条特别容易被漏掉。
AI 帮你部署时，多半只是把服务当场跑起来，顶多配了“崩溃了自动重启”。
可它经常忘了另一件事：服务器整个重启之后，你的后端、数据库能不能自己起来。
服务器为什么会重启？欠费恢复、厂商维护、系统更新，甚至半夜崩一次，都可能。
真到那时候，要是没设开机自启，机器是回来了，你的网站却还躺着，你还蒙在鼓里。
所以部署完，一定要确认一件事：这台服务器重启一次，所有服务都能自动回来。
用面板的，一般能在进程或服务设置里勾上开机自启。
用 Docker 的，让 AI 把容器的重启策略配好。
自己原生装的，就让 AI 帮你配成开机自启。
如果项目还没正式上线，可以直接重启验证。
已经在生产环境运行，就别为了测试随手重启。
先做好备份和恢复准备，再选用户少的维护时间验证。
三、数据一定要备份
用户数据，是底线中的底线。
操作会失误，服务器账号可能被攻破，AI 也可能一条命令就把数据删错。
一旦数据没了，很多时候是找不回来的。
数据库一旦被攻击者加密或者删除，对方留下的赎金信息，也不代表数据真的能恢复。
所以，数据一定要定期备份。
但备份以前，先让 AI 根据你的真实部署，把需要长期保留的东西完整列一遍。
数据库、用户上传的图片和文件、程序长期保存的其他数据，还有恢复时必须用到的关键配置，分别放在哪里。
这些才是需要备份的完整对象，不能只盯着数据库。
带着密码和密钥的配置，还要加密保存，不能直接丢进普通网盘。
多久备份一次，要看你最多能接受丢掉多久的数据。
如果最多只能接受丢一天，就至少每天备份一次。
备份对象和频率定好以后，还有两个关键。
第一，备份别和原数据放在同一块硬盘上。
你把备份就存在这台服务器上，一旦服务器被入侵、误重装或者整台实例被删，原数据和备份可能一起没。
正确的做法是放到别处去，比如另一台机器，或者专门的云存储。
原数据和备份，不能一起“陪葬”。
第二，备份完，一定要真的试一次恢复。
有一份备份文件，不代表它一定能恢复——文件可能是坏的、可能是不全的。
你不趁没事的时候真走一遍恢复流程，等真出事那天，才发现备份根本用不了，那就彻底完了。
用面板的，定时备份基本点几下就能配好，别嫌麻烦，这是保命的。
不用面板的，同样让 AI 带你配，记得把上面这两条要求一起提给它。
四、别让证书、域名悄悄过期，该更的补丁也别拖
有几样东西是有“保质期”的，到点不管，网站照样出事。
一个是域名，按年续费，过期了网站直接打不开，过期久了还可能被释放、被别人注册走。
一个是 HTTPS 用的那张 SSL 证书，也有有效期，过期了浏览器就会给用户标“不安全”。
免费证书很多能自动续，但也有些付费证书或特殊配置得你自己盯着，别默认觉得一劳永逸。
域名和证书这两样，面板大多能设到期提醒，记得提前打开。
还有一样也卡时间，最容易漏：网站完成 ICP 备案、正式开通以后，要检查公安联网备案有没有办。
官方要求是网络正式联通之日起 30 天内办理，具体入口和材料按照当地公安机关的办事指南准备。
另外还有一样，是补丁。
你用的那些框架、SDK，还有服务器上的系统本身、面板、数据库这些服务软件，都是别人写的代码。
时不时会爆出安全漏洞，官方会发新版本来修。
麻烦的地方在于：一个漏洞一旦被公开，全世界的攻击者也都跟着知道了。
那些没及时更新、还停在老版本上的服务器，就成了明摆着的靶子。
所以标着“安全更新”的，往往修的是要紧的漏洞，别拖着。
但反过来，升级也不能盲目。
有些升级——尤其是跨大版本的——可能跟你现在的项目不兼容，升完反而把原本好好的功能搞坏。
这里头最容易踩雷的，是数据库的跨版本升级：你项目里原本跑得好好的语句，升完可能就报错了。
所以动手前先搞清楚：这次升级到底解决什么问题、会不会影响我现在的项目。
你自己拿不准，就把项目情况告诉 AI，让它帮你分析该不该升、有什么风险、要不要先备份，确认清楚了再动手。
分析清楚以后，也别直接在生产服务器上升级。
先在开发或者测试环境里更新，跑一遍关键功能。
确认项目正常，再记下生产环境当前使用的版本、准备怎么退回去。
非必要不要一次更新多个关键组件。
这样真出了问题，至少知道是哪次升级造成的，也还有退路。
五、别让账单在你不知不觉中失控
还有一样，很多人上线后完全没设防，那就是账单。
有两种翻车，都很真实。
一种，是你的密钥被盗刷。
AI 密钥、支付密钥一旦泄露，机器人几个小时就能扫到，拿去疯狂调用，账全记你头上。
等你发现，账单已经很吓人了。
另一种，是流量费。
很多云服务器是按用量付费的，万一被人恶意打流量、或者被当成跳板，用量会悄悄飙上去，月底给你来一张天价账单。
这两样的共同点是：都在你看不见的地方一点点累积，等你收到账单，才追悔莫及。
所以上线后，顺手做两件事：
一是，去你云服务商的后台，把消费预警打开，花到某个数就发消息通知你，别等钱扣完才知道。
二是，去 AI、短信这些按调用量收费的平台，把用量提醒打开。
再检查平台有没有真正的硬额度、调用限速或者超额自动停用。
有就配上。
如果只有预算提醒，超过以后可能还会继续扣费，别把那个数字当成保险丝。
这块面板管不了，得去云服务商和对应服务的后台设，让 AI 告诉你具体在哪里点就行。
六、加新功能，别在线上瞎改
上线之后，你肯定还要继续加功能。
这时候千万别图快，直接让 AI 在线上正式环境里乱改。
正确的做法很简单：先把这次要改什么写清楚，按阶段一步步推。
本地测好，确认没问题，再更新到线上。
你也可以让 AI 先根据你的目标，写一份简短的实施说明，你确认了再动手改代码。
防漂移那一套规矩——别让 AI 悄悄改歪需求——上线之后照样得守，甚至更要守，因为现在是真有用户在用了。
开发流程篇里讲得更细，这里你先把这条底线抓住就行。
七、把版本管好
最后，Git 版本管理要用起来。
每一个版本都管好，你才能随时回退、随时看清楚改了什么。
这个我在立项补充篇里也提过，到了上线阶段，它就更重要了。
部署成功、线上跑稳之后，一定要把当前这一版封存成一个正式的生产版本。
后面如果要加新功能，就从这个版本拉一条新分支继续开发，别直接在生产版本上边跑边改。
如果只是这个版本上修 bug、解决小问题，就再从这个正式生产版本衍生出一条修复分支。
新功能走新分支，修问题走修复分支，线上正在跑的那一版始终有据可查、随时能回退。
落地时，让 AI 按这三步在你的仓库里给出具体方案：怎么封存生产版、怎么开新功能分支、怎么开修复分支。
你确认以后，再让它执行，别一上来就乱建乱删。
八、让 AI 给你整理一张维护清单
前面这些事，不能每次都靠你临时想起来。
最简单的办法，是让 AI 根据你的真实项目，整理成一张能长期照着做的维护清单。
你可以这样对它说：
“请先只读检查当前项目、部署文档，以及我已经提供的生产环境信息，不要自行连接或者修改生产服务器。根据项目真实情况，整理一份上线后的基础维护清单，按照日常检查、定期检查、每次上线前后和发生故障时分类。每一项写清楚要检查什么、去哪里看、出现什么情况需要处理，以及下一步应该先收集什么证据。不要直接套用通用模板，无法从当前项目确认的内容单独列出来问我。完成后先给我确认，不要直接执行任何生产环境操作。”
这张清单不用把专业运维的所有工作都塞进去。
只要能让你知道平时该看什么，出了问题先做什么，就已经有价值。
清单里哪一条你没看明白，就让它对着你自己的项目，用大白话再拆一遍。
以后部署方式、服务器或者项目结构变了，也让 AI 跟着更新。
九、最后
到这里，整个部署篇就讲完了。
从环境、上线前体检，到部署方式和服务器安全，再到上线之后最基础的维护，该守的底线都过了一遍。
你不懂写代码，也没学过专业运维，没关系。
这篇讲的几件事，本来就不是要把你变成专业运维，更不可能代替专业团队。
专业运维需要处理的，远远不止这一篇讲到的这些。
但对个人项目和刚起步的产品来说，你至少能在网站挂掉时及时知道，数据丢失时有机会恢复，更新翻车时能够退回去，费用异常时提前收到提醒。
这已经能帮你避开很多本不该发生的灾难。
等项目有了稳定用户、真实收入，或者保存着重要数据，再让专业人员介入关键运维。
你现在要做的，不是一下学会所有运维。
而是别让项目上线以后，就彻底失去照看。
