1. 项目概述：这不是一次“部署上线”，而是一场从实验室到产线的系统性迁移

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被无数数据科学家反复咀嚼、又悄悄回避的真相： Jupyter Notebook 从来就不是生产环境的入口，它只是思考的草稿纸。 我在带团队做模型交付的七年里，亲手把超过83个模型从本地笔记本推上生产服务，其中61个在前三个月内遭遇了至少一次非预期中断——不是模型不准，而是日志打不出来、特征版本对不上、GPU显存突然爆掉、或者凌晨三点告警说“/tmp目录写满导致预测超时”。Part 4 这个编号很关键：它不是入门指南，不是API调用教学，更不是“用Flask包一层就完事”的速成幻觉；它是前三个阶段（数据管道固化、模型封装标准化、服务接口契约化）落地后，真正踩进泥地里的第四步： 让机器学习服务像水电一样稳定、可观测、可回滚、可协同演进。 它面向的是已经能跑通pipeline、写得出Dockerfile、配得动Prometheus指标的中级以上从业者；它解决的核心问题，是“为什么模型在测试集AUC 0.92，上线后第二天监控显示P99延迟飙升300%，且无人能定位是数据漂移、特征工程bug，还是K8s资源配额被其他服务挤占”。关键词“Notebook to Production”“ML in the Real World”直指行业最大断层——我们教人怎么炼金，却极少教人怎么建炼金炉、铺输气管道、装压力表和安全阀。这篇文章不讲理论，只讲我在金融风控、工业设备预测性维护、电商实时推荐三个高要求场景中，用真实故障单反推出来的第四阶段实操框架。

2. 内容整体设计与思路拆解：放弃“一键部署”，拥抱“四层防御体系”

很多人看到Part 4，第一反应是“终于要讲Kubernetes了？”——错了。K8s只是工具链中的一环，甚至不是最脆弱的一环。真正的设计起点，是重新定义“生产就绪”（Production-Ready）的四个刚性维度： 可观测性（Observability）、可复现性（Reproducibility）、可协作性（Collaborability）、可韧性（Resilience）。 这不是我拍脑袋列的，而是过去三年我们团队每月复盘线上事故根因后，按发生频次排序的TOP4。比如2023年Q2，我们72%的P1级故障，根源不在模型本身，而在“无法快速判断当前服务加载的是哪个特征版本+哪个模型权重+哪套配置参数”。所以Part 4的整体架构，彻底放弃了“从Notebook导出模型→打包→部署”的线性思维，转而构建一个 以元数据为中枢、以自动化为肌肉、以人工干预为最后保险的四层防御体系 ：

2.1 第一层：元数据驱动的全链路血缘追踪

核心不是记录“谁提交了代码”，而是强制绑定“某次预测请求”与“该请求所依赖的全部实体”：原始数据快照ID、特征生成SQL版本哈希、模型checkpoint路径、推理服务容器镜像tag、甚至GPU驱动版本号。我们不用自研系统，而是用MLflow Tracking Server + 自定义Hook + 数据库触发器组合实现。关键在于：所有这些元数据，必须在 每次预测请求进入服务入口时，自动注入到OpenTelemetry trace中 ，而不是事后靠日志grep。这样当P99延迟报警时，运维同学点开Jaeger，直接下钻就能看到“这1000次慢请求，全部命中了同一组特征计算逻辑，且该逻辑依赖的PostgreSQL物化视图昨天被DBA重建过”。

2.2 第二层：不可变基础设施下的环境一致性保障

“我的本地Notebook跑得好好的，为什么CI里test失败？”——这种问题在Part 4里是零容忍的。我们要求： 从Python解释器版本、PyTorch编译选项（是否启用CUDA Graph）、到Linux内核参数（vm.swappiness=1），全部通过Docker BuildKit的--build-arg和RUN指令硬编码进基础镜像。 特别强调一点：绝不允许在Dockerfile里写 pip install -r requirements.txt ，因为requirements.txt里写 scikit-learn>=1.0.0 这种模糊约束，在不同时间build会拉取不同小版本，而sklearn 1.2.3和1.2.4在稀疏矩阵处理上就有行为差异。我们的方案是：用 pip freeze > pinned-requirements.txt 生成带精确hash的锁定文件，并在CI阶段用 pip install --require-hashes -r pinned-requirements.txt 校验。实测下来，这套机制让跨环境模型输出差异率从12.7%降到0.03%（仅剩浮点计算微小误差）。

2.3 第三层：面向SRE的轻量级服务契约管理

很多团队卡在“模型服务怎么才算上线成功？”。我们定义了一套极简但致命的SLI（Service Level Indicator）：

• SLO 1：预测延迟P99 ≤ 150ms （针对实时推荐场景）
• SLO 2：特征计算成功率 ≥ 99.95% （失败即触发熔断）
• SLO 3：模型输出分布偏移（KS统计量）≤ 0.15 （超阈值自动告警并冻结新流量）
  这些SLO不是写在文档里，而是直接嵌入服务健康检查端点（ /healthz?detailed=true ）。K8s liveness probe每10秒调用一次，返回JSON包含所有SLO当前值及最近1小时趋势。当KS值连续3次超阈值，服务自动返回HTTP 503，并向Slack #ml-ops-alerts频道推送带traceID的告警卡片。这个设计让SRE无需懂模型，也能用标准手段接管ML服务生命周期。

2.4 第四层：灰度发布与原子化回滚能力

“上线即发布100%流量”是Part 4的第一条红线。我们强制所有服务接入Istio，但不用其复杂流量路由，只启用最基础的 VirtualService 权重分流。关键创新在于： 回滚不是“删掉新Pod，重启旧Deployment”，而是“将100%流量切回旧版本Service的ClusterIP，并保持新版本Pod运行24小时供问题复现”。 为什么？因为很多问题（如内存泄漏）需要数小时才显现。我们开发了一个轻量CLI工具 ml-rollback ，执行时自动完成三件事：① 更新Istio VirtualService权重；② 调用MLflow API标记当前上线版本为“deprecated”；③ 向Datadog发送事件标注“回滚触发，原因：KS偏移超限”。整个过程平均耗时8.3秒，比手动操作快27倍，且100%可审计。

这套四层体系的设计哲学很朴素： 不追求技术炫技，只解决“出了问题，3分钟内能否定位到根因”这个唯一指标。 所有工具选型都服从一个原则——当值班工程师凌晨三点被叫醒时，他打开电脑看到的第一个页面，必须能直接回答：“是数据的问题？模型的问题？还是基础设施的问题？”

3. 核心细节解析与实操要点：那些文档里绝不会写的硬核细节

Part 4的成败，往往藏在几个看似微小、实则致命的细节里。这些不是概念，是我在产线踩坑后，用胶带和订书钉临时修复，最终沉淀为标准流程的“野路子智慧”。

3.1 特征版本与模型版本的强绑定，不是靠约定，而是靠编译期注入

你肯定见过这样的代码：

# feature_generator.py
def get_user_features(user_id):
    return pd.read_sql(f"SELECT * FROM user_features_v2 WHERE id = {user_id}")

问题在哪？ v2 是硬编码字符串，一旦DBA把表名改成 user_features_v2_2024Q3 ，服务就崩。我们的解法是： 在模型训练Pipeline的最后一步，自动生成一个 feature_version_map.json ，内容为：

{
  "user_features": {"table": "user_features_v2_2024Q3", "version_hash": "a1b2c3..."},
  "item_embeddings": {"model_path": "gs://models/embedding_v4.2.1", "version_hash": "d4e5f6..."}
}

然后在Docker build阶段，把这个JSON作为构建参数传入，并在服务启动时，由一个 FeatureRegistry 单例类加载。关键点来了： 这个JSON文件的生成，必须和模型checkpoint保存在同一事务中。 我们用MLflow的 log_artifact 上传模型，同时用 log_dict 上传feature_version_map，确保两者在MLflow UI里永远成对出现。实测发现，这个机制让特征不一致类故障下降了91%。

3.2 GPU显存泄漏的终极排查法：不用nvidia-smi，用 torch.cuda.memory_stats()

很多团队遇到GPU OOM，第一反应是加 --gpus all 或调大 --memory 。错。真正的杀手是PyTorch的缓存机制。我们在服务里埋了一个定时任务：每30秒调用 torch.cuda.memory_stats(device) ，提取 "allocated_bytes.all.current" 和 "reserved_bytes.all.current" 两个关键指标，上报到Prometheus。当 reserved_bytes 持续增长而 allocated_bytes 平稳时，100%是缓存泄漏。根因通常是：

• 在 @torch.no_grad() 装饰器外写了 .cuda() 调用；
• 使用了 torch.jit.trace 但未调用 model.eval() ；
• DataLoader的 pin_memory=True 与多进程worker冲突。
  我们的修复方案是：在服务入口处强制插入：

import gc
gc.collect()
torch.cuda.empty_cache()

并在每个预测函数末尾，显式调用 del tensor; gc.collect(); torch.cuda.empty_cache() 。别笑，这套“暴力三连”让GPU显存占用曲线从锯齿状变成一条直线，单卡并发能力提升2.3倍。

3.3 模型输出分布监控：不用复杂的PSI，用滚动窗口KS检验

很多方案推荐用Population Stability Index（PSI），但它对小样本敏感，且阈值难设定。我们改用Kolmogorov-Smirnov检验，但做了关键改造： 不是拿线上预测结果vs训练集分布比，而是拿“最近1000个预测结果”vs“前一小时的1000个预测结果”滚动比。 这样做的好处是：能捕捉到缓慢漂移（如用户行为随季节变化），也能识别突发异常（如某次特征工程bug导致大量负值输出）。KS统计量计算用 scipy.stats.ks_2samp ，但采样策略是：对预测结果数组，先做 np.quantile(..., q=[0.01, 0.99]) 截断，再抽样。为什么？避免极端离群值污染统计。实测表明，这个滚动KS方案比固定基准PSI提前17分钟发现数据漂移，且误报率降低64%。

3.4 日志不是为了“看”，是为了“查”：结构化日志的强制字段规范

我们禁用所有 print() 和 logger.info("predict success") 。所有日志必须是JSON格式，且强制包含以下字段：

• request_id : UUID4，由Nginx upstream传递；
• model_version : 从MLflow Model Registry读取；
• feature_hash : 对 feature_version_map.json 内容做sha256；
• inference_time_ms : 预测函数执行耗时，单位毫秒；
• output_distribution : 仅记录 min , max , mean , std ，不记原始数组（防日志爆炸）。
  最关键的是： 所有日志必须写入 /dev/stdout ，且用 sys.stdout.write(json.dumps(log_dict) + "\n") ，禁用任何日志库的缓冲。 为什么？因为K8s的 kubectl logs 命令，只有stdout/stderr是实时可读的。曾有个案例：某服务用loguru异步写文件，结果故障时 kubectl logs 返回空，运维以为服务没启动，实际是日志全在容器内某个 /var/log/ml-service.log 里，等SSH进去查，黄金15分钟已过。现在， kubectl logs -f ml-service-7b8c9d | jq '.output_distribution' ，3秒内看到分布异常。

提示：在Dockerfile里务必添加 ENV PYTHONUNBUFFERED=1 ，否则Python的print默认行缓冲，日志会延迟数秒才刷出。

4. 实操过程与核心环节实现：从Notebook到生产服务的完整流水线

现在，让我们把上述设计，变成可执行的代码和配置。以下是一个真实投产的简化版全流程，基于一个电商实时点击率预测模型（输入：用户ID、商品ID、上下文特征；输出：CTR概率）。所有步骤均已在AWS EKS集群验证。

4.1 步骤一：Notebook中的“生产意识”改造

原始Notebook可能长这样：

# train_model.ipynb
import pandas as pd
from sklearn.ensemble import RandomForestClassifier
df = pd.read_parquet("s3://data/raw/train.parquet")
model = RandomForestClassifier()
model.fit(df.drop("label", axis=1), df["label"])
joblib.dump(model, "model.pkl")

改造后，必须增加三段“生产钩子”：

① 元数据注册（训练结束时）：

import mlflow
mlflow.set_tracking_uri("http://mlflow-server:5000")
with mlflow.start_run():
    mlflow.log_param("n_estimators", 100)
    mlflow.log_metric("val_auc", 0.923)
    # 关键：记录特征版本映射
    feature_map = {
        "user_features": {"table": "user_features_v2_2024Q3", "hash": "a1b2c3..."},
        "item_features": {"table": "item_features_v1_2024Q3", "hash": "d4e5f6..."}
    }
    mlflow.log_dict(feature_map, "feature_version_map.json")
    # 保存模型（自动记录conda env）
    mlflow.sklearn.log_model(model, "model")

② 模型签名定义（明确输入输出Schema）：

from mlflow.models.signature import infer_signature
import numpy as np
# 构造示例输入（必须与生产请求结构一致）
sample_input = np.array([[12345, 67890, 0.8, 1.2, 0.0]])  # user_id, item_id, feat1, feat2, feat3
signature = infer_signature(sample_input, model.predict_proba(sample_input)[:, 1])
mlflow.sklearn.log_model(model, "model", signature=signature)

这一步生成的 signature.json ，会被后续服务框架用于自动校验请求体合法性。

③ 生成Dockerfile模板（用Jinja2动态注入）：

# Dockerfile.j2
FROM python:3.9-slim
# 注入精确依赖
COPY pinned-requirements.txt .
RUN pip install --require-hashes -r pinned-requirements.txt
# 注入模型和特征映射
COPY {{ model_path }} /app/model/
COPY {{ feature_map_path }} /app/config/
# 关键：设置不可变环境
ENV PYTHONUNBUFFERED=1
ENV TORCH_CUDA_ARCH_LIST="6.0;6.1;7.0;7.5;8.0;8.6"
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "app:app"]

注意： TORCH_CUDA_ARCH_LIST 必须显式声明，否则PyTorch会在运行时探测GPU架构，导致首次预测延迟高达3秒。

4.2 步骤二：构建可复现的服务镜像

CI脚本（GitHub Actions）核心片段：

- name: Pin dependencies
  run: |
    pip install -r requirements-dev.txt
    pip freeze > pinned-requirements.txt
    # 生成特征映射（调用内部API）
    curl -s "https://feature-api/v1/version?env=prod" > feature_version_map.json

- name: Build and push image
  uses: docker/build-push-action@v4
  with:
    context: .
    push: true
    tags: ${{ secrets.REGISTRY }}/ml-ctr:${{ github.sha }}
    cache-from: type=registry,ref=${{ secrets.REGISTRY }}/ml-ctr:latest
    cache-to: type=registry,ref=${{ secrets.REGISTRY }}/ml-ctr:latest,mode=max
    # 关键：构建参数注入
    build-args: |
      MODEL_PATH=./mlruns/0/${{ env.MLFLOW_RUN_ID }}/artifacts/model
      FEATURE_MAP_PATH=./feature_version_map.json

这里 build-args 将Notebook中生成的模型路径和特征映射，作为构建时变量传入Dockerfile，确保镜像内路径绝对准确。

4.3 步骤三：K8s部署与Istio灰度配置

deployment.yaml 精简版：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-ctr-v1
spec:
  template:
    spec:
      containers:
      - name: predictor
        image: $REGISTRY/ml-ctr:{{ .Values.version }}
        env:
        - name: MLFLOW_TRACKING_URI
          value: "http://mlflow-server:5000"
        - name: FEATURE_MAP_PATH
          value: "/app/config/feature_version_map.json"
        resources:
          limits:
            nvidia.com/gpu: 1
            memory: "4Gi"
          requests:
            nvidia.com/gpu: 1
            memory: "4Gi"
        # 关键：Liveness probe调用健康检查端点
        livenessProbe:
          httpGet:
            path: /healthz?detailed=true
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 10

virtualservice.yaml （Istio灰度）：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ml-ctr
spec:
  hosts:
  - ml-ctr.prod.svc.cluster.local
  http:
  - route:
    - destination:
        host: ml-ctr-v1
        subset: v1
      weight: 90
    - destination:
        host: ml-ctr-v2
        subset: v2
      weight: 10

新版本上线时，只需修改 weight 并 kubectl apply ，流量秒级切换。

4.4 步骤四：可观测性集成与告警闭环

Prometheus告警规则（ ml-ctr-alerts.yml ）：

- alert: ML_CTR_KS_DRIFT_HIGH
  expr: histogram_quantile(0.95, sum(rate(ks_stat_bucket[1h])) by (le)) > 0.15
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "CTR output distribution drift detected"
    description: "KS statistic > 0.15 for 5 minutes. Check MLflow run {{ $labels.run_id }}"

- alert: ML_CTR_GPU_MEMORY_LEAK
  expr: (container_memory_usage_bytes{container="predictor", job="kubernetes-cadvisor"}[1h]) - (container_memory_usage_bytes{container="predictor", job="kubernetes-cadvisor"}[1h] offset 30m) > 1e9
  for: 10m
  labels:
    severity: critical

告警触发后，通过Alertmanager路由到PagerDuty，并自动执行：

# 自动化响应脚本
curl -X POST "https://api.pagerduty.com/incidents" \
  -H "Authorization: Token token=$PD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "incident": {
      "type": "incident",
      "title": "ML-CTR KS Drift",
      "service": {"id": "PB12345", "type": "service_reference"},
      "body": {"type": "incident_body", "details": "Run ml-rollback --reason ks_drift --run-id 'abc123'"}
    }
  }'

这就是Part 4的终极形态： 告警不仅是通知，更是可执行的运维指令。

5. 常见问题与排查技巧实录：来自产线的37份故障单分析

我把过去一年处理的37份P1/P2级ML服务故障单，按根因归类，提炼出最常被问、也最容易被忽略的12个问题。每个问题都附带真实现场截图（文字描述）和独家排查口诀。

5.1 “模型预测结果和本地Notebook不一致”——90%是特征计算路径不同

典型现象：

• 本地 model.predict([[1,2,3]]) 返回 [0.87]
• 线上 curl -X POST ... -d '{"user_id":1,"item_id":2,"context":[3]}' 返回 [0.42]
  根因分析：
  本地Notebook用 pandas.read_csv() 读原始CSV，线上服务用 spark.read.parquet() 读预处理后Parquet，而Parquet的schema推断把 user_id 当成了 int32 ，但CSV里是 int64 ，导致特征缩放器（StandardScaler）输入类型不匹配。
  排查口诀：

“三查一比”：查服务日志里的 input_shape ，查特征生成SQL的 DESCRIBE TABLE ，查模型 signature.json 的 input 字段dtype，最后用 np.array_equal() 比对本地和线上特征向量的 numpy.dtype 。
终极解法：
在特征生成服务里，强制 cast("bigint") 所有ID类字段，并在模型签名中明确写 "type": "integer", "minimum": 0, "maximum": 9223372036854775807 。

5.2 “服务启动后CPU 100%，但无请求”——PyTorch DataLoader的幽灵线程

典型现象：
K8s Pod启动后， top 显示Python进程CPU 98%， lsof -i 无网络连接， strace -p <pid> 显示大量 futex 系统调用。
根因分析：
DataLoader的 num_workers>0 ，但主进程未加 if __name__ == '__main__': 保护，导致子进程递归启动新DataLoader，形成fork炸弹。
排查口诀：

“看进程树”： ps -ef | grep python | grep -v grep ，若看到 python app.py 下面挂了5个 python app.py ，就是它。
终极解法：
服务入口 app.py 必须：

if __name__ == '__main__':
    # 初始化模型、特征注册器等
    app.run(host='0.0.0.0', port=8000)

且DataLoader创建必须在 if __name__ == '__main__': 块内，或设 num_workers=0 （线上服务我们一律设0，用asyncio并发替代）。

5.3 “P99延迟突增，但CPU/MEM正常”——gRPC Keepalive心跳风暴

典型现象：
服务部署在K8s， kubectl top pod 显示资源正常，但 istioctl proxy-status 发现Sidecar Envoy连接数暴涨至5000+， kubectl logs ml-ctr-xxx -c istio-proxy | grep "upstream reset" 高频出现。
根因分析：
客户端gRPC配置了 keepalive_time=30s ，但服务端未配置 GRPC_ARG_KEEPALIVE_TIME_MS ，导致客户端每30秒发心跳，服务端无响应，连接堆积。
排查口诀：

“查Envoy统计”： istioctl proxy-config listeners ml-ctr-xxx | grep -A 10 "listener_0.0.0.0_8000" ，看 per_connection_buffer_limit_bytes 是否为0（默认值），若是，则心跳包被丢弃。
终极解法：
在服务启动脚本中添加：

export GRPC_ARG_KEEPALIVE_TIME_MS=60000
export GRPC_ARG_KEEPALIVE_TIMEOUT_MS=20000

并确保客户端 keepalive_time >= 服务端GRPC_ARG_KEEPALIVE_TIME_MS 。

5.4 “模型输出全是NaN”——CUDA运算的静默失败

典型现象：
GPU服务返回 {"prediction": [null, null, null]} ，日志无ERROR， nvidia-smi 显示GPU利用率0%。
根因分析：
模型中某层（如LayerNorm）输入含Inf/NaN，CUDA kernel静默失败，PyTorch不抛异常， model(input) 返回全NaN张量。
排查口诀：

“三步定位”：① torch.isfinite(input).all() 检查输入；② torch.autograd.set_detect_anomaly(True) 开启异常检测；③ 在 forward 函数每层后加 assert torch.isfinite(x).all(), f"NaN at layer {name}" 。
终极解法：
在数据预处理Pipeline中，强制 df = df.replace([np.inf, -np.inf], np.nan).dropna() ，并在服务入口加：

def validate_input(x):
    if not torch.isfinite(x).all():
        raise ValueError(f"Input contains Inf/NaN. Shape: {x.shape}")

5.5 “服务间歇性503，重启即恢复”——K8s readiness probe的陷阱

典型现象：
服务健康检查端点 /readyz 返回200，但 /predict 偶发503， kubectl describe pod 显示 Readiness probe failed: HTTP probe failed with statuscode: 503 。
根因分析：
/readyz 只检查进程存活，但 /predict 需加载大模型到GPU，首次加载耗时2.3秒，而readiness probe的 timeoutSeconds=1 ，导致probe超时，K8s认为服务未就绪，切断流量。
排查口诀：

“看probe日志”： kubectl logs ml-ctr-xxx | grep "readyz" ，若看到 "status":"starting","model_load_time_ms":2300 ，就是它。
终极解法：
readinessProbe 配置：

readinessProbe:
  httpGet:
    path: /readyz
    port: 8000
  initialDelaySeconds: 60  # 给足模型加载时间
  timeoutSeconds: 5        # 探针本身不能超时
  periodSeconds: 10

并在 /readyz 端点里，加入 if model_loaded and gpu_available: return 200 。

5.6 “特征计算成功率99.94%，差0.01%卡上线”——数据库连接池耗尽

典型现象：
特征服务日志高频出现 "ConnectionRefusedError: [Errno 111] Connection refused" ，但数据库监控显示连接数远低于上限。
根因分析：
PostgreSQL默认 max_connections=100 ，但应用层用 sqlalchemy.create_engine(pool_size=20, max_overflow=30) ，20个Worker各开20连接，理论峰值400连接，远超DB限制。
排查口诀：

“查DB连接”： SELECT count(*) FROM pg_stat_activity; ，若接近100，且 state='idle in transaction' 的连接多，就是连接泄漏。
终极解法：
在特征服务里，用 contextlib.closing() 确保 connection.close() ，并设 pool_pre_ping=True ，让SQLAlchemy每次取连接前先 SELECT 1 探测。

（以下问题因篇幅限制简述，但均经产线验证）

• Q7：模型AUC下降，但KS正常？ → 查 output_distribution.std ，标准差骤降说明模型“不敢预测”，大概率是正则化过强或学习率衰减错误。
• Q8：Istio灰度流量不均？ → 检查 VirtualService 的 trafficPolicy.loadBalancer.simple: ROUND_ROBIN 是否显式声明，K8s Service默认是SessionAffinity。
• Q9：MLflow UI看不到模型？ → 检查 MLFLOW_TRACKING_URI 是否指向Server的ClusterIP而非NodePort，后者在Pod内DNS解析失败。
• Q10：GPU显存碎片化？ → 不用 nvidia-smi ，用 torch.cuda.memory_summary() 看 [CUDA out of memory] 前的 reserved but unused 占比，超40%需重启。
• Q11：Prometheus指标延迟5分钟？ → 检查 scrape_interval 是否设为 30s ，但 scrape_timeout 为 10s ，超时导致采样丢失。
• Q12：回滚后旧版本报错？ → 查 feature_version_map.json 里旧版本的 table 名是否已被DBA归档，需同步更新映射。

注意：所有问题排查，第一步永远不是改代码，而是 kubectl exec -it ml-ctr-xxx -- sh 进入容器，运行 curl -s localhost:8000/healthz?detailed=true | jq 。90%的故障，答案就在这行JSON里。

6. 工具链与生态整合：不做重复造轮子，但必须掌控关键节点

Part 4的成功，不取决于用了多少酷炫工具，而在于是否在关键决策点保留了人工控制权。我们坚持“三不原则”： 不黑盒、不托管、不跳过验证。 下面是当前稳定运行的工具链全景，每个组件都标注了“为什么选它”和“必须自定义什么”。

6.1 元数据与模型管理：MLflow（开源版）

为什么选它？

• 轻量：单进程Server，无ZooKeeper/Kafka依赖，运维成本≈0；
• 开放：REST API完备，所有元数据可直接 curl 读取，不锁死；
• 社区强： mlflow.pyfunc 支持任意框架模型， mlflow.sklearn 等子模块成熟。
  必须自定义：
• backend_store_uri 必须用PostgreSQL（非默认file store），否则并发写入丢数据；
• default_artifact_root 必须指向S3兼容存储（如MinIO），并配置 AWS_PROFILE ；
• 在 mlflow server 启动参数加 --host 0.0.0.0 --port 5000 --workers 4 ，否则默认单线程扛不住高并发注册。

6.2 服务编排：Kubernetes + Istio（最小集）

为什么选它？

• K8s是事实标准，Istio的 VirtualService 是目前最成熟的灰度方案；
• 我们只用Istio的 IngressGateway 和 VirtualService ，禁用 Sidecar 自动注入（太重），改用 istioctl kube-inject 手动注入。
  必须自定义：
• istio-ingressgateway 的 service.type=LoadBalancer 改为 NodePort ，避免云厂商LB费用；
• VirtualService 的 timeout 必须显式设为 30s ，否则默认0（无限），导致上游超时级联。

6.3 可观测性：Prometheus + Grafana + OpenTelemetry

为什么选它？

• Prometheus的Pull模型天然适配K8s，Grafana仪表盘可共享；
• OpenTelemetry是CNCF毕业项目， opentelemetry-python SDK成熟，且 traces_exporter 支持Jaeger/Zipkin双后端。
  必须自定义：
• Prometheus的 scrape_configs 中， kubernetes_sd_configs 必须加 role: endpoints ，否则抓不到Pod级指标；
• OpenTelemetry的 TracerProvider 必须设 active_span_processor=BatchSpanProcessor ，否则高并发下Span丢失。

6.4 CI/CD：GitHub Actions（自托管Runner）

为什么选它？

• 免费额度够用，YAML语法清晰；
• 自托管Runner可装NVIDIA驱动、CUDA Toolkit，解决GPU镜像构建难题。
  必须自定义：
• Runner的 config.toml 中， concurrent = 1 （GPU构建必须串行）， environment = ["DOCKER_BUILDKIT=1"] ；
• Workflow中所有 run 步骤，必须加 shell: bash -euxo pipefail {0} ， -e 确保任一命令失败即终止。

6.5 特征存储：自研轻量服务（非Feast/Delta）

为什么自研？

• Feast太重，Delta Lake学习成本高；
• 我们的特征90%是静态表（用户画像、商品属性），用PostgreSQL物化视图+Redis缓存，QPS 2万+，延迟<5ms。
  必须自定义：
• PostgreSQL的 pg_cron 插件，每天凌晨2点自动 REFRESH MATERIALIZED VIEW CONCURRENTLY ；
• Redis缓存Key格式： feature:{table_name}:{id} ，TTL设为 3600 （1小时），避免陈旧数据。

这套工具链没有一个是“银弹”，但每个都经过产线千锤百炼。我的经验是： 宁可用10个简单工具拼出可靠系统，也不用1个全能工具换来黑盒风险。 当你的值班工程师能在3分钟内，用 kubectl + curl + jq 三命令定位90%问题时，你就真正跨过了