5.6 DevOps for One

个人版的持续部署

我在 4.2 节讲过 DevOps 和 CI/CD 的基本概念。但你可能会想："那些是针对团队的，我一个人需要 CI/CD 吗？"

答案是：需要，但可以比团队版本轻得多。

团队级的 CI/CD 有一整套流程：代码提交后运行自动化测试 → 构建 → 部署到测试环境 → 部署到预发环境 → 部署到生产环境。每一步都有自动化门禁。这很完善，但你一个人跑不动这套流程。

你的 "DevOps for One" 的版本是：代码修改后一键上线。

这个"一键"的核心是：

部署自动化（不是运维自动化）

一人公司的重点是"部署自动化"——代码改完能快速上线——而不是"运维自动化"——自动扩容、自动降级、自动故障恢复。后者的复杂度太高，你的产品早期用不上。

部署自动化的最低配置：

GitHub + Vercel（或者 Railway/Cloudflare） 是最简单的一键部署方案。配置好之后的工作流程是：

1. 你在本地写代码，测试通过
2. git add . + git commit -m "描述本次改动" + git push
3. Vercel 自动检测到代码更新，拉取代码，构建，部署

就这么简单。Git push 之后等一两分钟，你的新版本就上线了。全程不需要登录服务器、不需要手动上传文件、不需要重启进程。

这个流程和团队级的 CI/CD 核心区别在于：你没有自动化测试门禁。 代码改动不会因为"测试没通过"而被阻止上线——因为你根本没有自动化测试。这就是一人公司需要接受的现实：你跑得很快，但你不能保证每次上线都是"完美的"。你需要接受偶尔的小 bug 会漏到生产环境这个"风险"——然后通过"快速修复"来弥补。

数据库的 CI/CD

代码的部署有 Git push 自动触发解决了。但还有一个问题：数据库的变更怎么管理？

在团队中，数据库变更（比如加一个字段、改一个表结构）要走专门的流程——编写迁移脚本、评审、测试环境验证、生产环境执行。对一人公司来说，这个流程需要精简到极致。

几个方法：

方法一（推荐）：通过 ORM 的同步功能。 很多现代开发框架提供"自动同步数据库结构"的功能——你改代码中的模型定义，框架自动帮你修改数据库。比如 Prisma ORM 的 prisma db push 命令可以直接把模型变化同步到数据库，你不需要写迁移脚本。

方法二：用 Supabase 的 Web UI。 Supabase 提供了图形界面管理数据库表结构。你要加一个字段，打开网页，点几下鼠标就完成了。不需要写任何脚本。

方法三：写迁移文件并提交到代码仓库。 如果你的应用已经有一定规模了（几百个付费用户以上），可以考虑写迁移脚本。你在本地加好字段，生成迁移脚本，提交到代码仓库，部署时自动运行。

从方法一到方法三，随着你的产品规模增大，你需要的过程形式越来越"重"。一开始用方法一就够，什么时候觉得"不够安全了"再升级到方法二或方法三。

监控和告警

一个人运维需要知道的一件事："如果出问题了，我怎么能最快知道？"

你不能依赖用户告诉你说"你的产品崩了"——那通常是在你已经损失了若干用户之后你才知道的。

最小的有效监控：两个维度。

维度一：可用性监控。 你的网站能不能正常打开？这个最简单——用 Better Uptime 或 Pingdom 之类的服务。它们每隔几分钟访问一下你的网站，如果打不开了，给你发一封邮件或一条短信。免费计划够用了。配置过程不超过 5 分钟——输入你的网址，设置告警方式。

维度二：错误监控。 用户在使用中遇到了报错，你能看到吗？用 Sentry。它的免费计划适合一人公司。在应用中引入 Sentry 的 SDK（AI 可以帮你做这个配置），之后的代码报错会自动上报。你不需要用户来告诉你"我遇到了一个错误"——你可以在 Sentry 的后台看到错误堆栈，甚至知道用户是在什么操作下遇到这个错误的。这比"用户发了一个截图说报错了"要高效太多了。

这两个监控工具配置好之后，你可以放心地关掉编辑器去睡觉。如果半夜出了事，你的手机会收到通知——你再决定要不要爬起来修。

这里有一个心态问题需要注意：刚开始你可能会被 Sentry 里的错误数量吓到——打开一看几百个错误记录。不要慌，大部分是"已知但无害"的错误——比如某个第三方服务偶尔超时、某个用户的网络中断导致请求失败。你需要关注的是"影响用户使用的错误"，不是"日志里出现的每一条报错信息"。

故障处理流程

万一真的出了故障，你的处理流程应该是：

1. 确认影响范围：是全部用户都受影响，还是部分？是核心功能（支付、登录）挂了，还是边缘功能（头像上传）挂了？AI 可以帮你分析："我的 Sentry 里有这个错误，影响范围大概多大？"
2. 快速修复：把报错贴给 AI，让 AI 生成修复代码。不要在这个阶段追求完美——先恢复服务，再慢慢优化。
3. 回滚（如果需要）：如果修复太复杂，直接回滚到上一个版本。git revert 加 git push——Vercel 自动部署回旧版本。这个过程应该不超过 5 分钟。
4. 事后总结：故障恢复后，用 AI 帮你分析根本原因。"这次故障的根本原因是什么？怎么防止再次发生？"——AI 可以帮你分析代码和日志，给出预防建议。

一人公司的"高可用"策略

"高可用"这个词听起来很技术。但它对一人公司的实际意义只有一个：如果你的产品在某个时间点暂时不能用了，会有什么后果？

诚实回答这个问题，决定了你需要花多少精力在可用性上。

• 如果你做的产品是"给朋友用的内部工具"——服务挂了半天也没什么大不了的。你不需要做高可用。
• 如果你的产品是"面向 C 端的免费工具"——挂了几个小时，用户可能去用竞品了。你需要尽快修复，但不需要"零宕机"。
• 如果你的产品是"处理企业客户数据的 SaaS"——挂了 30 分钟，客户可能就不续费了。需要考虑简单的冗余和灾备方案。

三人公司的高可用策略就是在"影响了多少钱"和"花多少钱来防止"之间找到平衡点。一个人不需要追求 99.999% 的可用性（一年宕机不超过 5 分钟）——那是大公司才需要做的事情。你可以接受偶尔的短期宕机，只要你的响应和修复速度足够快。

核心思想：信任自动化，信任 AI

"DevOps for One"的核心思想是：尽可能自动化部署、监控、告警流程，让一个人可以睡个好觉。

你不需要成为运维专家，只需要理解几条基本规则：

• 代码 push 就能上线（自动化部署）
• 网站挂了你能收到通知（自动化监控）
• 你可以在手机上修复简单问题（远程修复能力）
• 复杂问题恢复稳定后再做根本原因分析（响应不是修复）

这四条全部可以借助 AI 完成。你不会配置 CI/CD？问 AI。你不会配 Sentry？问 AI。你不知道怎么分析错误原因？把错误贴给 AI。

你不需要成为 DevOps 专家才能做一人公司——你只需要知道"出了问题该怎么做"，然后让 AI 帮你解决具体的技术细节。