一个 AI Gateway 从“请求能够转发”到“可以放心维护”，中间还有很长一段工程距离。
最开始，它通常只是一个进程、一个端口和一份配置。模型能够返回结果，看上去就已经完成了大半。但只要它开始被持续使用，新的问题会立刻出现：配置由谁修改？密钥放在哪里？升级失败怎么办？数据多久备份一次？
01. 先定义“可维护”意味着什么
在这个项目中，我把可维护拆成四个可以检查的目标：服务状态可观察、数据可以恢复、操作可以重复、上游变化不会直接影响调用方。
部署成功是一个瞬间；可维护是一组每天都成立的条件。
02. 把运行结构拆开
应用、网关、数据和上游服务需要拥有明确边界。调用方只依赖稳定入口；网关负责协议与渠道差异；数据目录独立备份；上游服务可以单独升级或下线。
CLIENT应用与工具
→GATEWAY鉴权 · 路由 · 日志
→PROVIDERS模型与渠道
健康检查不应该只回答“进程是否存在”，还要回答关键依赖是否可用。下面是一段简化后的检查输出：
$ ailly ops health
ok gateway http 200 · 82ms
ok database sqlite writable
ok proxy latency 146ms
ok upstream 3 / 3 channels03. 把交付写进系统
如果每次发布都依赖记忆，系统实际上没有稳定的发布流程。构建、上传、备份、重启与健康检查应该按照固定顺序发生，并且任何一步失败都能停止后续动作。
| 阶段 | 必须确认 | 失败处理 |
|---|---|---|
| 发布前 | 构建通过、配置完整 | 停止发布 |
| 变更前 | 数据库备份可读取 | 保留旧版本 |
| 启动后 | 状态与关键渠道正常 | 回退并复查日志 |
04. 一份最小检查清单
- 配置与密钥不写入仓库
- 数据目录与程序文件分离
- 升级前创建可验证的备份
- 服务由进程管理器托管
- 关键操作具有统一入口
- 交接文档说明恢复方式
这份清单并不复杂，但它能让一个“偶尔能跑”的项目，逐步变成可以持续使用的服务。