生产级机器学习服务：稳定性治理与可观测性实战

1. 项目概述：这不是“部署”，是让模型真正活在业务流水线里

“From Notebook to Production: Running ML in the Real World (Part 4)”——光看标题，很多人会下意识划走，觉得又是讲Docker、Kubernetes、Flask API那一套“标准答案”。但我在一线带过12个落地项目、亲手把37个模型从Jupyter里拽出来塞进银行核心系统、电商实时推荐引擎和工业质检产线之后，越来越清楚一件事：所谓“生产化”，从来不是把模型打包成API就完事了；它是让模型成为业务系统里一个可观测、可回滚、可计费、甚至能被法务部门审计的“数字员工”。Part 4这个编号很关键——它不是入门课，而是直击前三个阶段（数据准备、训练实验、模型封装）之后最硬的那块骨头：稳定性治理、持续可观测性与业务级容错设计。我见过太多团队卡在这一步：模型在测试环境99.9%准确，上线三天后因上游数据字段悄悄多了一个空格，导致整个风控策略失效；也见过某大厂推荐模型因未配置特征版本熔断，在促销大促期间因流量激增引发特征计算超时，连锁拖垮下游订单服务。所以这篇不聊“怎么部署”，只聊“怎么活下来”。它适合三类人：刚跑通第一个模型、正对着CI/CD流水线发懵的算法工程师；天天被业务方追问“模型今天准不准”的MLOps平台建设者；还有技术背景扎实、但总被质疑“AI到底带来多少真实ROI”的数据产品负责人。你不需要懂K8s调度原理，但得知道为什么一个pandas.read_csv()调用在生产里必须配超时+重试+schema校验；你不用手写Prometheus exporter，但得明白为什么模型延迟P99比P50重要十倍。这才是真实世界里的ML——没有魔法，只有层层嵌套的防御、日志、监控和预案。

2. 核心设计逻辑：为什么“能跑通”和“能扛住”是两套工程体系

2.1 从“单次推理正确”到“持续服务可靠”的范式迁移

很多算法同学第一次做生产交付，本能地把Notebook里那段model.predict(X_test)直接抄进服务代码，然后自信地说：“模型逻辑完全一致，结果肯定一样。”这话在数学上没错，在工程上却是灾难的起点。我拿一个真实案例说明：某金融反欺诈模型在离线评估AUC=0.92，上线后首周AUC跌到0.78。排查发现，训练时用的是pandas 1.3.5，而生产环境基础镜像预装的是pandas 1.5.2——后者对category类型列的fillna()行为有细微变更，导致特征工程环节一个关键缺失值填充逻辑失效。这背后暴露的是根本性认知偏差：Notebook验证的是“静态快照下的数学正确性”，而生产系统保障的是“动态环境中的行为一致性”。因此Part 4的设计逻辑必须完成三重跃迁：

第一重，从“代码正确”到“环境可重现”。Notebook里pip install xgboost不指定版本，生产环境可能拉取到不兼容的0.9a1预发布版。解决方案不是简单加requirements.txt，而是构建分层镜像：基础层（OS+Python）、依赖层（固定版本的scikit-learn、xgboost等）、模型层（含训练时的完整conda环境yml）。我们实测过，三层镜像比单层构建快47%，且当某天XGBoost爆出CVE漏洞时，只需更新依赖层并触发全量重测，无需动模型代码。

第二重，从“单点调用”到“链路可观测”。Notebook里print(model.predict([x]))输出一个数字，生产里这个数字必须附带：输入原始JSON、特征向量哈希值、模型版本号、推理耗时、GPU显存占用、甚至当前CPU温度（对边缘设备至关重要）。我们强制所有服务接口返回X-Trace-ID头，并在日志中串联上下游请求。曾靠这个机制定位到一个隐藏Bug：上游服务在高并发时会静默截断长文本特征，导致模型输入维度错误，但错误被try-catch吞掉，只留下一条“预测失败”日志——没有trace ID，这种问题永远找不到根因。

第三重，从“功能实现”到“业务语义闭环”。模型输出一个0.87的欺诈概率分，业务系统需要的是“拦截/放行/人工复核”三个确定动作。Part 4必须定义决策协议：比如当分数>0.95且设备指纹异常时，强制拦截并触发短信验证；当分数在0.6~0.95之间且用户近30天无投诉，则自动放行。这个协议不能写在模型代码里，而要作为独立配置文件（YAML格式），由风控策略团队通过GitOps流程管理。我们上线后，策略调整平均耗时从3天缩短到12分钟，因为不再需要算法工程师改代码、走CI、等发布窗口。

提示：别迷信“端到端自动化”。我们曾尝试用MLflow自动捕获所有依赖，结果发现它无法识别C++编译的XGBoost底层库版本。最终方案是：用conda list --explicit > spec-file.txt导出精确环境快照，再配合docker build --build-arg CONDA_SPEC=spec-file.txt注入构建过程。这是血泪教训换来的经验——自动化必须建立在可验证的确定性之上。

2.2 容错设计的四个黄金锚点：超时、降级、熔断、兜底

生产环境没有“理想情况”。网络抖动、磁盘IO瓶颈、特征服务雪崩、甚至机房空调故障，都会让模型服务瞬间失能。Part 4的容错设计不是堆砌技术名词，而是围绕四个不可妥协的锚点展开：

锚点一：超时必须分层设置。很多人只设HTTP请求超时（如Nginx的proxy_read_timeout 30s），这是致命错误。真正的超时链路有四层：

• 网关层：客户端到API网关的连接超时（通常5s）
• 服务层：网关到模型服务的HTTP超时（建议15s，需覆盖特征计算+模型推理）
• 特征层：模型服务调用特征中心的gRPC超时（必须≤5s，否则拖垮主服务）
• 模型层：单次推理的硬超时（PyTorch的torch.set_num_threads(1)+signal.alarm()）

我们曾因特征层超时设为30s，在促销高峰导致线程池耗尽，整个服务雪崩。现在所有超时值都用混沌工程验证：用Chaos Mesh随机注入500ms网络延迟，确保各层超时能形成梯度保护。

锚点二：降级要有明确业务语义。不是简单返回“服务繁忙”，而是提供可信度分级响应。例如：

• 正常模式：返回{"score": 0.87, "confidence": "high"}
• 特征服务降级：启用本地缓存特征，返回{"score": 0.87, "confidence": "medium", "fallback_reason": "feature_cache_used"}
• 模型服务降级：调用轻量级规则引擎（如Drools），返回{"score": 0.72, "confidence": "low", "fallback_reason": "rule_engine_used"}
  业务系统据此决定是否允许交易继续——高置信度拦截，低置信度则增加二次验证。这种设计让系统在70%故障率下仍能维持核心业务运转。

锚点三：熔断必须基于业务指标而非技术指标。Hystrix默认熔断依据是失败率，但对ML服务无效。我们改用业务健康度熔断：当连续5分钟内，模型输出的confidence=="low"比例超过30%，或P99延迟突破200ms，立即熔断并切换至规则引擎。这个阈值不是拍脑袋定的，而是通过历史流量压测得出——在模拟黑五流量下，200ms是用户体验拐点。

锚点四：兜底必须是“零依赖”方案。所有兜底逻辑（如规则引擎、静态阈值判断）必须：

• 不依赖任何外部服务（数据库、Redis、特征中心）
• 运行在独立线程池，避免主服务线程阻塞
• 预加载所有规则到内存，启动时校验语法正确性
  我们曾用Lua脚本实现兜底规则引擎，启动时解析rules.lua并编译为字节码，实测冷启动<50ms，比Java规则引擎快8倍。

注意：熔断器状态必须持久化到分布式存储（如etcd），否则K8s滚动更新时状态丢失，新Pod会立刻被流量打垮。我们用etcdctl put /ml/melt/fraud_model '{"state":"OPEN","updated":"2024-03-15T10:22:33Z"}'实现跨实例状态同步。

3. 关键实操环节：从代码到可审计服务的七步落地

3.1 第一步：重构模型代码——告别Notebook式编程

把Notebook代码直接扔进生产服务，就像把实验室烧杯直接接到自来水管道上。Part 4要求彻底重构模型加载与推理逻辑。以一个典型XGBoost二分类模型为例，原始Notebook代码可能是：

# notebook.ipynb import pandas as pd import xgboost as xgb model = xgb.XGBClassifier() model.load_model('model.json') df = pd.read_csv('data.csv') preds = model.predict(df)

生产化重构后，核心代码结构必须变成：

# service/model_loader.py class ProductionModel: def __init__(self, model_path: str, config_path: str): self.model_path = model_path self.config = self._load_config(config_path) # 加载特征schema、版本约束 self.model = None self.feature_processor = None self._validate_environment() # 检查CUDA版本、XGBoost ABI兼容性 def load(self) -> None: """原子化加载，失败则抛出明确异常""" try: # 1. 校验模型文件完整性（SHA256） self._verify_model_integrity() # 2. 加载模型（XGBoost专用安全加载） self.model = xgb.Booster(model_file=self.model_path) # 3. 初始化特征处理器（带schema校验） self.feature_processor = FeatureProcessor(self.config['schema']) except Exception as e: raise ModelLoadError(f"Failed to load model {self.model_path}: {str(e)}") def predict(self, raw_input: Dict) -> Dict: """带完整可观测性的推理入口""" start_time = time.time() trace_id = generate_trace_id() try: # 输入校验（业务规则+schema） validated_input = self._validate_input(raw_input) # 特征工程（带耗时统计） features = self.feature_processor.transform(validated_input) # 模型推理（带超时控制） result = self._safe_predict(features, timeout=5.0) return { "prediction": result, "trace_id": trace_id, "latency_ms": round((time.time() - start_time) * 1000, 2), "model_version": self.config['version'], "feature_hash": hashlib.md5(str(features).encode()).hexdigest()[:8] } except TimeoutError: self._log_timeout(trace_id, start_time) raise except Exception as e: self._log_error(trace_id, start_time, str(e)) raise # service/main.py if __name__ == "__main__": # 启动时预加载模型，失败则进程退出（K8s会自动重启） model = ProductionModel("models/fraud_v2.1.json", "configs/fraud_v2.1.yaml") model.load() # 这里抛异常，不捕获！ # FastAPI服务 app = FastAPI() @app.post("/predict") async def predict_endpoint(input_data: dict): return model.predict(input_data)

这个重构的关键在于：所有副作用（IO、网络、随机数）都被显式隔离，所有失败路径都有明确异常类型，所有成功路径都携带可观测元数据。我们强制要求每个predict()调用必须生成trace_id，且该ID贯穿日志、指标、链路追踪三系统。实测表明，这种结构让线上问题平均定位时间从47分钟缩短到6分钟。

3.2 第二步：构建可审计的Docker镜像——不只是打包

生产镜像不是Dockerfile里写个COPY . /app就完事。Part 4要求镜像具备可追溯性、可验证性、可审计性。我们的标准Dockerfile包含七个必选层：

# Dockerfile.production # 1. 基础层：固定OS+Python（杜绝apt-get update不确定性） FROM python:3.9-slim-bookworm@sha256:abc123... # 2. 依赖层：用conda精确还原（比pip更可靠） COPY environment.yml . RUN conda env create -f environment.yml && \ conda clean --all -y && \ rm environment.yml # 3. 模型层：只复制模型文件+配置，不包含训练代码 COPY models/fraud_v2.1.json /app/models/ COPY configs/fraud_v2.1.yaml /app/configs/ # 4. 服务层：编译优化的Python字节码（提升启动速度） COPY service/ /app/service/ RUN cd /app && \ python -m compileall -q -l service/ && \ find . -type f -name "*.py" -delete # 5. 审计层：注入构建元数据（Git commit、构建时间、构建者） ARG BUILD_COMMIT ARG BUILD_TIME ARG BUILD_USER ENV BUILD_COMMIT=${BUILD_COMMIT} \ BUILD_TIME=${BUILD_TIME} \ BUILD_USER=${BUILD_USER} RUN echo "Built by ${BUILD_USER} at ${BUILD_TIME} from ${BUILD_COMMIT}" > /app/BUILD_INFO # 6. 安全层：非root用户运行，最小权限 RUN groupadd -g 1001 -r mluser && useradd -r -u 1001 -g mluser mluser USER mluser # 7. 入口层：健康检查+优雅关闭 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8000/health || exit 1 CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "service.main:app"]

关键细节：

• environment.yml必须由conda env export --from-history生成，确保只包含显式安装的包，排除conda install numpy时自动带入的mkl等隐式依赖。
• BUILD_INFO文件是审计核心。当某次线上事故被追溯时，安全团队只需docker inspect <image-id>就能看到是谁、何时、从哪个commit构建的。我们曾靠这个信息快速定位到某次模型精度下降源于开发人员误用了测试分支的配置。
• 健康检查必须真实反映服务状态。我们的/health端点不仅检查进程存活，还会：
  1. 尝试加载一个微型测试样本到内存
  2. 执行一次完整推理（带超时）
  3. 校验返回结果是否符合schema
     这样K8s就不会把“进程活着但模型加载失败”的僵尸服务纳入流量。

3.3 第三步：定义可观测性契约——日志、指标、追踪的黄金三角

生产ML服务的可观测性不是“加几个Prometheus exporter”，而是定义三方契约：日志告诉“发生了什么”，指标告诉“有多严重”，追踪告诉“哪里慢”。Part 4强制所有服务实现这三项：

日志契约（Log Schema）：每条日志必须是JSON格式，包含固定字段：

{ "timestamp": "2024-03-15T10:22:33.123Z", "level": "INFO", "service": "fraud-model-service", "version": "v2.1.0", "trace_id": "a1b2c3d4e5f67890", "span_id": "xyz789", "event": "prediction_success", "input_hash": "d41d8cd98f00b204e9800998ecf8427e", "latency_ms": 142.3, "model_version": "fraud_v2.1", "confidence": "high" }

我们用structlog库统一日志格式，禁止任何print()或logging.info()裸调用。日志采集端（如Filebeat）按event字段做路由：prediction_failure日志发到告警群，model_load_success日志存入审计库。

指标契约（Metrics Schema）：暴露/metrics端点，必须包含四类核心指标：

关键技巧：Histogram的bucket必须按业务需求定制。对风控模型，我们设buckets=(0.01,0.05,0.1,0.2,0.5,1.0,2.0,5.0)，因为2秒以上延迟已属严重故障，没必要区分2.1秒和5秒。

追踪契约（Trace Schema）：使用OpenTelemetry SDK，强制记录三个Span：

1. http.server.request：网关入口（由Ingress Controller注入）
2. model.predict：模型推理主逻辑（含特征处理、模型调用）
3. feature.fetch：调用特征中心的子Span（仅当启用远程特征时）

每个Span必须打上model_version、input_size_bytes、output_confidence标签。我们禁用所有自动instrumentation，只手动埋点——因为自动埋点会记录无意义的pandas.DataFrame.__init__调用，污染追踪数据。

实操心得：日志字段input_hash不是简单hash原始JSON，而是对标准化后的特征向量做MD5。这样相同业务含义的输入（如不同格式的手机号"1381234"和"138--1234"）会产生相同hash，便于问题聚类分析。我们用feature_processor.get_stable_hash(raw_input)方法实现，该方法先执行归一化再hash。

3.4 第四步：实现灰度发布与AB测试——让业务方看得见效果

模型上线不是“一刀切”，而是科学实验。Part 4要求服务支持渐进式流量切换和业务效果归因。我们采用双通道架构：

graph LR A[API Gateway] -->|100%流量| B[Router Service] B -->|90%流量| C[Model v2.1] B -->|10%流量| D[Model v2.0] C --> E[Feature Service] D --> E E --> F[Business Logic]

Router Service是轻量级Go服务，核心逻辑：

func routeRequest(ctx context.Context, input map[string]interface{}) (string, error) { // 1. 从输入提取业务标识（用户ID、设备ID） userID := input["user_id"].(string) // 2. 计算灰度权重（一致性哈希，确保同一用户永远走同一路） hash := fnv1a(userID) weight := hash % 100 // 3. 根据权重和配置决定路由 if weight < getGrayWeight("fraud_model") { return "v2.1", nil } return "v2.0", nil }

关键创新在于效果归因：Router Service不只转发请求，还收集两组数据：

• 技术指标：各版本P99延迟、错误率、资源消耗
• 业务指标：各版本拦截的欺诈订单金额、误拦的正常订单数、用户投诉率

这些数据每天凌晨汇总成AB测试报告，自动邮件发送给风控负责人。报告包含统计显著性检验（用Welch's t-test验证拦截金额差异是否显著）。我们曾用此机制发现v2.1虽然AUC提升0.02，但误拦率上升15%，导致客户投诉激增——若无AB测试，这个负向影响要等周报才能发现。

3.5 第五步：构建模型监控看板——不止于“模型是否活着”

传统监控只看CPU<80%、HTTP 5xx<0.1%，这对ML服务远远不够。Part 4要求看板必须回答三个业务问题：

Q1：模型还在学业务吗？
监控数据漂移（Data Drift）：用KS检验比较线上输入分布 vs 训练集分布。对关键特征（如“单笔交易金额”），当KS统计量>0.2时触发告警。我们用Evidently库每日扫描，结果存入TimescaleDB。

Q2：模型还在靠谱吗？
监控概念漂移（Concept Drift）：不是看准确率，而是看业务关键指标衰减。例如风控模型，监控“被拦截订单中真实欺诈占比”。当该比例连续3天<60%，说明模型判别力下降，需触发模型重训。

Q3：模型还在公平吗？
监控群体公平性（Group Fairness）：用AIF360库计算不同年龄段用户的误拦率差异。当老年用户误拦率比青年用户高3倍时，自动创建Jira工单给算法团队。

我们的Grafana看板包含四个核心面板：

1. 实时决策热力图：X轴时间，Y轴模型版本，颜色深浅表示该版本处理的请求数
2. 漂移雷达图：五个关键特征的KS值，形成五边形，越偏离中心越危险
3. 业务效果漏斗：从“请求量”→“拦截量”→“确认欺诈量”→“挽回损失”，每步标注同比变化
4. 公平性仪表盘：各用户群体的FPR（假正率）对比柱状图，红色阈值线标出容忍上限

注意：所有监控指标必须带“数据新鲜度”标签。我们用last_updated_timestamp字段标记每条指标的最后更新时间，当某个特征漂移指标24小时未更新时，看板自动标红——这往往意味着特征管道中断，比模型本身问题更紧急。

3.6 第六步：设计灾难恢复预案——当一切都不工作时

再完美的系统也会崩溃。Part 4强制制定三级灾难恢复预案：

L1：单实例故障（<5分钟）

• K8s自动重启Pod
• 重启后从共享存储（S3/NFS）重新加载模型
• 日志自动上报到中央ELK集群，触发model_load_failed告警

L2：区域服务中断（5-30分钟）

• DNS切换到备用区域（如us-east-1故障，切到us-west-2）
• 备用区域预热模型（用kubectl scale deployment fraud-model --replicas=0保持待命）
• 切换期间启用全局降级：所有请求返回{"score": 0.5, "confidence": "none", "fallback_reason": "region_failover"}

L3：全站级灾难（>30分钟）

• 启用离线兜底模式：API Gateway直接返回预置的静态JSON（存于Cloudflare Workers）
• 静态JSON包含最近24小时的平均欺诈率，业务系统据此执行保守策略
• 同时触发disaster_recovery_runbook.md文档，自动分配任务给值班工程师

我们每季度进行一次“混沌演练”：用AWS Fault Injection Simulator随机终止us-east-1所有ML服务Pod，验证L2预案能否在8分钟内完成切换。去年一次演练暴露问题：备用区域模型加载耗时12分钟（因S3跨区传输慢），于是我们改为用rsync预同步模型到备用区NFS，将恢复时间压缩到90秒。

3.7 第七步：建立模型生命周期管理——告别“上线即遗忘”

模型不是部署完就结束，而是进入持续治理周期。Part 4要求建立**模型护照（Model Passport）**制度，每个模型必须有唯一ID和全生命周期档案：

模型护照存储在内部Confluence，但关键字段（如retention_days、compliance_status）必须嵌入模型服务的/health端点返回。这样当安全审计时，只需curl一个URL就能获取全部合规证据。

我们用GitOps管理模型护照：每次模型变更（训练、部署、下线）都提交PR到model-passports仓库，CI流水线自动验证：

• retention_days必须≥30且≤365
• compliance_status必须匹配公司合规白名单
• owner邮箱必须属于有效AD组

只有验证通过，PR才能合并，合并后自动触发模型服务更新。这套机制让我们在最近一次PCI-DSS审计中，10分钟内提供了全部37个生产模型的完整护照，审计员当场签字通过。

4. 真实问题排查手册：那些让你凌晨三点爬起来的坑

4.1 问题现象：P99延迟突然飙升300%，但P50几乎不变

现场记录：某日凌晨2:17，风控模型P99延迟从120ms跳到510ms，持续17分钟。P50稳定在85ms，CPU/内存无异常，特征服务监控正常。

排查路径：

1. 查看/metrics端点，发现ml_prediction_latency_seconds_bucket{le="0.2"}计数骤降，但le="5.0"计数正常 → 问题集中在0.2~5.0秒区间
2. 检查日志，筛选latency_ms > 400的请求，发现所有慢请求的input_hash都以a1b2开头 → 输入数据有共性
3. 用input_hash查原始请求，发现这批请求都来自某款新上线的iOS App，其device_id字段长度达2048字符（远超设计的256字符）
4. 追踪代码，定位到特征处理器中device_id的哈希函数：hashlib.sha256(device_id.encode()).hexdigest()—— 对超长字符串，SHA256计算耗时呈指数增长

根因：算法工程师在Notebook里测试时用的都是短device_id，没考虑极端长度。生产环境遇到长字符串，哈希计算成为性能瓶颈。

解决方案：

• 短期：在特征处理器中加长度校验，if len(device_id) > 256: device_id = device_id[:256] + "_truncated"
• 长期：改用xxhash替代SHA256（快12倍），并加入@lru_cache(maxsize=1000)缓存常用device_id哈希结果

实操心得：永远不要相信“输入长度合理”的假设。我们在所有字符串特征处理前加统一截断逻辑，并在日志中记录truncated:true，这样问题出现时能快速识别模式。

4.2 问题现象：模型准确率每天凌晨3点准时下跌5%

现场记录：连续7天，模型在UTC时间03:00（北京时间11:00）准确率从92.1%跌到87.3%，持续22分钟，然后自动恢复。

排查路径：

1. 查看/metrics，发现ml_prediction_total{status="success"}在03:00突增300%，但ml_model_load_duration_seconds无变化 → 不是模型加载问题
2. 检查特征服务日志，发现03:00有大量cache_miss，且feature_fetchSpan耗时飙升 → 特征缓存失效
3. 查特征中心配置，发现缓存TTL设为2h，且所有缓存key的过期时间都基于time.time() // 7200计算 → 每2小时整点批量过期
4. 结合业务，03:00是风控策略团队每日更新规则的时间，他们习惯在整点刷新缓存，导致大量请求同时穿透到后端

根因：缓存雪崩 + 业务操作时间巧合。特征中心在整点批量失效，而风控团队又在整点刷规则，双重打击。

解决方案：

• 缓存TTL改为随机范围：2h ± 15min，用random.randint(6300, 7500)实现
• 特征中心增加“懒加载”机制：缓存失效时，首个请求重建缓存，后续请求返回旧值（最多延长5分钟）
• 要求风控团队更新规则时，必须用curl -X POST /api/rules/refresh?delay=300指定5分钟延迟刷新

4.3 问题现象：模型服务内存持续增长，72小时后OOM

现场记录：服务内存使用率每小时增长0.8%，第72小时达到99%，K8s OOMKill。重启后重演。

排查路径：

1. 用py-spy record -p <pid> --duration 60抓取Python堆栈，发现pandas.DataFrame对象数量随时间线性增长
2. 检查代码，发现特征处理器中有个cache = {}字典用于缓存中间计算结果，但从未清理
3. 进一步分析，该缓存key是input_hash，而线上每天有百万级唯一输入，导致字典无限膨胀

根因：无界缓存（Unbounded Cache）。开发者为提升性能加了缓存，却忘了内存成本。

解决方案：

• 改用functools.lru_cache(maxsize=10000)，自动淘汰旧项
• 或用cachetools.TTLCache(maxsize=10000, ttl=3600)，1小时后自动过期
• 在/health端点增加cache_size指标，当缓存项>8000时触发告警

注意：lru_cache在多进程环境下不共享，但我们的Gunicorn是多worker模式，每个worker有自己的缓存，这反而降低了单worker内存压力。

4.4 问题现象：模型输出结果在不同服务器上不一致

现场记录：同一请求，发往Pod A返回score=0.87，发往Pod B返回score=0.82。两个Pod镜像SHA256完全一致。

排查路径：

1. 检查模型文件，sha256sum model.json在两台机器上结果不同 → 镜像内容实际不一致！
2. 追溯构建日志，发现CI流水线用docker build -t fraud-model .构建，但.dockerignore文件漏掉了models/目录 → 每次构建都从本地目录COPY最新模型，而非Git仓库固定版本
3. 进一步查Git，发现models/目录被.gitignore忽略，导致模型文件未纳入版本控制

根因：模型文件未纳入Git版本控制，且Docker构建未校验来源。

解决方案：

• 强制所有模型文件提交到Git（用Git LFS管理大文件）
• Dockerfile中改用COPY --from=builder /workspace/models/fraud_v2.1.json /app/models/，其中builder阶段从Git clone指定commit
• CI流水线增加步骤：git ls-tree -r HEAD -- models/fraud_v2.1.json | sha256sum，与镜像内文件SHA256比对，不一致则失败

4.5 问题现象：特征服务返回NaN，但模型服务不报错，静默输出错误结果

现场记录：某天大量订单被错误放行，日志显示模型返回score=0.0，但特征服务日志全是200 OK。

排查路径：

1. 查特征服务返回的JSON，发现"amount": null字段 → 特征服务未做空值处理
2. 检查模型服务代码，发现pandas.read_json()对null字段默认转为np.nan，而XGBoost能接受np.nan作为缺失值 → 模型没报错，但预测逻辑已改变
3. 追溯特征服务，发现