第 05 模块 · 2 节

上线、监控与持续优化

《Codex 生产级工程》05 生产级实战 · 本节时长 30 分钟

上线只是开始,重点是「持续优化」

上一节搭好了一套自动化体系。部署上线只是第一步——真正的价值在上线之后的运行、监控与持续优化。体系是「活」的,要一直喂、一直调。

这一节讲上线、监控、持续优化。

贯穿项目deploy-bot 不是「上完线就完」。这一节把 deploy-bot 上线后的「稳、看、调」三件事讲清楚:上线要稳、监控要主动、发现数据异常就优化。deploy-bot 从「搭出来」走向「长期好好运转」。

上线:稳字当头

上线别一把梭,分几步:

  • 先小范围:灰度、分批,别全量一把上
  • 可回滚:出问题能退到上一稳定版
  • 留记录:上线了什么、什么时候,能查到
灰度 10% → 观察 → 没问题 → 全量
出问题 → 回滚 → 修 → 再上

稳,比快重要。

对 deploy-bot 上线,尤其要稳:

deploy-bot 上线步骤
1. 先在 staging 上完整跑通 N 次,确认稳定
2. 灰度:先对 1 个项目的 production 开放部署,观察
3. 可回滚:确认 production 失败能自动回滚到上一稳定版
4. 留记录:每次上线了什么版本、改了哪些门禁,都记下来

上线不是「推上去」,是「确认它能稳住了再放开」。


监控:上线后要看什么

上线后不能「甩手不管」,要持续监控:

监控 看什么
用量 Token、成本、调用次数
错误 失败率、异常
性能 响应时间、是否变慢
任务 定时任务有没有漏跑、失败

监控的意义:在用户发现之前你先发现。

对 deploy-bot,监控项要贴它的部署场景:

监控 deploy-bot 看什么
部署是否触发 该部署的提交有没有漏部署
部署成功率 最近部署的成功/失败比
耗时 部署是否变慢、卡在哪一步
回滚次数 是否频繁回滚(说明流程不稳)

这些数字一异常,就是「用户发现问题之前」的预警。


告警:出问题主动知道

配合监控设告警:

  • 错误率超阈值 → 告警
  • 定时任务失败 → 告警
  • 用量接近预算 → 告警

告警要分级、要准确,别一有风吹草动就轰炸,久了没人看。

对 deploy-bot 的告警分级:

deploy-bot 告警
最高级:production 部署失败、回滚发生 → 立即通知,必须看到
中级:staging 连续失败 N 次 → 通知负责人
低级:单次 staging 失败、部署略慢 → 记录,合并告警

核心告警保证触达,噪音别淹没大事。


持续优化:体系的常态

监控不只是「发现问题」,更是「发现改进点」:

监控数据 → 发现问题 → 定位原因 → 优化 → 再监控
数据 可能的问题 优化方向
成本偏高 上下文太长/模型用大 上下文优化、换模型
错误率高 Agent 误判/规则不清 调 Agent 配置
任务变慢 数据量大了 拆分、优化脚本

每个监控数据,都指向一个优化动作。

对 deploy-bot 的监控数据 → 优化动作:

deploy-bot 数据 可能的问题 优化方向
部署变慢 构建/数据量大 拆分构建、优化脚本
回滚频繁 门禁没过住坏代码 加严门禁、补测试
staging 失败多 部署步骤不稳 调 deploy-bot 规则、补重试

一个「监控 → 优化」示例

监控发现:报表任务耗时从 2 分钟涨到 10 分钟。
定位:数据量涨了,单次全量查询太慢。
优化:改成增量查询 + 分页处理。
再监控:耗时回到 2 分钟。

发现问题 → 优化 → 验证,循环不止。

对 deploy-bot 一次「监控 → 优化」:

监控发现:deploy-bot 部署 staging 的耗时从 3 分钟涨到 15 分钟。
定位:构建步骤没有缓存依赖,每次全量重装。
优化:加依赖缓存,构建只重跑改动部分。
再监控:耗时回到 3 分钟,部署恢复正常。

监控数据不止是「报错」,更是「优化的线索」。


常见坑:上线后就「甩手不管」,直到用户来报

上线后最常见的坑,是以为「上完线就没事了」,等到用户或业务方来报问题,才发现体系早就在悄悄出错。

真实场景:deploy-bot 上线后没人看监控。某天它频繁回滚、staging 连续失败,但你没设告警,也没人看日志。直到某个项目发现「怎么老是部署不上去」才报过来,这时已经影响了好几个项目、拖了很久。

为什么:上线不是终点,是「运维」的开始。没有主动监控 + 告警,体系出问题你根本不知道,等于让业务方替你当监控。

怎么破:上线当天就把「监控 + 分级告警」配好,而不是「以后再说」;核心指标(production 失败、回滚、连续失败)一定要有最高级告警;设定固定节奏看监控,别等别人来报。把「没人报 = 没问题」改成「监控正常 = 没问题」。


小结

  1. 上线要稳:灰度、可回滚、留记录
  2. 监控:用量、错误、性能、任务,主动看
  3. 告警:出问题主动知道,分级准确
  4. 持续优化:监控数据 → 发现问题 → 优化 → 再监控
练习给上线后的 deploy-bot 定一份「稳 / 看 / 调」方案。①三步走:a. 定上线步骤(先 staging 跑通 → 灰度一个项目 → 可回滚);b. 列出 3-4 个要监控的 deploy-bot 指标,并给核心项配最高级告警;c. 从监控数据里挑一个「优化点」跑一遍「发现问题 → 优化 → 再监控」。②怎么判断做对了:deploy-bot 上线是「灰度 + 可回滚」,不是一把全量;production 失败 / 回滚有最高级告警,不用等用户报;每个监控异常都能对应一个明确的优化动作并验证生效。③卡住了怎么办:不知道监控什么,就先只盯「部署成功率 + 回滚次数」这两个核心;告警配不齐,就先保「production 失败」一条最高级;优化没效果,先确认「问题真的复现」再谈改,别改完就以为好了。

下一节,讲项目复盘与经验沉淀。