- 学习结果
- 有一份上线检查表和一份故障处理清单：知道日志在哪里、备份能不能恢复、出问题时先查哪一层、怎样回到上一个可用版本。
- 时长
- 2-3 小时
- 难度
- 经验分享
- 核验
- 已核验 2026-10-01 · 下次复核 2026-10-31
正文
小产品出事故，很少是因为流量太大，更多是自己造成的：一次部署带上了错误的配置，一个测试环境的脚本连到了正式数据库，或者数据库出了问题，才发现从来没备份过。
这些问题大多可以提前准备。这篇按上线前后的顺序，讲部署、环境变量、排查、监控、备份和回滚各要准备什么。
部署：上线的是构建产物，不是源码
部署的不是你写的源码，而是构建之后生成的文件。静态站点部署的是构建输出目录；有服务器端逻辑的项目，还需要对应平台的运行适配。部署前先弄清三件事：构建命令是什么、输出目录在哪里、需要哪个版本的运行环境。
本地开发服务器能打开，不代表线上能正常工作。开发服务器常常会替你做一些容错，比如自动处理路径，线上不会。安装依赖、构建、发布这三步的结果要分别检查。
大多数托管平台会为每次提交生成一个预览地址，先在预览环境里检查，再发布到正式环境。
环境变量：分清公开和机密
配置分两类：浏览器可以看到的（比如统计代码的 ID）和必须保密的（数据库管理员密钥、邮件服务令牌、支付私钥）。机密配置只能在服务器端使用，绝不能打包进前端代码。
预览环境和正式环境要分开配置，否则测试时可能给真实用户发邮件，或者把测试数据写进正式数据库。.env 这类存放密钥的文件不要提交到代码仓库。密钥泄露或人员变动时要及时更换，更换前先想清楚有哪些服务依赖它。
出问题时，按层排查
线上出问题时，最忌讳的是凭感觉到处改，尤其是一出问题就去改 DNS，很可能让影响扩大。按从外到内的顺序，一层层排除：
- 域名解析：域名是否指向了正确的服务？
- 证书和连接：HTTPS 证书是否有效？能否建立连接？
- 平台和路由：最新一次部署成功了吗？请求的路径有没有对应的页面？
- 前端：页面能打开，但交互异常，就看浏览器控制台的报错；图片 404 通常是资源路径问题。
- 服务器端函数：接口返回 500，看函数日志。
- 数据和外部服务：数据库连接、第三方服务是否正常。
每排除一层，就记下来，避免重复检查，也方便事后复盘。
监控：围绕用户真正要做的事
监控的目的是在用户告诉你之前发现问题。从最关键的用户任务出发设置：
- 可用性检查：定时访问首页和最关键的接口（比如登录、提交表单），失败就提醒你。
- 错误追踪：前端和服务器端的报错集中收集，记录时间、请求标识和错误类型。Sentry 这类工具可以做到。
- 日志：静态资源、前端脚本和服务器端函数的日志往往在不同的地方，提前弄清楚每一类去哪里看。
日志里不要记录完整的个人信息、密码和付款信息。告警要能指向一个具体的排查动作，比如“提交接口错误率超过 5%，先看函数日志”；只会响、不知道该干什么的告警，很快就会被忽略。
备份：没恢复过的备份不算备份
代码在 Git 里，不代表数据也有备份。需要备份的东西有四类，各有各的保存方式：
- 代码：Git 仓库，最好有一个远端副本。
- 数据库：用户数据、订单等。
- 用户上传的文件：头像、附件，通常在对象存储里。
- 配置：环境变量、域名设置、第三方服务的配置。
不要默认托管数据库会替你备份。以 Supabase 为例，它的官方文档说明，自动每日备份覆盖的是付费套餐，不同套餐的保留天数也不同；免费套餐的项目，官方建议定期用命令行导出数据，并在别处另存一份。
图：Supabase Database Backups 官方文档页面截图，截取于 2026-10-24，内容以官方当前页面为准。
备份多久做一次，取决于你能接受丢失多少数据：能接受丢一天，就每天备份；一小时都不能丢，就需要更细的方案。最重要的一点是定期演练恢复：在一个隔离的环境里，用备份恢复一份数据，确认真的能用。只看到备份文件存在，不能证明它能恢复。
回滚：代码和数据要分开考虑
很多托管平台支持一键回到之前的某次部署，比如 Cloudflare Pages 的回滚功能。但回滚代码不会撤销数据库的改动。如果新版本修改了表结构，回到旧版本的代码，可能和新的表结构不兼容。
所以修改表结构时，尽量分步进行：先加新字段，新旧代码都能运行；确认新版本稳定后，再删除旧字段。这样任何时候回滚代码都是安全的。
出事故时的顺序
- 先止损：回滚到上一个稳定版本，或者暂时关闭出问题的功能，阻止影响继续扩大。
- 记录时间线：什么时候发现、做了什么、最后一个正常的版本是哪个。
- 恢复后再分析原因：写一份简短的复盘，重点是以后怎样避免，而不是追究责任。Google 的 SRE 实践把这叫作“无责复盘”。
一个人运营的产品也值得有一份故障处理清单：包括各个后台的入口、日志的位置、回滚的步骤，以及出问题时怎样告诉用户。
学习步骤
- 写下项目的构建命令、输出目录和运行环境版本，确认预览环境可用。
- 列出所有环境变量，标出公开和机密，检查机密配置没有进入前端代码。
- 按六层排查顺序，写下每一层去哪里看、看什么。
- 为首页和最关键的接口设置可用性检查，接入错误追踪。
- 列出四类需要备份的东西，写清各自的方式和频率，并做一次恢复演练。
- 写一份故障处理清单：止损步骤、回滚方法、日志位置和对用户的通知方式。
场景拆解
上线后接口突然全部报错
小许的目录站在周五晚上部署了一个新版本，半小时后收到告警：投稿接口的错误率是 100%。
- 先止损：他没有急着排查，先在平台上把部署回滚到上一个版本，投稿恢复正常。
- 按层排查：首页正常，说明域名、证书和路由没问题；浏览器控制台显示接口返回 500，于是去看函数日志。
- 找到原因：日志显示“数据库连接失败”。新版本引用了一个新的环境变量名，但他只在预览环境里配置了，忘了在正式环境里添加。
- 修复：在正式环境补上配置，重新部署，逐项检查投稿流程。
- 复盘：在上线检查表里加了一条“对比预览和正式环境的变量列表”。
整个过程投稿只中断了二十分钟。关键是先回滚止损，而不是在线上一边出错一边调试。
补充材料
思维导图、练习、清单和参考资料可按需展开。
01 思维导图和离线文件
适合读完后下载到自己的知识库里继续整理。
上线前准备
- 确认构建命令和输出目录
- 区分公开和机密配置
- 预览和正式环境分开
监控和排查
- 可用性检查和错误追踪
- 按层排查，从域名到数据库
- 日志不记录敏感信息
- 告警指向具体动作
备份和回滚
- 代码、数据库、上传文件、配置
- 定期演练恢复
- 先止损再分析
- 表结构分步修改
02 实践练习
根据文章内容记录自己的判断与依据。
为你的项目做一次上线准备
为你已经上线、或准备上线的项目，完成上线检查表和故障处理清单。
准备材料
- 项目的部署平台和数据库后台的访问权限。
- 一个可以用来测试恢复的隔离环境。
练习步骤
01 / 整理部署和配置
时间： 30 分钟
操作：
- 写下构建命令、输出目录和运行环境版本。
- 列出全部环境变量，标出公开和机密，对比预览和正式环境。
产出： 部署说明和环境变量清单。
检查： 机密配置没有出现在前端代码和代码仓库里。
02 / 设置监控
时间： 40 分钟
操作：
- 为首页和一个关键接口设置可用性检查。
- 故意触发一个错误，确认你能在错误追踪或日志里看到它。
产出： 一份监控和日志位置清单。
检查： 收到告警时，你知道第一步该做什么。
03 / 演练备份恢复和回滚
时间： 60 分钟
操作：
- 导出一份数据库备份，在隔离环境里恢复，检查数据是否完整。
- 在预览环境或测试项目里练习一次回滚。
产出： 恢复演练记录和故障处理清单。
检查： 记下了恢复用了多长时间、遇到了什么问题。
完成检查
- 知道每一层故障去哪里查。
- 备份至少成功恢复过一次。
- 有一份可以直接照着做的故障处理清单。
03 清单、模板和关键词
用于项目记录和自查。
上线检查表
- 构建命令、输出目录和运行环境版本已确认
- 预览环境检查通过
- 正式环境的变量与预览环境逐项对比过
- 机密配置不在前端代码和仓库里
- 首页和关键接口有可用性检查
- 错误追踪已接入，日志位置已知
- 数据库、上传文件、配置都有备份方式
- 最近一次恢复演练的日期：____
- 回滚步骤已写下并练习过
故障处理清单
发现时间：
影响范围（哪些功能、多少用户）：
止损动作（回滚 / 关闭功能）：
最后一个正常的版本：
按层排查的结果：
根本原因：
修复方式：
以后怎样避免：
是否需要通知用户，如何通知：
关键概念
- 构建产物：部署的是构建生成的文件，不是源码
- 预览环境：正式发布前的检查环境
- 环境变量：区分公开配置和机密配置
- 可用性检查：定时访问关键页面和接口
- 恢复演练：用备份实际恢复一次
- 兼容迁移：分步修改表结构，保证随时可以回滚
容易误判
- 本地能打开就认为线上没问题
- 预览和正式环境共用同一个数据库
- 一出问题就去改 DNS
- 以为代码在 Git 里就等于数据有备份
- 默认托管数据库会自动备份
- 回滚代码却没考虑数据库结构的变化
04 工具和参考资料
本篇涉及的工具和参考链接。
可参考工具
- Cloudflare Workers
- Vercel
- Sentry
- Better Stack
- Supabase