1 篇博文 含有标签「cron-jobs」

事故复盘将十二天前的一次部署确定为支出增加 3.6 倍的原因，而当时在场的参与者中，没有一个人在变更发布时参与其中。部署过程非常常规：蓝绿切换，流量按计划转移到绿色环境，蓝色环境停用，流水线变绿，发布工程师关闭了工单。生产环境的 SLO 都没有触发。应用层的告警也没有响起。系统运行得完全符合设计。

原本的设计是一个每五分钟运行一次的 Cron 任务，它每五分钟针对稳定的系统提示词前缀 (system-prompt prefix) 预热提供商的 Prompt 缓存。这种预热为团队在冷启动时带来了 91% 的缓存命中率，并在每个会话的第一次请求中获得了大约 4 倍的成本优势。该 Cron 任务是一年前首次引入蓝绿模式时编写的，其主机选择器 (host selector) 被固定在蓝色池 (blue pool)，以避免在重叠窗口期间运行两次预热。当绿色环境变成活跃环境而蓝色环境消失时，该 Cron 任务失去了它的主机，并从“每五分钟运行一次”悄无声息地转变为“永不运行”。随着提供商缓存的 TTL 使预热的前缀过期，缓存命中率在接下来的 36 小时内逐渐下降。成本仪表盘计算的是每日窗口内的平均单次请求成本，平滑了趋势，直到下一个计费周期让问题变得显而易见。