企业官网建设流程全解析

那天上午十点，我的工作群被一张截图炸开了：推荐系统的点击率曲线、审核系统的误杀率曲线、客服系统的转人工率曲线，三条曲线几乎在同一时刻开始失控。有人把三条曲线拼在一起，配了一句评论：全司AI同时申请产假。老实讲，第一次看到这个梗我是想笑的，但接下来的四个小时，我完全笑不出来。这不是一句玩笑，而是我们真的遇到了一个能让所有算法模型集体“摆烂”的故障。

这个故障让我第一次认真思考一个问题：当全公司的AI服务同时“请假”时，我们到底应该先骂算法，还是先看依赖链和配置中心？这篇文章想完整复盘一次真实的排查过程，也把后面补上的防御手段整理出来，给同样被“AI集体罢工”折磨过的朋友一点参考。

1. 事故日现场：推荐、审核、客服在同一天开始“带薪发呆”

1.1 三个业务线的异常表现各不相同

先说现象。事故那天，我们涉及的核心业务线一共有四条：推荐、内容审核、智能客服，还有一个语音助手。各自表现出来的症状完全不一样，这也是最开始我们花了很长时间互相“甩锅”的原因。

推荐业务线的反馈是最直观的：首页推荐位的点击率一小时之内掉了将近一半，而且用户刷出来的品类非常单一，大量已经下架的商品重新出现在候选序列里。运营同学一开始以为是商品池出了问题，还查了一轮库存同步任务。

内容审核那边更吓人。当天上午开始，审核系统对普通图片和短文本的误杀率从平时的0.3%直接飙到2.4%，也就是大概每一千条正常内容里有二十四条被拦截。很多用户申诉和客诉涌进来，审核团队一度以为是最近更新的敏感词库误伤了正常内容。

智能客服和语音助手的表现则更“软性”：客服机器人开始答非所问，用户问退货流程，它反复推荐优惠券和会员充值；语音助手则表现为响应超时，唤醒后要等三四秒才给出反馈，而且回答内容明显偏“模板化”，像所有句子都从一个默认答案池里捞出来的一样。

1.2 “全司AI同时申请产假”这个梗是怎么传开的

说实话，如果只有一条业务线出问题，大家不会往“公共故障”上想。但四路业务同时崩，群里就热闹了。A同学在群里发了一张监控拼接图，本来是想对比四条曲线，没想到一眼看上去四根线几乎都在同一个时间点开始拐头。B同学随口回了一句：“这架势，是全司AI同时申请产假了吧。”

这个梗很快传开，因为实在贴切——不是某一块业务不行，是每个业务里的AI都在“消极怠工”。但搞笑归搞笑，排查还是要继续。我们当时第一反应都是检查自己最近有没有发版、有没有调参、有没有改特征。结果四个团队一通翻日志，谁也没有找到自己这边的异常变更。

真正让大家警觉的是，每个团队都说“我们没动过代码，模型也没重新发布过”。于是我们开始意识到，问题可能出在大家共同依赖的某个地方。

2. 排查链路：从各查各的到锁定公共依赖

2.1 第一波排查：每个团队都在查自己的代码

我先说我们当时最容易被带偏的地方。故障发生后，推荐团队的第一反应是看快照特征、模型版本、AB实验流量分配。审核团队在看规则引擎的配置和敏感词表。客服团队在看FAQ检索服务和对话状态机。我们四个团队并行排查了两个多小时，基本相当于各查各的，谁也没往公共层想。

这其实是一个很常见的排查误区。当一个系统“看起来”症状各不相同时，大家倾向于认为问题在自己的业务代码里。但AI系统有个特点：不同业务模型可以共享很多底层组件。比如特征平台、推理网关、模型服务框架，甚至一个公共的全局配置项。这些组件如果出了问题，表面症状会因为各自模型的输入输出差异而表现得很不一样，但根因只有一个。

我们开始把四路请求的链路图拉出来对照，发现它们确实不是“互不相干”的。推荐模型、审核模型、客服语义模型、语音意图模型，虽然部署在不同的服务里，但推理时都会去同一个“共享特征服务”拉用户特征和内容特征。也就是说，如果特征服务给的数据出了问题，四路模型会同时“吃坏肚子”。

2.2 共同的异常点：模型网关的流量形态不对

顺着这个思路，我们把第一波调查重点放在模型推理网关上。从网关监控看，四路请求的数量都没有明显变化，QPS平稳，HTTP错误率也很低，表面上看不出什么大问题。但仔细看P99时延，发现从十点零七分开始，所有模型服务的P99时延都不同程度上涨，客服模型甚至翻了一倍多。

更关键的是，请求在网关内部的分支统计出现了一个奇怪现象：大量请求没有走“正常推理分支”，而是走了“特征缺失兜底分支”。我们的推理框架有一个容错设计：当模型请求拿不到特征时，不会直接报错，而是返回一个基于默认值的低置信度预测结果。这样做本意是防“脏请求”拖垮模型服务，但坏处是它把故障静默吞掉了——网关日志里全是“feature_fallback”的标记，却没有一条红色错误。

到这里事情就清楚了一半：四路模型本身没坏，坏的是它们上游的特征获取。我们随后直接连到共享特征服务，看每条请求日志，果然发现所有特征字段都是0或者空字符串。模型拿到一堆空特征，自然只能输出“无区分度”的结果，表现为点击率下降、审核分数偏移、客服答非所问。

2.3 特征服务的输入突变：模型没坏，是“饭”坏了

我当时跟同事打了个比方：模型就像厨子，特征就像食材。厨子本身没有问题，但食材仓库突然给每个订单都发了一箱过期土豆，那不管是什么菜系的大厨，做出来的东西都不会好吃。

接下来要回答的问题是：为什么特征服务会返回全零数据？

我们先查特征服务自身的缓存，发现热点用户和内容特征的Redis命中率确实在下降，但并没有到完全打空的程度。再往里查，发现特征服务在构造每个特征向量的时候，会调用一个“特征提取器”组件。而这个组件当前加载的，居然是一个用于单元测试的mock实现——它不会访问任何真实数据源，只会往每个字段里填默认值。

看到这个线索，我们立刻去翻特征服务对应的配置中心。这时候距离故障发生已经过去了三个多小时，群里早就没有心情再玩“申请产假”的梗了。

3. 真正的根因：一个全局开关让整套推理链进入“测试态”

3.1 配置中心里凌晨两点的一条变更

真正的原因，最终在配置中心的审计日志里被找到。记录显示，当天凌晨两点十四分，有人对“生产环境公共配置”做了一次变更，变更内容只涉及一个布尔开关：use_mock_feature_extractor，从 false 改成了 true。

这个配置项一看就知道是开发用的测试开关。正常流程里，A同学在本地联调特征服务时，会用true来绕过真实依赖，让整个链路能跑通。但那天凌晨他在公共配置区里改了东西之后，没有切回自己的私有配置空间，也没有走生产变更审批，直接把这个改动提交到了所有人共用的命名空间。

他以为自己改的是自己那台开发机的配置，实际上改的是全公司所有业务线模型服务都会读取的全局配置。于是从凌晨开始，所有新进入推理流程的特征请求，全都在走mock提取器。四路业务线因为请求量不同、缓存策略不同，才从上午十点左右开始陆续表现出异常。这也解释了为什么事故不是“零点准时爆炸”，而是拖到上班高峰期才爆发。

3.2 为什么一个布尔开关能让所有模型集体失灵

可能有人会问：一个Mock开关，怎么就让全公司AI集体失灵了？这里面有三层原因，缺一不可。

第一层是公共配置的作用域太大。我们的配置中心支持按命名空间管理，业务线的私有配置在各线自己的命名空间里，但公共配置在所有服务里优先级最高。A同学改的这个开关正好挂在“公共配置”上，所以所有服务都会读到。

第二层是各业务线普遍缺乏输入校验。正常来说，模型推理前应该检查特征的有效性，比如非零率、缺失率、合理范围。但为了推理性能，我们没有做全量校验，只依赖特征服务返回“一定是对的”。当mock特征返回全零时，下游模型根本没有察觉，直接拿零向量做前向计算。

第三层是之前提到的“静默降级”。推理网关看到特征缺失，本应该把请求标记为失败并触发报警，但我们的容错逻辑选择了返回默认结果。这个设计本意是防止个别脏请求影响用户体验，结果在全局故障时，反而让所有异常响应都变成了“正常响应”。

这三层叠加在一起的后果就是：系统没有报错，没有崩溃，只是像一群不想上班的员工一样，每个人都给出最低质量的产出，然后还假装自己干得很好。

3.3 从返回内容异常到提交记录的实锤

回头梳理时间线，整个排查过程大致是这样的：

回滚操作本身只花了几秒钟。但回滚后指标并没有立刻恢复，原因是下游模型还在用旧的缓存特征做推理，需要等缓存过期。到下午两点左右，推荐点击率、审核误杀率、客服转人工率才先后回到故障前水平。整个故障持续了大约四小时，影响面覆盖四个业务线，直接导致当天数万条内容需要人工重新审核。

我后来问A同学，他说他当时只是想把联调环境跑通，改完就被拉去开会了，完全没想起来自己动的是生产公共配置。这个回答听着离谱，但其实很典型——每一个配置事故背后，几乎都有一个“我就临时改一下”的念头。

4. 复盘后的防御体系：怎么防止AI再次集体请假

4.1 全局配置的权限隔离、审批与灰度

事故后的第一件事，是把配置中心的权限模型重做了一遍。公共配置命名空间不再允许任何个人直接编辑，只能通过“申请-审批-灰度-生效”的流程。流程里强制要求写清楚影响范围、变更原因和回滚方案，并且配置生效支持按比例灰度，比如先让5%流量走到新配置，观察十分钟没有问题再全量。

同时，我们规定所有带mock、debug、test、dev字样的组件，只能在测试环境加载。生产环境的服务启动时，会做一次“环境标识检查”，如果发现当前环境是生产，但配置要求加载mock提取器，直接拒绝启动并报错。这个检查看起来很傻，但却是最有效的一层保险。

这里有一个细节：配置中心一定要保留完整的审计日志，包括谁改的、什么时间改的、改之前的值和改之后的值。这次事故能在一小时内确认根因，靠的就是审计日志里那条清清楚楚的变更对比。如果没有审计日志，大家可能要从特征算子包版本一路查到凌晨的发布记录，难度会大很多。

4.2 给模型输入增加“特征体检”

第二项关键改造，是在推理链路里增加特征合法性校验。我们加了一个轻量级的“特征体检”逻辑，放在特征服务返回结果之前。每次批量特征返回时，统计稠密特征的“有效非零字段占比”，如果低于某个阈值（比如40%），就认为这次特征构造异常，直接返回显式错误，而不是拿着全零特征往下游发。

显式错误的好处是，下游的推理网关会立即感知到上游异常，进而触发熔断和告警，而不是走静默降级。也就是说，我们允许模型服务不可用，但绝不允许模型服务“坏着还假装可用”。可用性可以降，数据质量不能被污染，这是一个非常重要的取舍。

实际做下来，这个校验对性能影响很小。我们只对特征向量里的关键字段做统计，不需要逐个遍历所有维度。而且校验结果可以写到日志里，配合监控平台画一条“特征非零率”曲线，一旦数据开始漂移，能第一时间看到。

4.3 可观测性升级：不能只用QPS和错误率判断AI健康

这次事故给我们最大的教训之一是：AI系统的健康度不能只看QPS、错误率和时延。这三个指标对于传统接口来说够用，但模型服务比较特殊——就算QPS正常、错误率为零、时延很低，模型也可能在输出一堆垃圾结果。

所以我们在监控看板上新增了几个指标：模型平均置信度、Top1得分与Top2得分的差距、特征有效字段占比、降级分支调用次数。这些指标能直接反映“模型输出质量”。比如说推荐模型原本Top1和Top2的得分差通常在0.3左右，如果某天突然缩到0.01，那就说明排序几乎没有区分度，很可能特征在退化。

这类“输出健康度”指标不用全部建模，先挑两三个最敏感的就行。关键是让监控的人能在业务指标异常之前，先看到模型输出的异常。我们这次就是太信任业务指标，等到点击率掉了才警觉，其实模型平均置信度在故障后几分钟内就已经明显下滑了。

4.4 应急预案：宁可切换人工兜底，也不要在有问题的系统上硬撑

最后，我们重新梳理了全公司各业务线的人工兜底流程。很多团队平时只依赖AI自动化，一旦AI故障，根本没有快速切换到人工的能力。这次审核业务就是因为没有备用的人工审核队列，导致大量内容挤压。

现在的预案很简单：一旦核心模型服务的“输出健康度”指标连续五分钟异常，值班同学有权直接触发“AI停用”开关，让业务流量切到规则引擎、人工队列或历史推荐缓存。听起来很粗暴，但实践证明，与其让AI继续以低质量状态产出，不如先停掉它，保住用户体验。

这个开关平时每季度会做一次演练。第一次演练的时候，好几个团队发现自己根本不知道怎么一键切换，折腾了半小时才找到对接人。演练完，我们把切换操作整理成一张校验表，贴在值班文档首页：确认上游特征状态、确认数据源可用、确认人工队列水位、一键切换、验证业务指标。

5. 最后一点私货：算法没有感情，但依赖链会记仇

这次“全司AI同时申请产假”的事故，后来成了我们组里的一个梗。每次有人改配置，大家都会开玩笑说“你小心让全司AI集体请假”。玩笑归玩笑，背后的教训我记了很久。

AI模型本身没有情感，不会真的“累”或“罢工”。它只能按照数据、特征和配置去计算。当所有模型同时给出糟糕结果时，我们要找的不是某个模型“变笨了”，而是它们共同依赖的那条链路里，哪个环节被悄悄换掉了。配置开关、特征服务、推理框架，任何一个公共组件出问题，都足以让整个体系在同一天集体“摆烂”。

我现在看任何AI系统，都会先问几个问题：模型的输入特征有没有校验？公共配置有没有权限隔离和审计？监控里有没有“输出健康度”指标？人工兜底链路能不能一键切换？这几个问题问完，基本就能判断一个团队是真的在做AI系统，还是在裸奔。

如果你也遇到过类似的“AI集体请假”事故，别急着骂算法，先去翻配置中心的审计日志。那个全公司的AI们同时沉默的早晨，最后教会我的不是怎么修模型，而是怎么尊重依赖链。