1. 项目概述：这不是一次“部署上线”演示，而是一场真实世界的ML交付实战复盘

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着三个关键信号：Notebook是起点，不是终点；Production是目标，但绝非简单打包；Real World是限定词，也是所有技术决策的终极判官。我带过七支不同行业的ML落地团队，从金融风控模型到工厂设备预测性维护，从电商推荐系统到医疗影像辅助标注，反复验证一个事实：真正卡住90%项目的，从来不是算法精度提升0.3%，而是模型在凌晨三点因上游数据格式突变而静默失效、是API响应延迟从200ms跳到8秒导致下游订单系统雪崩、是运维同事拿着一份“已上线”的模型文档，却找不到它依赖的Python包版本和CUDA驱动号。这篇内容，就是Part 4——它不讲Docker怎么写Dockerfile，不教Kubernetes怎么配HPA，而是聚焦在模型服务化之后那72小时里，你必须亲手处理的11个具体问题：数据漂移监控告警阈值怎么设才不误报也不漏报？模型热更新时如何保证请求零丢失？AB测试流量切分为什么不能只靠Nginx哈希？我们用一个真实的智能客服意图识别模型（BERT微调+ONNX Runtime加速）为蓝本，把生产环境里那些没人写进文档、但每天都在发生的“脏活累活”，掰开揉碎讲清楚。如果你刚把模型从Jupyter里跑通，正准备推给测试同学；或者你已经上线了模型API，但每次发布新版本都像拆弹——那这部分内容，就是你接下来三天该打印出来贴在显示器边上的操作手册。

2. 内容整体设计与思路拆解：为什么放弃“标准流程”，选择“故障驱动”架构

2.1 核心矛盾：学术范式与工程现实的根本错位

很多团队在设计ML生产流程时，下意识套用论文里的pipeline图：Data → Preprocess → Train → Evaluate → Deploy。这图本身没错，但它隐含了一个危险假设——所有环节的输入输出都是确定性、强契约的。现实呢？上游CRM系统某次数据库迁移，把原本VARCHAR(50)的“客户备注”字段悄悄扩成TEXT，模型预处理脚本里写的text[:50]直接截断关键信息；第三方天气API返回结构突然从JSON变成XML，ETL任务 silently fail 了三天，训练数据集里全是空值填充的“晴天”；甚至更隐蔽的——销售部门在BI看板里把“高价值客户”定义从“年消费>5万”临时改成“近30天有3次咨询”，而特征工程代码还锁在GitLab里没同步。这些都不是bug，是数据契约的自然衰减。Part 4的设计起点，就是承认这种衰减不可消除，只能被可观测、可干预、可回滚。因此，整个架构不按“阶段”划分，而按“故障域”组织：数据层故障、模型层故障、服务层故障、协同层故障。每个模块都内置“自证清白”能力——比如特征服务模块，不仅提供特征向量，还实时输出该批次数据的分布直方图、缺失率、与基线的KS检验p值；模型服务模块，不只返回预测结果，还附带该请求的推理耗时分位数、GPU显存占用峰值、以及本次预测所用模型版本的完整构建哈希。

2.2 方案选型逻辑：轻量级可观测性优先于重型平台

市面上有太多“端到端ML平台”方案：SageMaker Pipelines、Vertex AI Workbench、MLflow Model Registry……它们功能强大，但有一个共同软肋——默认不暴露底层故障信号。比如MLflow的Model Registry能告诉你“model-v2.1.3已transition to Staging”，但它不会告诉你，这个版本在灰度期间，对“退货原因”类别的F1-score下降了12%，因为训练时用了新采集的客服语音转文本数据，而ASR引擎升级后把“七天无理由”错识别成“七天无理由退”。Part 4采用“乐高式组合”：用Prometheus+Grafana做指标采集与可视化（为什么不用Datadog？因为它的免费版对自定义指标打点频率有限制，而我们每秒要上报200+个维度的模型健康指标）；用Elasticsearch+Kibana做日志归集（关键不是存储，而是让“某次请求失败”能关联到“同一时刻的GPU温度飙升”和“上游数据库连接池耗尽”）；用自研的model-sanity-checker工具做模型包完整性校验（它不只是验MD5，还会解析ONNX模型的graph结构，确认输入tensor name与线上服务配置完全一致）。这种组合看似原始，但好处是：每个组件的故障信号都裸露在外，没有黑盒抽象层帮你“优雅降级”——而恰恰是这种裸露，让你在凌晨两点看到告警时，能30秒内定位到是特征缓存过期还是模型权重加载异常。

2.3 关键取舍：牺牲“一键部署”便利性，换取“分钟级故障恢复”

最常被问的问题是：“你们为什么不直接用Triton Inference Server？”答案很实在：Triton确实能自动管理多模型、多版本、GPU资源，但它把“模型热更新”封装成一个原子操作。而我们在真实场景中发现，真正的痛点不是“换模型”，而是“换模型时如何不中断业务”。举个例子：智能客服系统要求99.99%的请求在500ms内返回，当我们要上线新意图模型时，如果直接reload，哪怕只有100ms的停顿，按QPS=2000计算，就会有200个用户看到“系统繁忙”提示——这在客服场景是不可接受的。所以我们放弃了Triton的auto-reload，改用“双实例+流量染色”方案：新模型先以standby模式启动，用影子流量（1%真实请求的副本）验证其输出稳定性；待连续5分钟影子流量的准确率波动<0.5%，再通过Envoy的动态路由配置，将生产流量逐步切到新实例，整个过程平滑无感。这个方案需要多写300行配置代码，但换来的是故障恢复时间从“小时级”压缩到“秒级”。这就是Part 4的核心哲学：不追求技术栈的先进性，只锚定业务SLA的硬约束。

3. 核心细节解析与实操要点：11个必须亲手处理的具体问题

3.1 数据漂移监控：别再用固定的KL散度阈值

几乎所有教程都说：“监控输入数据分布，KL散度>0.1就告警”。这在实验室里成立，在生产环境里是灾难。我们曾用这个规则监控用户搜索关键词的TF-IDF向量，结果每周一上午9点准时告警——因为市场部固定在周一发促销邮件，大量用户搜“618优惠券”，导致“618”这个词频突增，KL散度飙到0.8，但模型效果完全不受影响。根本问题在于：KL散度对高频词敏感，却对真正影响模型的低频关键特征不敏感。我们的解法是分层监控：

• 宏观层：用PSI（Population Stability Index）替代KL，因为它对分布偏移更鲁棒，且业界有成熟经验阈值（PSI<0.1稳定，0.1~0.2需关注，>0.2需干预）；
• 微观层：对每个特征单独计算“影响权重”，公式为impact_score = |feature_importance * (current_mean - baseline_mean)|，只对impact_score排名前10的特征设置动态阈值——比如“用户停留时长”特征重要性0.35，基线均值120秒，当前均值180秒，则impact_score=21，远超阈值15，触发深度分析；
• 业务层：绑定业务事件日历，对已知促销期、节假日等时段，自动放宽阈值30%。这套机制上线后，误报率从每周7次降到每月1次。

提示：不要在Prometheus里直接计算PSI，因为PSI需要全量分布直方图。我们用Spark Streaming每15分钟聚合一次特征分布，存入Redis的Sorted Set，Grafana通过Prometheus exporter读取Redis数据并计算PSI——这样既保证实时性，又避免Prometheus内存爆炸。

3.2 模型热更新：零丢失的关键在“连接保持”而非“进程重启”

热更新失败最常见的原因是：新模型加载完成前，旧模型进程已被kill，而负载均衡器还没把流量切走，导致请求直接502。标准解法是“滚动更新”，但滚动更新有gap。我们的方案是“连接保持+优雅退出”：

1. 新模型服务启动时，先监听一个临时端口（如8081），完成模型加载、warmup（用100条样本预热GPU cache）后，向Consul注册健康检查；
2. Consul健康检查脚本不只ping端口，还会发送一条测试请求，验证返回结果是否符合schema（如{"intent":"greeting","confidence":0.92}）；
3. 一旦Consul标记新实例为healthy，Envoy立即开始将新连接导向8081，但对已在8080上建立的长连接，保持120秒存活期（通过HTTP/2的SETTINGS_MAX_CONCURRENT_STREAMS控制）；
4. 旧实例在120秒倒计时结束后，主动关闭监听端口，等待所有活跃流完成。实测下来，QPS=1500时，最大连接中断时间为0.03秒，远低于Nginx默认的1秒超时。

注意：这个方案要求客户端支持HTTP/2或长连接重试。我们强制所有内部服务使用gRPC（HTTP/2底层），对外API网关则配置proxy_next_upstream http_502 timeout，确保单点故障自动重试。

3.3 AB测试流量切分：哈希算法必须绑定“业务实体ID”而非“请求ID”

用Nginx的hash $request_id做AB分流，看似简单，但会制造幽灵bug。某次我们给推荐模型做AB测试，A组用新模型，B组用旧模型，按$request_id哈希分流。上线后发现A组点击率诡异升高15%——排查三天才发现，$request_id是Nginx生成的UUID，而前端SDK在用户刷新页面时会重置session，导致同一用户在5分钟内可能被分到A/B两组，A组看到的推荐结果更吸引人，用户就多点了几次，数据污染了AB对比。正确做法是：分流键必须是业务稳定的实体ID。我们统一使用user_id（登录用户）或device_fingerprint（未登录用户），并通过Redis Bloom Filter去重，确保同一用户100%固定在一组。更进一步，我们要求所有AB测试配置必须声明sticky_key字段，CI/CD流水线会自动校验该字段是否存在于请求头中，否则拒绝发布。

3.4 特征一致性：离线训练与在线服务的“特征计算”必须同源

这是最隐蔽的坑。离线训练用Spark SQL计算“用户近7天平均下单金额”，在线服务用Flink实时计算同样指标，但Spark的date_sub(current_date,7)和Flink的INTERVAL '7' DAY在时区处理、日期边界上存在毫秒级差异，导致同一用户在离线训练样本里特征值是238.5，在线推理时变成238.7——这点差异让模型在“临界值”附近频繁抖动。我们的铁律是：所有特征计算逻辑必须写在同一个Python函数库里，离线用Pandas调用，实时用Flink UDF调用。例如：

# features/core.py def calc_avg_order_amount(user_id: str, as_of_date: datetime) -> float: # 统一SQL模板，由不同引擎渲染 sql = f"SELECT AVG(amount) FROM orders WHERE user_id='{user_id}' AND order_time BETWEEN '{as_of_date - timedelta(days=7)}' AND '{as_of_date}'" return execute_sql(sql) # execute_sql根据运行环境自动选择SparkSession或FlinkTableEnvironment

上线前，我们会用1000个真实用户ID，对同一as_of_date，分别跑离线和实时计算，比对结果，差异>0.01即阻断发布。

3.5 模型解释性：SHAP值不是“锦上添花”，而是故障诊断的听诊器

当模型线上效果突降，传统做法是查日志、看指标、重训模型。但我们发现，SHAP值能精准定位“哪个特征的异常输入导致了批量错误”。比如某次客服意图识别准确率从92%跌到76%，常规监控显示GPU、内存、延迟都正常。我们随机采样1000个失败请求，计算每个请求的SHAP值，发现83%的失败案例中，“用户消息长度”特征的SHAP贡献值异常高（>0.8），而基线分布中该特征贡献值通常<0.3。顺藤摸瓜，发现前端SDK升级后，把用户输入的emoji表情全部转义成\\uXXXX格式，导致消息长度暴增3倍，超出模型预设的max_length=128，触发了截断——但模型本身没报错，只是默默返回了错误意图。现在，我们把SHAP分析集成到告警流程：当准确率下降>5%，自动触发SHAP分析，10分钟内生成归因报告，直达负责人企业微信。

3.6 日志结构化：必须包含“可关联追踪”的三层ID

生产环境日志混乱的根源，是缺乏统一追踪体系。我们强制所有日志必须包含三个ID：

• request_id：由API网关统一分配，贯穿整个请求链路；
• model_version_hash：模型包构建时生成的SHA256，确保知道这次预测用的是哪个commit；
• feature_batch_id：特征服务生成的批次ID，关联到具体的特征计算任务。 三者用|拼接成trace_id，例如req_abc123|mdl_v2.1.3_sha256|feat_20240520_0800。Kibana里搜索trace_id:"req_abc123*"，就能看到从API入口、到特征获取、到模型推理、再到结果返回的完整日志流。曾经有个case：用户投诉“为什么给我推荐竞品”，我们用trace_id查到该请求的特征向量里，“用户历史购买品类”特征值为0（应为1），再顺藤摸瓜发现特征管道里一个JOIN条件写错，导致该用户画像数据被过滤——整个排查从3小时缩短到11分钟。

3.7 资源隔离：GPU显存不是“够用就行”，而是“精确预留”

ONNX Runtime默认会贪婪占用所有可用GPU显存，这在多模型共用GPU时是定时炸弹。我们曾因一个新上线的图像分割模型占满显存，导致正在运行的NLP模型OOM崩溃。解决方案是：在容器启动时，通过--gpus device=0 --memory=8g硬限制，再在ONNX Runtime配置中设置intra_op_num_threads=1和inter_op_num_threads=1，并启用cuda_mem_limit参数。具体计算公式：

cuda_mem_limit = (GPU总显存 - 系统保留) × 0.85 - 其他进程显存占用

例如V100 32GB GPU，系统保留2GB，其他进程占1GB，则cuda_mem_limit = (32-2)×0.85 -1 = 24.5GB。这个值写死在模型服务的config.yaml里，启动时ONNX Runtime会严格遵守，超限直接报错，绝不抢夺。

3.8 模型回滚：不是“切回旧版本”，而是“原子化切换”

回滚失败往往因为“状态残留”。比如旧模型依赖的Redis缓存key格式变了，切回去后读不到数据。我们的回滚协议是原子化的：

1. 回滚操作触发时，首先停止新模型的所有写操作（如禁用特征缓存更新）；
2. 清空新模型专用的Redis namespace（如cache:new_model:*）；
3. 用git checkout还原模型代码，并用docker build --build-arg MODEL_VERSION=old_v1.2.0重建镜像；
4. 启动旧模型实例，通过Consul健康检查后，Envoy切流。 整个过程写成Ansible Playbook，执行时间<47秒，且每次执行前会校验Redis key pattern是否存在冲突。

3.9 安全加固：模型文件不是“静态资产”，而是“可执行代码”

很多人忽略：ONNX文件本质是protobuf序列化数据，可被注入恶意payload。我们曾用onnx.checker.check_model()验证模型，但该工具只检查结构合法性，不防攻击。实际加固措施有三层：

• 传输层：所有模型文件通过HTTPS下载，校验TLS证书链；
• 存储层：模型仓库（MinIO）开启服务端加密（SSE-S3），且每个模型对象附加x-amz-meta-signature头，值为HMAC-SHA256(model_bytes, secret_key)；
• 加载层：ONNX Runtime启动时，先用onnx.load()加载模型，再用onnx.shape_inference.infer_shapes()推断shape，最后用自研safe_graph_validator扫描所有node.op_type，禁止Loop、If等可编程op——因为这些op可能被用来绕过沙箱执行任意代码。

3.10 成本监控：GPU小时不是“越便宜越好”，而是“单位预测成本最低”

团队常陷入误区：选最便宜的GPU实例。但我们的成本公式是：

unit_cost = (GPU实例小时费 + 存储费用 + 网络出向费) / (QPS × 3600 × uptime_ratio)

例如A10G实例小时费0.7美元，QPS=300，uptime_ratio=0.95，则unit_cost=0.7/(300×3600×0.95)=9.1e-7美元/次；而T4实例小时费0.35美元，但QPS仅180，unit_cost=0.35/(180×3600×0.95)=5.7e-7美元/次。所以T4更优。我们用Prometheus记录每台GPU实例的gpu_utilization、gpu_memory_used、requests_total，Grafana仪表盘实时计算unit_cost，当某实例unit_cost连续1小时高于集群均值20%，自动触发告警，提醒优化。

3.11 协同规范：ML工程师的“交付物清单”必须包含5项硬性产出

避免“模型交付即失联”，我们定义了标准化交付物：

1. 模型包：含ONNX文件、requirements.txt、config.yaml；
2. 特征字典：Excel表格，列明每个特征名、类型、业务含义、计算逻辑、更新频率；
3. SLA承诺书：明确写出P95延迟、可用率、数据新鲜度（如“用户行为特征T+15min可达”）；
4. 故障预案：列出TOP5故障场景（如“特征服务宕机”、“GPU显存溢出”）及对应的手动干预步骤；
5. 回滚验证报告：用1000条历史样本，证明回滚到上一版本后，关键指标回归基线±0.5%以内。 这5项缺一不可，CI/CD流水线会自动校验，缺失则阻断发布。

4. 实操过程与核心环节实现：以智能客服意图识别模型为例

4.1 环境准备：从零搭建可观测性底座

我们用Terraform在AWS上初始化基础环境，核心资源包括：

• 1台t3.medium EC2作为Prometheus server（8GB RAM，50GB GP3磁盘）；
• 1台c5.2xlarge EC2作为Grafana server（8vCPU，16GB RAM）；
• 1个3节点ES集群（r6.large.elasticsearch，启用了UltraWarm）；
• 1个MinIO S3兼容存储桶（用于模型仓库）。

Terraform脚本关键配置：

# prometheus.tf resource "aws_instance" "prometheus" { ami = data.aws_ami.ubuntu.id instance_type = "t3.medium" # 关键：增大Prometheus内存限制 user_data = <<-EOF #!/bin/bash echo 'vm.swappiness=1' >> /etc/sysctl.conf sysctl -p mkdir -p /data/prometheus mount /dev/xvdf /data/prometheus EOF }

安装Prometheus时，特别注意storage.tsdb.retention.time="30d"和--web.enable-admin-api（用于远程reload配置）。Grafana则预装prometheus和elasticsearch数据源插件，并导入我们定制的Dashboard JSON（含“模型延迟热力图”、“特征漂移TOP10”、“GPU利用率趋势”三个核心视图）。

4.2 模型服务化：ONNX Runtime + FastAPI + Envoy

模型服务代码结构：

/model_service/ ├── main.py # FastAPI入口，定义/healthz和/predict端点 ├── model_loader.py # 单例模式加载ONNX模型，含warmup逻辑 ├── feature_client.py # 封装对特征服务的gRPC调用 ├── metrics.py # Prometheus指标收集器（predict_latency_seconds、model_load_success_total等） └── config.yaml # 包含model_path、cuda_mem_limit、feature_service_endpoint等

main.py核心逻辑：

@app.post("/predict") async def predict(request: PredictRequest): start_time = time.time() try: # 1. 获取特征 features = await feature_client.get_features(request.user_id, request.text) # 2. 模型推理 input_tensor = preprocess(features) # 归一化、padding等 output = model_session.run(None, {"input": input_tensor}) result = postprocess(output) # 3. 上报指标 predict_latency_seconds.observe(time.time() - start_time) return result except Exception as e: predict_errors_total.inc() raise HTTPException(status_code=500, detail=str(e))

Envoy配置关键段（envoy.yaml）：

static_resources: clusters: - name: model-service connect_timeout: 0.25s type: STRICT_DNS lb_policy: ROUND_ROBIN load_assignment: cluster_name: model-service endpoints: - lb_endpoints: - endpoint: address: socket_address: address: model-service-primary port_value: 8000 - endpoint: address: socket_address: address: model-service-standby port_value: 8001

通过Consul服务发现，Envoy自动感知实例健康状态，无需手动维护endpoint列表。

4.3 数据漂移监控流水线：Spark Streaming + Redis + Grafana

数据采集脚本（drift_monitor.py）：

from pyspark.sql import SparkSession from pyspark.sql.functions import * import redis spark = SparkSession.builder.appName("drift-monitor").getOrCreate() # 每15分钟读取一次特征表 df = spark.read.format("delta").load("s3a://feature-bucket/user_behavior_features") # 计算每个特征的分布直方图（100 bins） histograms = {} for col in ["avg_order_amount", "last_login_days", "click_count_7d"]: hist = df.select(col).rdd.flatMap(lambda x: x).histogram(100) histograms[col] = hist # 存入Redis，key为"drift:20240520_0800:{col}" r = redis.Redis(host='redis-host', port=6379, db=0) for col, (bins, values) in histograms.items(): key = f"drift:{datetime.now().strftime('%Y%m%d_%H%M')}:{col}" r.zadd(key, {str(i): v for i, v in enumerate(values)})

Prometheus exporter（redis_exporter.py）：

from prometheus_client import Gauge, CollectorRegistry import redis registry = CollectorRegistry() psi_gauge = Gauge('model_drift_psi', 'PSI value for feature drift', ['feature'], registry=registry) def collect_psi(): r = redis.Redis() # 获取最新两个时间窗口的直方图 keys = sorted(r.keys("drift:*"), reverse=True)[:2] if len(keys) < 2: return hist1 = [float(v) for v in r.zrange(keys[0], 0, -1, withscores=True)] hist2 = [float(v) for v in r.zrange(keys[1], 0, -1, withscores=True)] psi = calculate_psi(hist1, hist2) # 自研PSI计算函数 psi_gauge.labels(feature="avg_order_amount").set(psi)

Grafana Dashboard中，PSI指标阈值线设为0.1（黄色）和0.2（红色），并配置告警规则：model_drift_psi{feature="avg_order_amount"} > 0.2，触发企业微信通知。

4.4 AB测试实施：Envoy + Consul + 自研流量控制器

AB测试配置存于Consul KV：

ab-test/intent-model/ ├── config.json # {"version_a": "v2.1.3", "version_b": "v1.8.0", "traffic_ratio": {"a": 0.7, "b": 0.3}} └── sticky_keys # ["user_id", "device_fingerprint"]

Envoy的RouteConfiguration动态加载：

route_config: name: intent-route virtual_hosts: - name: intent-service domains: ["*"] routes: - match: { prefix: "/predict" } route: weighted_clusters: clusters: - name: model-a weight: 70 - name: model-b weight: 30 # 关键：基于header的sticky hash_policy: - header: { header_name: "x-user-id" }

流量控制器服务（ab-controller.py）监听Consul KV变更，一旦ab-test/intent-model/config.json更新，立即调用Envoy Admin API/v3/route_configs推送新配置。整个过程<3秒，且支持灰度发布：先推送到10%的Envoy实例，验证无误后再全量。

4.5 故障演练：模拟3类典型故障并验证恢复流程

我们每月进行一次“红蓝对抗”演练，蓝队（运维）制造故障，红队（ML工程师）按SOP恢复：

• 故障1：特征服务宕机
  蓝队kubectl delete pod -n feature-service。红队检查Grafana“特征延迟P95”飙升，立即执行SOP第3步：启用本地缓存（Redis中预存的7天特征快照），同时通知特征团队紧急修复。缓存模式下，模型延迟从200ms升至350ms，但可用率保持100%。

• 故障2：GPU显存溢出
  蓝队用nvidia-smi -i 0 -r强制重置GPU，触发ONNX Runtime OOM。红队查看Prometheusgpu_memory_used_percent告警，执行SOP第5步：临时降低cuda_mem_limit参数，重启模型服务。1分钟内恢复，P95延迟回升至220ms。

• 故障3：模型逻辑错误
  蓝队偷偷修改ONNX模型，将Softmax层替换为Identity，导致输出未归一化。红队通过“影子流量”监控发现confidence值>1.0，立即触发回滚SOP，47秒内切回v2.1.2版本，准确率回归92.3%。

三次演练平均恢复时间（MTTR）为2分18秒，远低于SLA要求的5分钟。

5. 常见问题与排查技巧实录：来自72小时真实战场的速查表

5.1 “模型预测结果忽高忽低，但指标监控一切正常”——查特征缓存一致性

现象：P95延迟、GPU利用率、错误率都平稳，但业务方反馈“今天推荐的爆款商品变少了”。
排查路径：

1. 在Kibana中搜索trace_id:"req_*"，随机选10个成功请求，提取feature_batch_id；
2. 登录特征服务数据库，查该feature_batch_id对应的created_at时间戳；
3. 对比created_at与当前时间，若差>15分钟，说明特征新鲜度不足；
4. 进一步查特征管道日志，发现Spark作业因上游数据延迟而跳过今日调度。
   根治方案：在特征管道中加入data_delay_monitor，当上游数据延迟>10分钟，自动触发告警并暂停下游作业，避免陈旧特征污染模型。

5.2 “新模型上线后，部分用户收到‘503 Service Unavailable’”——查连接池耗尽

现象：错误率曲线出现尖峰，但只影响约5%的请求，且集中在特定时间段（如早10点）。
排查路径：

1. 查Envoy access log，过滤503，发现upstream_reset_before_response_started{reason="connection_failure"}；
2. 查模型服务Pod日志，发现ConnectionRefusedError；
3. 查kubectl top pods，发现模型服务Pod的RESTARTS列有数字；
4. 进一步查kubectl describe pod，发现OOMKilled事件。
   根治方案：在模型服务启动脚本中加入ulimit -n 65536，并配置Kubernetesresources.limits.memory="4Gi"，避免因文件描述符耗尽导致连接拒绝。

5.3 “AB测试结果显示新模型效果更好，但全量后业务指标反而下降”——查样本选择偏差

现象：AB测试A组CTR+12%，全量后整体CTR-3%。
排查路径：

1. 导出AB测试期间A/B组的用户画像分布（年龄、地域、设备类型）；
2. 发现A组中iOS用户占比68%，B组仅42%；
3. 进一步分析，发现前端SDK在iOS上对user_id采集率更高（因IDFA权限），而安卓用户大量未登录，被分到B组；
4. 验证：单独看iOS用户全量数据，CTR+9%，与AB结果一致；安卓用户全量CTR-8%。
   根治方案：AB测试必须按“用户粒度”而非“请求粒度”分流，且分流前强制校验user_id有效性，无效ID统一归入Control组。

5.4 “模型热更新后，延迟P95从200ms升到1200ms”——查GPU上下文切换开销

现象：更新瞬间延迟飙升，持续约3分钟，之后缓慢回落。
排查路径：

1. 查nvidia-smi dmon -s u，发现util（GPU利用率）在更新后持续>95%；
2. 查/proc/driver/nvidia/gpus/0000:00:00.0/information，确认GPU驱动版本；
3. 发现新模型使用了CUDA Graph优化，但旧驱动不支持，导致每次推理都重建计算图。
   根治方案：模型服务Dockerfile中固化NVIDIA_DRIVER_VERSION，CI/CD流水线增加驱动兼容性检查，不匹配则阻断发布。

5.5 “Prometheus里模型延迟指标突增，但Grafana看单个Pod延迟正常”——查服务发现延迟

现象：全局P95延迟告警，但查具体Pod指标都<300ms。
排查路径：

1. 查Envoy stats，发现cluster.model-service.upstream_rq_timeP95为1500ms；
2. 查cluster.model-service.upstream_cx_active，发现连接数远超Pod数；
3. 判断是Envoy与后端Pod间连接未复用；
4. 查Envoy配置，发现http_protocol_options未启用http2_protocol_options。
   根治方案：所有Envoy到模型服务的连接强制HTTP/2，并配置max_stream_duration: 60s，避免长连接僵死。

实操心得：我们把这5类问题编译成ml-troubleshooting-cheatsheet.pdf，放在内部Wiki首页。新成员入职第一周，必须用这份手册独立解决3个模拟故障，才算通过上岗考核。因为真正的ML工程能力，不体现在你多会调参，而体现在你面对一团乱麻的日志时，能否3分钟内抓住那个唯一正确的线索。

我在实际交付中发现，最有效的学习方式不是读文档，而是亲手制造一次故障再修复它。所以Part 4的结尾，我建议你立刻做一件事：挑一个你正在维护的模型服务，用kubectl delete pod干掉它的一个实例，然后打开你的监控大盘，盯着那几条曲线，像猎人一样寻找第一个异常信号——那个信号出现的时刻，就是你真正理解“生产环境”含义的开始。