从'能上线'到'能稳定运行'：新手最容易漏掉的环节

部署这件事，新手通常理解为：代码传上去、服务能跑起来、网页能打开就算成功了。

我见过太多这样的例子：凌晨三点网站崩了，当事人翻遍服务器找不到日志；被攻击了完全不知道，直到收到云服务商的通知邮件；数据库被删了才发现从来没做过备份。

“能上线”和”能稳定运行”之间，隔着好几层你可能根本没想过的事情。

监控：你不知道它什么时候崩的

服务跑起来了，但什么时候开始变慢、什么时候开始报错，你一无所知。

你需要的是基础监控，关注三个指标就够了：CPU 使用率、内存使用率、磁盘使用率。超过 80% 就该注意，超过 90% 基本要出事。

萤光云这类云服务商一般会在控制台提供基础的监控面板，开机就有。但如果你想做得更细，可以用 Prometheus + Grafana 搭一套轻量级的监控系统，服务器上装一个 node_exporter，图形化展示服务器状态，一目了然。

应用层的监控也很重要：接口响应时间、错误率、在线人数。直接用开源的 Grafana Loki 或者付费的阿里云 ARMS 都行，看你的预算。

网站挂了，想查原因，结果日志没有、或者日志全存在容器里删容器就丢了。这种情况我见过不止一次。

日志一定要落盘到服务器本地，不要存在容器内部。Docker 启动的时候加一个参数：

docker run -d -v /data/my-app/logs:/app/logs -p 3000:3000 my-app

日志文件定期轮转也很重要，不然有一天会发现日志文件把磁盘塞满了。Linux 自带的 logrotate 就能解决这个问题，配置一下每天或者每个文件超过 50MB 就自动切分压缩。

数据丢了是什么感觉？经历过的人都懂。没经历过的，希望你别经历。

数据库要定期备份。MySQL 举例，每天凌晨三点自动跑一个备份脚本：

mysqldump -u root -p'密码' --all-databases > /data/backup/db_$(date +%Y%m%d).sql

备份文件也要定期清理，只保留最近 30 天的，超过就删掉。备份文件建议传到另一台机器或者对象存储上，不要和数据库存在同一台服务器——服务器一起挂就全完了。

萤光云现在有快照功能，可以给整台服务器做快照，成本不高但关键时刻能救命。

云服务器上线第一天，就会收到各种扫描和尝试登录的日志。开放 22 端口（SSH）和 3306 端口（MySQL）到公网，基本等于裸奔。

安全上一定要做的几件事：

第一，SSH 密钥登录，禁止密码登录，改掉 22 端口。

第二，防火墙只开放必要的端口。Web 服务开 80 和 443，SSH 开你改过的那个端口，其他一律关掉。

第三，应用层面的攻击也要防。Nginx 配置一下限流，防止一个人疯狂请求把服务器打挂。

第四，定期更新系统补丁。Linux 的 apt update && apt upgrade 每个月跑一次，不麻烦。

服务器断电、维护重启、云服务商迁移机器，你的服务还能自动起来吗？

Docker 容器默认不会开机自启，需要在启动命令里加一个参数：

docker run -d --restart=always -p 3000:3000 --name my-app my-app

–restart=always 的意思是服务器重启之后，容器自动启动。systemd 的服务也可以配置开机自启，但如果业务全在 Docker 里，Docker 的 restart 策略就够用了。

说完这些，有人会觉得：自己搭监控、日志、备份、安全这套体系好麻烦。

其实萤光云现在有一些现成的运维工具可用，比如控制台自带的监控告警、快照备份、安全组配置。相比自己从零搭，选择成熟的云服务商能省不少运维的精力——至少半夜报警的时候有个工单系统可以走。

业务上了规模之后，这些运维工作会越来越复杂，但在初期先把监控、日志、备份、安全、自启动这几件事做好，已经超过大多数新手了。

部署这件事，代码能跑只是第一步。真正的考验是：半夜崩了你能不能快速定位，出了事故你有没有东西可查，数据丢了有没有办法恢复。

这些问题想清楚了，稳定运行才算真正开始。