企业官网建设流程全解析

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

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被日常忽略的真相。它不是教你怎么把model.fit()换成model.predict()，也不是演示一个带Flask接口的demo跑通了就算完事。它直指机器学习落地中最顽固的断层：数据科学家在Jupyter里调出0.92的AUC，运维工程师在K8s集群里看到CPU飙到98%、延迟毛刺突破3秒、模型输出开始返回NaN——而两边用的居然是同一份代码、同一个Git commit。我做过7个从0到1的ML生产化项目，其中4个在第三周就退回重做，原因全出在Part 4这个阶段：当模型要真正扛住用户请求、日志要能定位到具体某条样本的推理链路、特征更新要和业务数据库变更强一致、AB测试流量要精确到千分之一——这时候，Notebook里那套“先跑通再优化”的思维，会立刻变成系统性风险的放大器。核心关键词——ML生产化、模型服务化、特征一致性、可观测性、CI/CD for ML——它们不是技术选型清单，而是五道必须同时答对的考题。适合谁？如果你是刚把模型精度刷到SOTA、正准备提PR给工程团队的数据科学家；如果你是接到“明天上线模型”通知、但手头只有.pkl文件和一句“它应该能work”的后端工程师；或者你是技术负责人，发现团队每月花40%工时在救火而非迭代——这篇就是为你写的实战手记。它不讲理论推导，只记录我在金融风控、电商推荐、IoT设备预测三个真实场景中，如何用最小改动让模型从“能跑”变成“敢用”。

2. 整体设计思路：为什么放弃“一键部署”，选择“分层解耦+渐进式接管”

2.1 拒绝“黑盒打包”：从Notebook到服务的三重失真

很多团队第一反应是找工具：“用BentoML打包”“用KServe部署”“用MLflow注册模型”。我试过全部，结果发现：工具越强大，掩盖的问题越深。根本矛盾在于Notebook天然存在的三重失真：

• 环境失真：Notebook里pip install xgboost==1.7.6，生产环境Docker镜像用的是conda-forge源，版本锁死在1.6.2——XGBoost 1.7引入的enable_categorical参数在1.6里直接报错，但错误日志只显示TypeError: predict() got an unexpected keyword argument，排查耗时6小时。

• 数据失真：Notebook里pd.read_csv('data/train.csv')读取本地文件，生产环境特征服务（Feature Store）返回的是Dict[str, np.ndarray]，类型不匹配导致sklearn预处理器崩溃，而异常被上层HTTP框架吞掉，只返回500。

• 逻辑失真：Notebook里写if pd.isna(row['age']): row['age'] = 25做缺失值填充，生产环境上游ETL已将age字段转为INT NOT NULL，该逻辑永远不触发——但模型训练时用了填充值，线上却用原始值，特征分布偏移（Covariate Shift）悄然发生。

所以Part 4的设计起点很朴素：不追求“一步到位上线”，而追求“每一步都可验证、可回滚、可度量”。我们把整个迁移拆成四个物理隔离层：

1. 计算层（Compute Layer）：模型推理逻辑本身，要求纯函数式、无状态、输入输出严格定义；
2. 数据层（Data Layer）：特征获取与预处理，必须与线上特征服务API完全对齐；
3. 服务层（Serving Layer）：HTTP/gRPC接口、负载均衡、熔断限流，与模型逻辑彻底解耦；
4. 观测层（Observability Layer）：从请求ID贯穿到特征值、模型版本、GPU显存占用的全链路追踪。

提示：不要试图用一个工具覆盖所有层。我见过团队用KServe强行注入特征预处理逻辑，结果每次特征Schema变更都要重建整个Serving镜像，CI/CD流水线卡在镜像构建环节长达22分钟——这违背了“快速迭代”的初衷。

2.2 渐进式接管策略：灰度发布不是功能，而是架构契约

“灰度发布”常被理解为流量比例控制（如10%用户走新模型）。但在ML生产化中，它首先是架构层面的契约。我们在金融风控场景落地时，强制约定三条红线：

• 数据契约：新模型服务必须能接收旧版特征服务返回的v1.2Schema，并向下兼容；同时自身输出必须包含model_version、feature_schema_version、inference_latency_ms三个必填字段，供下游监控系统消费。

• 行为契约：新模型在相同输入下，输出概率值偏差必须<0.001（浮点精度内），否则自动触发告警并切回旧服务。这个阈值不是拍脑袋定的——我们用生产环境最近7天的10万条真实请求做离线比对，统计99.9分位偏差值，取整后加安全余量。

• 资源契约：单实例P95延迟≤120ms，CPU使用率≤65%，内存常驻≤1.8GB。这些不是SLA指标，而是部署前的准入检查项。K8s HPA扩容阈值就设在这组数字上，避免“模型越准越慢”的陷阱。

这套契约让灰度不再是“赌一把”，而是变成可编程的自动化流程。当新模型通过全部契约检查，CI/CD流水线才允许执行kubectl set image命令——此时人工干预已退出关键路径。

2.3 工具链选型逻辑：为什么用FastAPI不用Flask，为什么弃用Triton选ONNX Runtime

工具没有优劣，只有是否匹配你的约束条件。我们放弃Triton的决策过程值得展开：

• Triton优势：原生支持TensorRT加速、多模型并发、动态批处理（Dynamic Batching）。
• 我们的约束：
  • 模型类型混合（XGBoost/LightGBM占比65%，PyTorch占比28%，TF 7%）；
  • 特征预处理逻辑复杂（需调用外部Redis缓存、调用内部HTTP API获取用户画像）；
  • 运维团队熟悉Python生态，不希望引入CUDA版本管理新技能树。

Triton的Dynamic Batching在混合模型场景下反而成为瓶颈——它要求所有模型输入tensor shape严格一致，而XGBoost的[batch_size, n_features]和PyTorch的[batch_size, seq_len, hidden_dim]根本无法统一。我们实测发现：开启Dynamic Batching后，XGBoost模型延迟反而增加40%，因为Triton需要做额外的shape校验和内存拷贝。

最终选择ONNX Runtime + FastAPI组合，理由很务实：

• ONNX Runtime对XGBoost/LightGBM/PyTorch/TF的ONNX导出支持成熟，且提供InferenceSession级别的CPU/GPU绑定控制；
• FastAPI的Pydantic模型校验天然契合ML输入输出定义（例如class InferenceRequest(BaseModel): user_id: str; features: List[float]），自动生成OpenAPI文档，前端调试效率提升3倍；
• 最关键的是：所有预处理逻辑可写在FastAPI路由函数内，用标准Python调试，无需学习新DSL。当某次线上特征计算错误时，我们直接在FastAPI日志里看到redis.get(user_id+'_profile') returned None，5分钟定位到Redis连接池耗尽问题——这种调试体验，是任何黑盒推理服务器给不了的。

3. 核心细节解析：从Notebook代码到生产服务的七处致命改造

3.1 输入输出契约化：用Pydantic强制定义数据边界

Notebook里常见的def predict(df)在生产环境是灾难源头。我们必须把“任意DataFrame”变成“有明确Schema的结构化数据”。以电商推荐场景为例，原始Notebook代码：

# notebook.py def predict(user_df, item_df): # 合并用户特征、商品特征、交叉特征 merged = user_df.merge(item_df, on='user_id') # 调用训练好的LightGBM模型 return lgb_model.predict(merged[feature_cols])

生产化改造后：

# api/schema.py from pydantic import BaseModel, Field from typing import List, Optional class UserFeature(BaseModel): user_id: str = Field(..., description="用户唯一标识") age_group: str = Field(..., regex="^(young|middle|senior)$") last_purchase_days: int = Field(..., ge=0, le=365) class ItemFeature(BaseModel): item_id: str = Field(..., description="商品唯一标识") category: str = Field(..., description="商品一级类目") price_bucket: float = Field(..., ge=0.0) class InferenceRequest(BaseModel): user: UserFeature items: List[ItemFeature] context: dict = Field(default_factory=dict) # 保留扩展字段 class InferenceResponse(BaseModel): predictions: List[float] = Field(..., description="每个商品的点击概率") model_version: str = Field(..., description="当前服务的模型版本") latency_ms: float = Field(..., description="端到端处理延迟")

注意：Field(..., regex=...)和Field(..., ge=0, le=365)不是装饰，是运行时强制校验。当上游传入age_group="teenager"时，FastAPI直接返回422错误，根本不会进入模型推理逻辑——这避免了因数据脏导致的模型静默失败。

3.2 特征获取去中心化：拒绝“模型内嵌特征工程”

Notebook里pd.read_parquet('s3://feature-bucket/user_v3.parquet')这种写法，在生产环境等于埋雷。我们要求所有特征必须通过统一特征服务（Feature Store）API获取，且API调用必须满足：

• 超时硬限制：单次HTTP请求≤200ms，超时则降级为默认特征（如age_group="unknown"），并记录feature_fetch_timeout告警；
• 熔断机制：连续5次超时，自动切断该特征源，切换至备用缓存（Redis中预热的7天快照）；
• Schema强校验：API返回JSON必须符合OpenAPI定义的Schema，缺失字段或类型错误立即抛出FeatureSchemaMismatchError。

实现代码片段（简化版）：

# feature_client.py import httpx from tenacity import retry, stop_after_attempt, wait_exponential class FeatureClient: def __init__(self, base_url: str): self.client = httpx.Client(base_url=base_url, timeout=200.0) @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10)) def get_user_features(self, user_id: str) -> UserFeature: try: resp = self.client.get(f"/users/{user_id}", timeout=200.0) resp.raise_for_status() data = resp.json() # Pydantic自动校验并转换类型 return UserFeature(**data) except httpx.TimeoutException: logger.warning(f"Feature fetch timeout for user {user_id}") raise FeatureFetchTimeoutError() except ValidationError as e: logger.error(f"Feature schema mismatch: {e}") raise FeatureSchemaMismatchError()

这个设计让特征问题变得“可感知”。当某天特征服务升级导致last_purchase_days字段从int变成string，我们第一时间在日志里看到ValidationError: 1 validation error for UserFeature last_purchase_days value is not a valid integer，而不是等模型输出全乱了才发现。

3.3 模型加载单例化：解决冷启动与内存泄漏

Notebook里lgb_model = lgb.Booster(model_file='model.txt')在Web服务里会引发两个问题：

• 冷启动延迟：每次HTTP请求都重新加载模型，1.2GB模型加载耗时2.3秒；
• 内存泄漏：FastAPI默认多进程模式（Uvicorn workers），每个worker进程都加载一份模型副本，4核机器内存暴涨4.8GB。

解决方案：模型加载与Web服务进程分离，通过共享内存或进程间通信（IPC）传递。我们采用更轻量的方案——全局单例+懒加载：

# model_loader.py import threading from typing import Optional import lightgbm as lgb class ModelLoader: _instance = None _lock = threading.Lock() _model: Optional[lgb.Booster] = None def __new__(cls): if cls._instance is None: with cls._lock: if cls._instance is None: cls._instance = super().__new__(cls) return cls._instance def get_model(self) -> lgb.Booster: if self._model is None: with self._lock: if self._model is None: logger.info("Loading LightGBM model...") self._model = lgb.Booster(model_file="/models/lgb_v4.2.txt") logger.info("Model loaded successfully") return self._model # 在FastAPI应用启动时预热 @app.on_event("startup") async def startup_event(): model_loader = ModelLoader() model_loader.get_model() # 强制加载

实操心得：不要依赖@lru_cache或functools.cache，它们在多进程环境下不共享缓存。必须用threading.Lock保证单例，且get_model()方法要加日志——某次线上事故就是因模型文件路径写错，get_model()静默返回None，直到第一个请求进来才报错，而错误日志被淹没在海量请求中。

3.4 推理过程可观测：从“黑盒预测”到“白盒追踪”

生产环境最怕“模型突然不准了”，但更怕“不知道哪里不准”。我们要求每次推理必须生成可追溯的Trace ID，并记录关键节点：

实现上，我们用OpenTelemetry注入Trace Context：

# tracing.py from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor from opentelemetry.exporter.jaeger.thrift import JaegerExporter provider = TracerProvider() processor = BatchSpanProcessor(JaegerExporter(agent_host_name="jaeger", agent_port=6831)) provider.add_span_processor(processor) trace.set_tracer_provider(provider) # 在FastAPI路由中 @app.post("/predict") async def predict(request: InferenceRequest): tracer = trace.get_tracer(__name__) with tracer.start_as_current_span("ml_inference_pipeline") as span: span.set_attribute("user_id", request.user.user_id) # 记录各阶段 with tracer.start_as_current_span("feature_fetch") as feat_span: user_feat = await feature_client.get_user_features(request.user.user_id) feat_span.set_attribute("fetch_time_ms", time.time() - start_time) with tracer.start_as_current_span("model_inference") as model_span: input_array = construct_input(user_feat, request.items) pred = model_loader.get_model().predict(input_array) model_span.set_attribute("gpu_memory_mb", get_gpu_memory())

这套追踪让我们在某次大促期间快速定位到问题：feature_fetch阶段耗时突增，进一步下钻发现是用户画像API响应时间从50ms涨到800ms，根源是Redis主从同步延迟——而模型本身性能完全正常。

3.5 错误处理防御化：定义四层错误分类与降级策略

Notebook里try...except Exception as e:在生产环境毫无意义。我们按影响范围定义四层错误：

关键实践：所有降级策略必须预验证。例如L2降级用的默认特征，必须在CI阶段用历史数据跑一遍，确保降级后AUC下降不超过0.02——否则降级等于失效。

3.6 日志结构化：让每一行日志都成为分析线索

生产环境日志不是给人看的，是给ELK/Splunk分析的。我们强制所有日志JSON化，并注入关键上下文：

{ "timestamp": "2024-06-15T08:23:41.123Z", "level": "INFO", "service": "ml-recommender", "version": "v4.2.1", "trace_id": "0a1b2c3d4e5f6789", "span_id": "fedcba9876543210", "user_id": "U123456", "model_version": "lgb-v4.2", "feature_source": "redis", "latency_ms": 87.4, "message": "Inference completed" }

注意：user_id和trace_id必须出现在每条日志中。某次排查发现某类用户点击率骤降，我们直接在Kibana里用user_id: U* AND latency_ms > 1000筛选，发现是特定地域用户IP段被防火墙拦截，导致特征服务超时——这种关联分析，靠非结构化日志根本做不到。

3.7 配置中心化：告别config.py硬编码

Notebook里MODEL_PATH = "/home/user/models/v4.2/"这种写法必须消灭。我们用Consul做配置中心，关键配置项：

热重载模型的核心代码：

# config_watcher.py import consul import threading import json class ConfigWatcher: def __init__(self, host="consul", port=8500): self.c = consul.Consul(host=host, port=port) self.model_version = self._get_model_version() def _get_model_version(self) -> str: _, data = self.c.kv.get("model/version") return json.loads(data["Value"])["version"] if data else "lgb-v4.1" def watch_config(self): index = None while True: try: index, data = self.c.kv.get("model/version", index=index) if data and data["Value"]: new_version = json.loads(data["Value"])["version"] if new_version != self.model_version: logger.info(f"Model version changed from {self.model_version} to {new_version}") self.model_version = new_version # 触发模型重载 model_loader.reload_model(new_version) except Exception as e: logger.error(f"Config watch error: {e}") time.sleep(5) # 启动监听线程 watcher = ConfigWatcher() threading.Thread(target=watcher.watch_config, daemon=True).start()

这套机制让我们在某次紧急修复中，5分钟内完成模型版本切换，全程零请求失败——而传统方式需要修改代码、走CI/CD、滚动更新Pod，耗时25分钟。

4. 实操全流程：从本地验证到全链路压测的12个关键步骤

4.1 步骤1-3：本地沙箱验证（耗时≈2小时）

目标：确认Notebook代码能在无网络依赖下完成端到端推理。

1. 环境克隆：用pipreqs . --savepath requirements.txt提取Notebook依赖，创建干净虚拟环境：

   python -m venv ml-prod-env source ml-prod-env/bin/activate pip install -r requirements.txt

2. 数据脱敏：从生产库抽样1000条真实请求，用faker库替换敏感字段（user_id→U_fake_123），保存为test_data.json。

3. 离线推理脚本：编写local_test.py，模拟生产环境调用链：

   # local_test.py from api.schema import InferenceRequest, InferenceResponse from feature_client import FeatureClient from model_loader import ModelLoader # 禁用真实特征服务，用mock替代 class MockFeatureClient: def get_user_features(self, user_id): return UserFeature(user_id=user_id, age_group="young", last_purchase_days=5) # 执行推理 req = InferenceRequest( user=MockFeatureClient().get_user_features("U123"), items=[ItemFeature(item_id="I456", category="electronics", price_bucket=2999.0)] ) resp = predict_handler(req) # 调用FastAPI路由函数 print(f"Prediction: {resp.predictions[0]:.4f}")

   ✅ 验证点：输出概率值与Notebook中lgb_model.predict()结果绝对误差<1e-6。

4.2 步骤4-6：容器化与基础服务部署（耗时≈1.5小时）

目标：构建可复现的Docker镜像，并在K8s集群部署最小可用服务。

4. Dockerfile优化：放弃FROM python:3.9-slim，改用FROM continuumio/miniconda3:4.12.0，利用Conda环境锁定二进制依赖：

   FROM continuumio/miniconda3:4.12.0 COPY environment.yml . RUN conda env create -f environment.yml && conda clean --all SHELL ["conda", "run", "-n", "ml-prod", "bash", "-c"] COPY . /app WORKDIR /app CMD ["uvicorn", "main:app", "--host", "0.0.0.0:8000", "--port", "8000"]

5. K8s Deployment配置：设置资源限制与健康检查：

   # deployment.yaml resources: limits: memory: "2Gi" cpu: "1000m" requests: memory: "1.5Gi" cpu: "500m" livenessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /readyz port: 8000 initialDelaySeconds: 5 periodSeconds: 5

6. 服务暴露：用Ingress Controller暴露HTTPS端点，并配置WAF规则拦截恶意UA。

4.3 步骤7-9：特征服务联调与契约验证（耗时≈3小时）

目标：确保生产特征服务返回数据与Pydantic Schema 100%匹配。

7. 契约测试脚本：用pytest编写Schema验证测试：

   # test_feature_contract.py def test_user_feature_schema(): # 调用真实特征服务 resp = requests.get("https://feature-api.prod/users/U123") assert resp.status_code == 200 data = resp.json() # 用Pydantic反序列化，失败则抛出异常 user_feat = UserFeature(**data) assert user_feat.age_group in ["young", "middle", "senior"]

8. 特征漂移检测：对last_purchase_days字段，计算其在测试数据集上的分布（直方图），与生产环境最近24小时数据分布做KS检验（Kolmogorov-Smirnov Test），p-value < 0.01则告警。

9. 超时熔断测试：用toxiproxy模拟特征服务200ms延迟，验证降级逻辑是否触发：

   # 启动ToxiProxy toxiproxy-cli create feature-api -l localhost:8001 -u feature-api.prod:443 toxiproxy-cli toxic add feature-api -t latency -a latency=200 -a jitter=50 # 调用API，检查是否返回默认特征 curl -X POST http://localhost:8000/predict -d '{"user":{"user_id":"U123"}}'

4.4 步骤10-12：全链路压测与灰度发布（耗时≈4小时）

目标：验证服务在真实流量下的稳定性，并完成渐进式上线。

10. 压测脚本：用locust模拟用户行为：

    # locustfile.py from locust import HttpUser, task, between class MLUser(HttpUser): wait_time = between(1, 3) @task(10) def predict(self): # 随机选取测试用户 user_id = random.choice(["U123", "U456", "U789"]) self.client.post("/predict", json={ "user": {"user_id": user_id}, "items": [{"item_id": "I001", "category": "books"}] })

    压测参数：100并发用户，持续10分钟，监控P95延迟、错误率、CPU使用率。

11. 灰度发布策略：在Istio中配置VirtualService，按Header灰度：

    # virtual-service.yaml http: - match: - headers: x-canary: exact: "true" route: - destination: host: ml-recommender subset: canary weight: 100 - route: - destination: host: ml-recommender subset: stable weight: 90

12. 效果验证：灰度期间，实时对比两组流量的业务指标：

    指标	稳定版（90%）	灰度版（10%）	允许偏差
    平均点击率	4.21%	4.25%	±0.1pp
    加购转化率	12.8%	12.9%	±0.2pp
    单用户GMV	¥89.3	¥88.7	±¥2.0
    达标后，执行istioctl apply -f virtual-service-stable.yaml全量切流。

5. 常见问题与排查技巧实录：来自7个项目的血泪教训

5.1 问题1：模型精度“上线即跌”，但离线评估一切正常

现象：A/B测试显示新模型CTR下降0.3%，而离线AUC提升0.015。

排查路径：

• 第一步：检查特征服务返回数据。用curl -H "X-Trace-ID: debug-123" https://feature-api.prod/users/U123获取带Trace ID的原始响应，发现last_purchase_days字段值全为null。
• 第二步：查特征服务日志，发现上游ETL任务因磁盘满失败，已停更2天。
• 第三步：确认特征服务降级策略——它返回了null而非默认值，而模型代码未处理null，导致np.nan传播。

根因：特征服务降级逻辑缺陷（应返回默认值，而非null）+ 模型代码缺少np.isnan()校验。

解决方案：

• 特征服务强制要求：所有字段必须有默认值，null视为Schema错误；
• 模型输入层增加assert not np.isnan(input_array).any()断言，失败则记录nan_propagation告警。

实操心得：永远不要相信特征服务返回的null是“合理缺失”。在金融风控场景，我们规定：所有数值型特征缺失时，必须返回业务含义明确的默认值（如credit_score=0表示“无信用记录”，而非null）。

5.2 问题2：K8s Pod频繁OOMKilled，但top显示内存使用仅1.2GB

现象：Pod内存限制2GB，但kubectl top pod显示使用1.2GB，却持续被OOMKilled。

排查路径：

• 第一步：kubectl describe pod <pod-name>查看Events，发现OOMKilled事件；
• 第二步：进入Pod执行cat /sys/fs/cgroup/memory/memory.usage_in_bytes，显示2.1GB；
• 第三步：cat /sys/fs/cgroup/memory/memory.stat | grep pgpg，发现pgpgin（页入）高达15GB，说明存在内存碎片。

根因：ONNX Runtime的内存分配器在Python多线程环境下产生大量小对象，GC无法及时回收，导致RSS（Resident Set Size）远超Python对象内存。

解决方案：

• 在Dockerfile中添加ENV OMP_WAIT_POLICY=PASSIVE，减少OpenMP线程争抢；
• 用psutil.Process().memory_info().rss替代sys.getsizeof()监控真实内存；
• 将内存限制提高到2.5GB，并设置--memory-reservation=2.0Gi。

5.3 问题3：Trace ID丢失，无法关联请求与模型日志

现象：Kibana中能看到HTTP请求日志，但找不到对应的model_inference日志。

排查路径：

• 第一步：检查FastAPI中间件，发现TraceIdMiddleware未正确注入trace_id到request.state；
• 第二步：检查opentelemetry.instrumentation.fastapi版本，发现v0.39b存在Context Propagation Bug；
• 第三步：验证trace.get_current_span()在路由函数内返回None。

根因：OpenTelemetry SDK版本不兼容，Context未在异步协程间正确传递。

解决方案：

• 升级opentelemetry-instrumentation-fastapi到v0.40+；
• 在路由函数开头强制tracer.start_span("request_context")；
• 用contextvars手动传递Trace ID：

  from contextvars import ContextVar trace_id_var = ContextVar("trace_id", default="") @app.middleware("http") async def trace_middleware(request: Request, call_next): trace_id = request.headers.get("X-Trace-ID", str(uuid.uuid4())) trace_id_var.set(trace_id) response = await call_next(request) return response # 在模型推理中 def predict(): trace_id = trace_id_var.get() logger.info(f"Predicting with trace_id={trace_id}")

5.4 问题4：CI/CD流水线卡在“构建Docker镜像”，耗时超30分钟

现象：流水线在docker build步骤停滞，du -sh /var/lib/docker显示磁盘使用98%。

排查路径：

• 第一步：docker system df -v查看镜像层大小，发现<none>悬空镜像占12GB；
• 第二步：docker builder prune清理，但下次构建又出现；
• 第三步：检查Dockerfile，发现COPY . /app将.git目录、__pycache__、大型测试数据集一并复制。

根因：Docker构建缓存污染 + 构建上下文过大。

解决方案：

• 创建.dockerignore文件：

  .git __pycache__ *.pyc tests/ data/ notebooks/

• 改用BuildKit加速：

  # syntax=docker/dockerfile:1 FROM --platform=linux/amd64 continuumio/miniconda3:4.12.0

5.5 问题5：AB测试流量分配不均，灰度组实际接收23%流量

现象：Istio VirtualService配置10%灰度，但监控显示灰度组QPS是稳定组的2.3倍。

排查路径：

• 第一步：istioctl proxy-config cluster <pod-name>检查服务发现，发现灰度组Endpoint数量是稳定组的2倍（因