Fable 5部署验收 | 日志回滚清单

title: " Fable 5部署验收 | 日志回滚清单" category: 人工智能 tags:

• 大模型API中转站
• 4SAPI
• Claude Fable 5
• 部署验收
• 日志监控
• 回滚
• 成本治理 description: "服务器、Docker、数据库和项目部署完成后，真正决定能不能上线的是验收、日志、备份和回滚。本文讲如何用 Fable 5 做上线前检查、故障排查、日志总结和回滚演练，并用 4SAPI 管理模型调用成本与审计。"

前面四篇讲了：

服务器初始化。
Docker 安装。
数据库安装。
项目部署。

这一篇收尾，讲上线验收。

很多部署事故不是发生在“装不上”。

而是发生在：

以为已经装好了。

服务能访问，不代表能上线。

首页能打开，不代表数据库写入正常。

SSL 能申请，不代表续期没问题。

容器能启动，不代表日志、备份、回滚都准备好了。

所以最后一步，要让 Fable 5 做上线前审查。

4SAPI 则负责记录整个部署链路里的模型调用、成本和高风险判断。

1. 上线前先问 Fable 5：我漏了什么

把你的部署信息整理给 Fable 5：

项目类型：
服务器系统：
部署方式：
数据库：
域名：
SSL：
Nginx：
日志位置：
备份方式：
回滚方式：

然后问：

请以高级运维工程师视角做上线前审查。

重点检查：
1. 哪些验证还没做
2. 哪些配置可能只是在本机能跑
3. 哪些端口或服务有安全风险
4. 数据库是否有备份和恢复演练
5. SSL 是否有续期风险
6. 是否有回滚方案
7. 是否有日志可以排查问题

输出：
P0/P1/P2 风险清单。
每条给出证据、影响、修复建议和是否阻塞上线。

这类审查很适合 Fable 5。

因为它要跨服务器、Docker、数据库、Nginx、SSL、项目代码一起看。

2. 上线验收清单

一张最小清单：

把执行结果贴给 Fable 5，让它只判断：

能不能上线。
哪些阻塞。
哪些上线后观察。

不要让它继续发散优化。

上线前最怕“顺手优化”。

3. 日志：先知道去哪看

常见日志位置：

给模型看日志时，注意脱敏：

API Key。
数据库密码。
Cookie。
Authorization header。
用户手机号、邮箱、订单号。

可以先让低成本模型做脱敏摘要。

再让 Fable 5 做关键判断。

这就是 4SAPI 路由的好处：

便宜模型处理重复日志。
高级模型处理根因判断。

4. 健康检查接口

如果项目没有健康检查，建议加一个。

最简单：

GET /health

返回：

{
  "status": "ok",
  "version": "1.0.0",
  "time": "2026-07-03T00:00:00Z"
}

更进一步，可以检查：

数据库连接。
Redis 连接。
关键环境变量是否存在。
模型 API 是否可达。

但不要在 health 里泄露敏感信息。

让 Fable 5 审查：

请设计一个适合当前项目的 health check。
要求：
1. 不泄露敏感信息
2. 能区分 app、db、redis、model API 的状态
3. 适合 Nginx 或监控系统调用
4. 给出失败时排查路径

5. 备份：配置也要备份

很多人只备份数据库。

但部署恢复时，还需要：

docker-compose.yml
.env 示例和真实环境变量记录位置
Nginx 配置
SSL 证书自动续期配置
数据库备份
上传文件或对象存储配置
部署脚本

注意，真实 .env 不应该随便备份到公开仓库。

可以备份到安全位置。

并记录：

谁能访问。
怎么恢复。
多久轮换。

让 Fable 5 写备份清单：

请根据我的部署方式，生成备份清单。
区分：必须备份、可以重建、不应该备份到 Git 的内容。

6. 回滚：先写剧本再上线

上线前必须写回滚剧本。

最小回滚剧本：

触发条件：
- 5xx 错误持续超过 5 分钟
- 登录或支付核心流程失败
- 数据库迁移异常

回滚步骤：
1. 停止新版本服务
2. 恢复上一版镜像或代码
3. 恢复上一版环境变量
4. 恢复 Nginx 配置
5. 如涉及数据库迁移，按预案处理
6. 验证核心接口

确认人：
- 技术负责人
- 业务负责人

让 Fable 5 审查：

请审查这份回滚方案。
重点找不可逆步骤、缺失备份、验证不足和会扩大故障的动作。

回滚不是失败。

没有回滚才危险。

7. 用 Fable 5 排查线上错误

线上报错时，不要只贴一句：

网站打不开。

给 Fable 5 一个排查包：

现象：
- 用户看到什么
- 从什么时候开始
- 是否全量影响

最近变更：
- 部署时间
- 修改内容
- 数据库迁移
- Nginx/SSL/DNS 变化

日志：
- app 最近 200 行
- nginx error 最近 200 行
- db 最近 200 行

验证命令：
- curl 结果
- docker compose ps
- ss -tulpn

Prompt：

请按故障排查顺序分析。
先判断影响面，再列最可能根因。
每个根因必须对应日志或命令证据。
不要建议高风险修复命令，先给只读验证步骤。

这会比直接问“怎么修”稳很多。

8. 4SAPI 成本治理：部署任务也要算账

部署阶段模型调用不少：

规划。
审查。
日志摘要。
报错排查。
回滚方案。
上线总结。

建议在 4SAPI 里按阶段标记：

记录字段：

project
stage
task_id
risk_level
model
cost
final_status

这样你能知道：

一次部署花了多少模型成本。
高级模型主要用在哪些关键判断。
哪些低价值环节可以降模型。
哪些错误反复发生，应该写成部署 SOP。

9. 给 Fable 5 的真实排错包模板

线上出问题时，最忌讳一句话丢给模型：

网站挂了，帮我看看。

这样 Fable 5 只能猜。

更好的做法，是给它一个标准排错包：

【故障现象】
- 用户看到：
- 影响范围：
- 开始时间：
- 最近一次正常时间：

【最近变更】
- 代码版本：
- 部署时间：
- 配置变化：
- 数据库迁移：
- Nginx/SSL/DNS 变化：

【当前状态】
- docker compose ps：
- curl -I 域名：
- ss -tulpn：
- df -h：
- free -h：

【日志】
- app 最近 200 行：
- nginx error 最近 200 行：
- db 最近 200 行：

【要求】
先判断影响面，再给只读验证步骤。
不要直接给删除、重启数据库、清空缓存、回滚生产的命令。
每个判断都要对应日志或命令证据。

这个模板能显著提升排错质量。

因为它把模型从“猜原因”拉回“按证据排查”。

如果日志很长，可以先让低成本模型压缩成摘要：

请脱敏并总结这段日志，只保留错误、时间、请求路径、状态码和堆栈关键行。
不要推断根因。

然后再把摘要交给 Fable 5 做根因分析。

这就是 4SAPI 路由的典型用法。

10. 部署日报模板

如果你经常部署，可以让 Fable 5 每次生成一份部署日报。

模板：

# 部署日报

项目：
日期：
负责人：
版本：

本次变更：
- 

部署步骤：
- 

验证结果：
- 首页：
- API：
- 数据库：
- 后台任务：
- 日志：

异常和处理：
- 

回滚准备：
- 上一版镜像/代码：
- 数据库备份：
- Nginx 配置备份：

后续观察：
- 

模型调用：
- Fable 5 用于：
- 低成本模型用于：
- 4SAPI 日志 task_id：

这份日报的意义不是形式主义。

它能让你一个月后还知道：

那天到底改了什么。
哪个问题当时怎么修的。
有没有留下观察项。
模型帮了哪一步。

11. 部署复盘文档

部署完，让 Fable 5 生成复盘：

请根据本次部署记录生成复盘文档。

包括：
1. 最终部署架构
2. 服务器和服务清单
3. 环境变量清单，不包含真实值
4. 数据库和备份方式
5. Nginx/SSL 配置说明
6. 常见故障排查入口
7. 回滚步骤
8. 下次优化建议

这份文档以后很值钱。

因为你两个月后一定会忘：

当初为什么这么配。
日志在哪。
证书怎么续。
数据库怎么备份。

好部署不是一次成功。

是未来可维护。

12. 整组部署路线图

这一组可以连起来看：

第156期：服务器初始化
第157期：Docker 和 Compose
第158期：数据库和 Redis
第159期：项目、Nginx、域名、SSL
第160期：验收、日志、备份、回滚

如果你只想部署一个项目，顺序不要乱。

先地基，再容器，再数据，再应用，再验收。

每一步都让 Fable 5 做审查，而不是只做命令生成。

13. 总结

用 Fable 5 辅助部署，真正的价值不是“复制命令更快”。

而是：

部署前能规划。
执行中能排错。
上线前能审查。
出问题能回滚。
结束后能沉淀文档。

4SAPI 让这件事更适合团队：

高级模型负责高风险判断。
低成本模型负责日志和摘要。
所有调用都有记录。
每次部署成本可复盘。

最后记住一句：

不要让模型替你冒险。
要让模型帮你看见风险。

这才是 Fable 5 这种高级模型，在部署服务器、安装数据库、安装 Docker、上线项目时最值得用的地方。