小团队小程序服务器运维实录

做了几年小程序外包，交付之后最怕听到的一句话不是“有 bug”，而是“服务器又挂了”。前者改代码就行，后者往往意味着半夜爬起来看日志、重启服务、临时扩容，第二天还得给客户写事故说明。这篇文章不讲大道理，就聊聊我这两年在小程序服务器运维上踩过的坑和最后沉淀下来的做法，主要面向和我一样两三台机器、预算有限的小团队。

先想清楚：你的小程序真的需要“服务器”吗

很多项目一开始就上云服务器、装 Nginx、配数据库、写 Dockerfile，其实没必要。我接过一个预约类小程序，日活不到两百，业务逻辑就是查列表、提交表单、发个订阅消息。这种量级用云开发的云函数加云数据库完全够，运维成本接近于零，也不用操心证书续期、系统补丁这些东西。

判断标准我一般看三条：

• 有没有需要长时间运行的后台任务，比如视频转码、大批量导出；
• 数据是否需要和已有系统做复杂联表查询；
• 客户是否明确要求数据放在自己的服务器上（政企类项目常见）。

三条都不占，就别折腾服务器了。省下来的时间拿去优化首屏加载，收益比调服务器参数大得多。

监控：别等用户来告诉你挂了

我吃过最惨的一次是数据库连接池被打满，接口全部超时，客户在群里 @ 我时已经过去了四十分钟。从那以后，任何项目上线前我都会做三件事：

1. 健康检查接口

写一个极简的 /health，只做一件事：查一次数据库并返回 200。用第三方监控平台（UptimeRobot、阿里云云监控都行）每分钟探一次，挂了立刻发短信。

app.get('/health', async (req, res) => {
  try {
    await db.query('SELECT 1');
    res.status(200).json({ ok: true });
  } catch (e) {
    res.status(500).json({ ok: false });
  }
});

2. 关键错误主动上报

不要只依赖控制台日志。Node 服务里挂上 unhandledRejection 和 uncaughtException，把堆栈推到告警群。小程序端也用 wx.onError 收集一下，很多问题只有真机才复现。

3. 慢查询和慢接口记录

在请求中间件里记一下耗时，超过 1 秒的打条日志。上线一个月后回头看，往往能发现几个拖后腿的接口，优化掉之后整体体验提升很明显。

部署：能自动化就别手动

早期我图省事，本地打包、scp 上传、ssh 上去重启，结果有一次传了一半网络断了，服务起不来，回滚又找不到上一版包。现在固定用一套很土但可靠的流程：

• 代码推送到 Git 仓库，打 tag；
• CI 里跑测试、构建镜像，推到镜像仓库；
• 服务器上执行拉取和重启脚本，保留最近三个版本；
• 重启后自动请求一次健康检查，失败就回滚到上一个 tag。

这套流程用 GitHub Actions 加一个几十行的 shell 脚本就能搭起来，不需要 K8s。小团队上 K8s 的维护成本远大于收益，除非你本来就很熟。

成本控制：别让账单吓到自己

服务器运维不只是技术活，也是算账的活。几个我常用的省钱手段：

• 带宽按量付费，图片和静态资源全部走对象存储加 CDN，别让服务器扛流量；
• 数据库选按配置计费的小规格，配合慢查询优化，大多数项目 2 核 4G 就够；
• 日志定期清理，别让磁盘被日志撑爆，我一般保留 7 天；
• 非核心服务（比如后台管理）放到低配机器上，和主接口隔离。

另外提醒一句，云厂商的包年包月和按量计费价格差得挺多，新项目上线前先估算流量，别一上来就买高配。有一个客户的项目，我接手时每月服务器账单是八百多，梳理完发现一半花在闲置的负载均衡和没关的测试环境上。

备份和回滚：出事时唯一能救命的东西

数据库每天自动备份，这个不用多说。我想强调的是恢复演练。备份文件能不能用，只有真恢复一次才知道。我现在的习惯是每个季度挑一个项目，在测试环境把备份导入一遍，确认数据完整。听起来麻烦，但真出事的时候，这几分钟的准备能让你少掉很多头发。

还有一点，配置文件和环境变量不要只存在服务器上。我见过有人服务器重装后，发现数据库密码只记在自己脑子里。用密码管理工具或者加密仓库存一份，团队里至少两个人有权限。

写在最后

小程序服务器运维这件事，说到底不是追求多先进的架构，而是让系统在你看不见的时候也能稳稳跑着。监控到位、部署可回滚、成本可控，这三条做到，大部分事故都能提前发现或者快速恢复。剩下的精力，留给业务和代码本身，那才是真正创造价值的地方。