单机到云平台的演进路径
绝大多数系统不是一开始就上多区域、高可用、Kubernetes。它们通常从一台机器起步，然后逐渐长复杂。
常见演进路线
graph LR
A[单机开发环境] --> B[VPS/云主机]
B --> C[Nginx + App + DB]
C --> D[分离数据库/对象存储]
D --> E[容器化]
E --> F[多实例/负载均衡]
F --> G[更复杂平台]
每一步增加了什么能力
| 阶段 | 新能力 | 新代价 |
|---|---|---|
| 单机 | 快速试错 | 不稳定 |
| VPS | 可公网访问 | 需自己运维 |
| 分层部署 | 更清晰 | 配置更多 |
| 容器化 | 环境一致 | 学习成本 |
| 多实例 | 更稳 | 监控和发布更复杂 |
什么时候不该往上升维
- 单机问题都没解决时，不该急着上集群
- 还没有自动备份时，不该先搞服务网格
- 团队只有 1-2 人时，不该复制大厂架构
# 一个很好的自检问题
echo "如果现在服务挂了，我能在 15 分钟内恢复吗？"
真实案例：一个团队的三年演进
背景：某 4 人技术团队，运营一个 SaaS 产品，从零开始到月活 10 万用户。
阶段一（第 1–6 个月）：手动部署时代
服务器：1 台 VPS（4 核 8G）
部署方式：SSH 登录 → git pull → 手动重启
备份方式：无
监控方式：收到用户投诉才知道挂了
某天凌晨，CTO 改了一行 SQL 字段名，手动部署后发现数据库查询全部报错。因为没有备份，花了 4 小时从代码里反推旧数据结构，恢复到凌晨 5 点。
阶段二（第 7–18 个月）：脚本化 + 基础监控
改进：写了 deploy.sh（5 步固定顺序 + 健康检查）
改进：Cron 每日 pg_dump + rclone 上传 S3
改进：UptimeRobot 每分钟 HTTP 检查，挂了发 SMS
结果：凌晨宕机从"用户告知"变成"自动告警 5 分钟内知道"
阶段三（第 19–36 个月）：CI/CD + 容器化
改进：GitHub Actions 自动化部署 + 回滚
改进：Docker Compose 管理 web + db + redis
改进：迁移到 AWS，EC2 + RDS（托管数据库，备份自动化）
团队：仍然 4 人，运维时间从每周 8 小时降到 1 小时
关键教训： 每个阶段的升级都是被当前的最大痛点驱动的——不是因为听说了新技术，而是因为现有方式已经无法支撑。
本节结论
你的第一目标不是“像大厂”，而是：
- 先把一台 Ubuntu 机器运维扎实
- 再把部署、监控、恢复做成可重复流程
- 最后才去看多实例和多云变体
本节执行清单
- [ ] 列出你当前处于哪一个基础设施阶段
- [ ] 写出下一个阶段真正要解决的问题
- [ ] 删除一个目前对你来说过早的复杂设计
下一章：Ubuntu 服务器初始化——从一台干净机器开始。