2 篇博文 含有标签「runbook」

弃用通知邮件在一个周二的下午寄达。你的计费流水线赖以生存了 14 个月的模型现在进入了 60 天的倒计时。提示词是由一名在 3 月离职的工程师调优的。评估套件自发布以来从未重新设定基准。客户成功团队正在询问为什么两个企业账户的“AI 感觉不一样了”。没有人把这件事列入路线图，也没有人能清爽地接手，因为在你组织的心理模型中，这是一个一次性项目 —— 尽管这已经是今年的第四次了。

每个在生产环境中运行 AI 功能的团队在 18 个月内都会得出同样的感悟：基础模型提供商正以团队未曾预料的频率弃用模型，而团队的迁移应对措施始终是由于收到通知邮件而触发的被动仓促应对。解决方法不是为下一次迁移准备一个更好的操作手册 —— 这类手册已经很多了，你的团队可能也写过一个。解决方法是停止将迁移视为一个项目，而是将其视为一个经常性的运营原语。把它排进日历。

页面告警在凌晨 2:47 响起。智能体（Agent）正向客户支持工单发送语气错误的回复，延迟仪表盘显示平稳，错误率正常，而且由于过去 12 小时内没有进行过任何部署，没有任何东西可以回滚。值班工程师打开了运维手册（runbook），滑过了“重启工作线程池”和“扩容队列”，直到翻到底部，也没发现任何能与眼前告警相匹配的内容。他们在凌晨 3:04 开始阅读系统提示词（system prompt）。到凌晨 3:31，他们仍在阅读。

这是全新的故障形态。那些为“高延迟意味着重启 Pod，5xx 错误增加意味着回滚部署，队列深度增加意味着扩容工作线程池”而设计的轮值制度，已无法应对此类问题。第一直觉——回滚部署——是错误的，因为根本没有部署：模型在版本化别名（versioned alias）后静默升级了，第三方工具的响应结构发生了偏移，提示词版本在不同区域间出现了偏差，或者评估集在几周前就已失效，而回归问题一直在持续累积。告警是真实的。运维手册却保持沉默。AI 值班现在已经成为一门独立的学科，试图将其强行套入现有的轮值体系，只会产生那种在告警发生时，所有人第一步都是在通话中相对无言、第一次开始阅读提示词的方案。