小项目上云后最容易被忽略的三件事：备份、日志与健康检查

很多小项目上线时的样子都很像：一台云服务器、一个 Nginx、一份刚部署好的代码，浏览器一打开能访问，就算是“上线成功”了。真正的问题往往不在上线那一刻，而在上线之后的两三个月：某天早上发现服务挂了，却不知道它是什么时候挂的；想回滚，才发现没有可用的备份；想定位问题，日志早就被新内容冲掉了。下面这三件事成本都不高，却是小项目长期稳定运行的底线。

一、备份：先保证能恢复，再谈备份频率

备份最容易犯的错误，是把备份文件和原数据放在同一台机器、同一个目录里。机器磁盘一坏、误操作一删，两边一起没了，这样的备份等于没有备份。对小项目来说，可行的最低标准是三条：备份要离线，至少有一份放在本机之外的对象存储或另一台机器上；备份要定期自动跑，靠人想起来手动备份迟早会断；备份要真的恢复过一次，至少在测试目录里演练一次解压和导入流程，确认文件不是空的、数据库能正常打开。

具体做法不必复杂：数据库每天凌晨用系统自带的导出工具导一份，压缩后按日期命名，上传到对象存储并设置 30 天的过期规则；应用代码和配置文件则用版本控制管理，服务器上的运行版本永远对应某一个可查到的提交记录。这样即使某天服务器需要重建，恢复流程也是确定的几步，而不是凭记忆拼凑。

二、日志：只记有用的，并且要轮转

日志有两个极端都不好：一个是什么都不记，出问题只能靠猜；另一个是什么都记，磁盘几天就被日志写满，最后服务因为磁盘满而挂掉。合理的日志策略是分级：正常请求只记关键字段，错误和异常必须记完整堆栈和当时的请求参数，调试级别的详细输出只在排查时临时开启，排查完立刻关掉。

更重要的是轮转。Linux 上用 logrotate 这类现成工具，给每个服务的日志设好按天切割、保留 14 天、压缩旧文件、超过上限自动删除，基本可以做到一劳永逸。还有一个容易被忽略的点：日志里不要打印密码、令牌、身份证号这类敏感信息。很多泄露事故不是被攻击打穿的，而是日志文件本身被误发、误传造成的，写日志时先过一遍“这行如果公开出去有没有问题”，能省掉很多事后补救。

三、健康检查：等用户告诉你挂了，就已经晚了

没有健康检查的服务，故障发现方式只有一个：用户来反馈。而用户反馈到达你这里时，往往已经过去了很久。最简单的健康检查不需要任何监控平台：给应用加一个轻量的健康接口，只返回运行状态和关键依赖是否连通；再用一台外部机器或免费的定时检测服务，每隔几分钟请求一次这个接口，连续两次失败就发一条提醒。

健康检查的设计也有讲究：它应该只检查“服务能不能正常对外提供服务”，而不是把所有内部细节都暴露出来；检查频率要合理，太密会给服务增加无谓负担，太稀则发现延迟太长。对小项目来说，五分钟一次、失败两次再告警，是一个兼顾及时性和误报率的起点。告警通道同样要简单可靠，邮件或即时消息能收到就行，不要把告警本身做成另一个需要维护的复杂系统。

把三件事串成上线清单

项目每次上线或迁移服务器时，按这张清单过一遍：备份任务是否已自动跑、恢复流程是否演练过；日志是否分级、是否轮转、是否排除了敏感字段；健康检查接口是否已部署、外部检测是否已开启、告警是否能收到。清单上的每一项都不需要花钱、不需要引入新平台，却能在关键时刻把一次“不知道什么时候坏的、恢复不了的”事故，变成“几分钟内发现、一小时内恢复”的普通事件。

小项目的稳定运行从来不是靠某一次精心的部署，而是靠这些不起眼但持续运转的兜底机制。把备份、日志和健康检查先做到位，再去追求性能优化和功能迭代，顺序对了，后面的路会稳得多。