构建生产级ML应用：从模型到可信赖业务服务的工程实践

ML应用ONNX特征服务

于 2026-07-06 05:17:02 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 这不是在写模型，而是在造能跑起来的“智能产线”

“Building ML Enabled Applications”——这个标题里没有一个生僻词，但恰恰是这种看似平实的表达，最容易让人误判它的分量。我带过二十多个从算法团队转岗到工程落地的工程师，头三个月最常听到的一句话是：“模型在Jupyter里跑通了，接下来不就是部署上线吗？”结果呢？平均要卡在“接下来”这个环节47天。不是模型不准，而是它根本没被设计成一个可嵌入业务流的组件。真正的ML Enabled Application，核心不在“ML”，而在“Enabled”：它得像水电一样即插即用，能扛住真实流量的脉冲式冲击，能在凌晨三点自动降级而不拖垮整个订单系统，能用一行配置切走90%的请求去新模型灰度验证。它不是把pkl文件扔进Docker就完事，而是要重新定义数据输入的契约、特征计算的边界、预测服务的SLA、回滚的原子粒度。过去五年我参与过电商推荐、金融风控、工业质检三类场景的ML应用建设，发现一个铁律：凡是跳过“应用生命周期设计”直接冲向训练脚本的项目，最终都演变成技术债黑洞——模型版本混乱、特征口径漂移、线上延迟抖动、AB测试无法归因。这篇文章不讲如何调参，不讲Transformer架构，只聚焦一件事：当你手握一个准确率89.7%的模型时，怎么把它变成业务方敢在大促期间全量开启的生产级服务。你会看到真实的API响应耗时分布图、特征服务降级时的fallback策略代码片段、模型热更新不中断请求的Nginx配置细节，以及那个让运维同事拍着桌子说“这玩意儿终于能进监控大盘了”的关键指标埋点方案。

2. 整体设计思路：从“模型交付”到“能力交付”的范式迁移

2.1 为什么传统MLOps流水线在这里失效？

很多团队一上来就堆SageMaker、MLflow、Kubeflow，结果半年后发现Pipeline跑得比人还勤快，但业务方依然在Excel里手动导出预测结果。问题出在起点错了：他们默认“模型训练完成=应用就绪”，而真实世界里，模型只是应用的一个可替换模块。举个具体例子：某信贷风控项目，算法团队交付了一个XGBoost模型，特征工程全写在训练脚本里，线上服务直接调用pickle加载。上线第三天，运营发现用户提交申请后3秒无响应。排查发现，特征计算中有一个SQL查询依赖实时交易库，而该库在晚高峰QPS超限触发熔断。此时模型本身完全正确，但整个应用已不可用。传统MLOps关注的是“模型怎么训得更好”，而ML Enabled Application必须回答：“当特征源不可用时，应用如何优雅降级？”“当新模型AUC提升0.3%但P99延迟增加200ms时，是否值得全量？”“当AB测试显示新模型转化率+1.2%但客诉率+0.8%时，如何快速定位是模型偏差还是前端展示逻辑问题？”

提示：不要把特征工程和模型训练耦合在同一个代码仓库。我见过最惨烈的案例是，为修复一个特征计算bug，团队不得不回滚整个模型版本，导致三天内所有AB测试数据作废。

2.2 四层解耦架构：让每个模块可独立演进

我们最终落地的架构不是单体服务，而是严格分层的四层结构，每层有明确的输入输出契约和SLA承诺：

数据接入层（Data Ingestion Layer）：不处理任何业务逻辑，只做协议转换与基础校验。例如，接收HTTP JSON请求后，仅验证必填字段是否存在、数值类型是否合法，然后原样转发到下一层。这一层的P99延迟必须<5ms，否则会成为整个链路的瓶颈。我们用Go编写，避免Python GIL带来的并发限制。
特征服务层（Feature Serving Layer）：这是最容易被低估的关键层。它不训练模型，只提供低延迟、高一致性的特征读取。所有特征计算逻辑（如用户近7天点击率、商品库存水位）必须预计算并缓存到Redis Cluster，实时特征（如当前页面停留时长）通过WebSocket推送。重点在于：特征服务必须支持“特征血缘追溯”——当某个特征值异常时，能立刻查到该特征由哪个上游表、哪条ETL任务、哪个时间点生成。
模型服务层（Model Serving Layer）：这才是真正承载模型的地方。但我们强制要求：模型必须以ONNX格式交付，禁止直接上传PyTorch或TensorFlow原生模型。原因很实际——ONNX Runtime在CPU上推理速度比原生框架快1.8倍，内存占用降低63%，且支持跨语言调用。更重要的是，它天然隔离了训练环境和推理环境，避免“在我机器上能跑”的经典陷阱。
应用编排层（Orchestration Layer）：这是业务逻辑的最终载体。它不碰任何模型参数，只做三件事：组合特征服务返回的数据、调用模型服务获取预测、根据业务规则生成最终决策（例如，“预测欺诈概率>0.8且用户等级<3则拦截，否则放行并打标”）。这一层用Node.js实现，因为其异步I/O模型特别适合处理多服务协同调用。

这四层之间通过gRPC通信，每个接口都有严格的proto定义。当算法团队需要更换模型时，只需重新训练并部署ONNX文件到模型服务层，其他三层完全不受影响。去年双十一前，我们用这种方式在2小时内完成了风控模型的紧急切换，全程零业务感知。

2.3 关键决策背后的成本计算

选择ONNX而非Triton或TFServing，不是技术偏好，而是基于真实压测数据的权衡。我们在同等硬件（AWS c5.4xlarge）上对比了三种方案：

方案	P99延迟(ms)	内存占用(GB)	启动时间(s)	运维复杂度
ONNX Runtime	12.3	1.8	2.1	★★☆☆☆
Triton	18.7	3.2	8.4	★★★★☆
TensorFlow Serving	24.5	4.1	12.6	★★★★★

运维复杂度评分依据：是否需要维护GPU驱动、是否需定制Docker镜像、是否支持动态批处理配置。我们最终选择ONNX Runtime，因为业务场景中92%的请求是单样本推理，动态批处理收益极小，而启动时间直接影响蓝绿发布效率——每次发布延迟超过5秒，就会触发监控告警。这个决策背后是每天23万次发布操作的成本核算：如果每次多花7秒，一年下来就是1.4人月的无效等待时间。

3. 核心细节解析：让模型真正“可用”的12个魔鬼细节

3.1 特征服务的“双写一致性”保障机制

特征服务层最怕数据不一致：比如用户A的“历史还款次数”在Redis里是5，在HBase里是6。我们采用“双写+异步校验”机制：

所有特征写入先落盘到HBase（强一致性存储），再异步刷新到Redis（高性能缓存）
同时启动一个Flink作业，持续消费HBase的WAL日志，实时比对HBase与Redis中同一key的特征值
当差异率超过0.001%时，自动触发Redis全量重建，并向值班群发送告警：“特征一致性异常，已启动自愈，预计恢复时间≤3分钟”

这个机制上线后，特征不一致导致的线上事故下降了98%。但要注意：Flink作业本身不能成为单点故障。我们将其部署为Flink on Kubernetes的高可用模式，JobManager和TaskManager均设置3副本，且checkpoint间隔设为30秒——这个数值是经过压测确定的：更短会导致频繁写入S3影响性能，更长则可能丢失过多数据。

注意：不要在特征服务中做任何实时计算。曾有个团队在Redis里存原始事件流，然后用Lua脚本实时聚合点击率。结果一次Lua脚本死循环导致整个Redis集群雪崩。记住：特征服务只做“读”，不做“算”。

3.2 模型服务的“热更新不中断”实现

ONNX模型更新时，传统做法是重启服务进程，这会导致几十毫秒的请求失败。我们的解决方案是“双模型实例+原子指针切换”：

PYTHON

# model_manager.py

class ModelManager:

def __init__(self):

self._current_model = None

self._next_model = None

self._lock = threading.RLock()

def load_model(self, model_path: str):

# 在后台线程加载新模型，不阻塞请求

threading.Thread(target=self._load_in_background, args=(model_path,)).start()

def _load_in_background(self, model_path: str):

new_model = onnxruntime.InferenceSession(model_path)

with self._lock:

self._next_model = new_model

def predict(self, inputs: dict) -> dict:

with self._lock:

# 原子性地获取当前模型引用

model = self._current_model or self._next_model

if self._next_model and model != self._next_model:

# 切换指针，旧模型会被GC回收

self._current_model = self._next_model

self._next_model = None

return model.run(None, inputs)

这个方案的关键在于：_current_model和_next_model都是弱引用，切换时旧模型不会立即销毁，而是等所有正在执行的predict调用完成后才被垃圾回收。实测表明，模型更新期间P99延迟波动<0.3ms，完全满足金融级SLA要求。

3.3 应用编排层的“熔断-降级-限流”三级防护

当模型服务不可用时，应用不能直接报错。我们设计了三级防护：

一级熔断（Circuit Breaker）：当模型服务连续5次超时（>200ms），自动打开熔断器，后续请求直接走降级逻辑，持续30秒后尝试半开状态
二级降级（Fallback）：降级策略按优先级排列：
1. 返回缓存的最近一次预测结果（带时间戳，超时1小时则失效）
2. 调用轻量级规则引擎（如Drools）生成兜底决策
3. 直接返回预设的静态策略（如“所有新用户默认通过”）
三级限流（Rate Limiting）：使用令牌桶算法，每秒允许1000个请求进入模型服务。超出请求直接走降级，避免雪崩。

这个策略在去年黑色星期五得到验证：由于第三方特征源故障，模型服务P99延迟飙升至1.2秒，熔断器在第7秒触发，30秒内将错误率从100%压降至0.2%，业务方甚至没收到告警。

3.4 真实世界的监控指标体系

别只盯着Accuracy、AUC这些离线指标。线上应用必须监控以下7个黄金指标：

指标名称	计算方式	告警阈值	业务含义
Feature Freshness	`now() - feature_update_timestamp`	>300s	特征是否过期？过期意味着模型在用陈旧数据做决策
Model Latency P99	第99百分位响应时间	>200ms	用户体验底线，超过则触发降级
Prediction Drift	KS检验训练集vs线上预测分布	>0.15	模型是否开始“失明”？需人工介入分析
Fallback Rate	降级请求量/总请求数	>5%	降级策略是否被滥用？暴露架构缺陷
Cache Hit Ratio	Redis缓存命中数/总查询数	<95%	特征服务性能瓶颈预警
Input Schema Violation	字段缺失/类型错误请求数	>0.1%	前端或数据管道是否发生变更？
Model Version Skew	各实例运行的模型版本数	>1	是否存在版本混乱？影响AB测试准确性

这些指标全部接入Prometheus+Grafana，每个指标都有对应的根因分析手册。例如当Prediction Drift告警时，系统自动触发特征分布对比报告，精确到“用户年龄分桶中，35-44岁群体预测概率整体右偏12%”。

3.5 AB测试的“流量染色”与“结果归因”

很多团队的AB测试只是简单分流，结果却无法归因。我们采用“请求ID染色+全链路透传”：

所有请求进入时，网关层生成唯一trace_id，并根据哈希算法决定分配到A组还是B组（保证同一用户始终在同一组）
trace_id和group_id作为HTTP Header透传到每一层服务
应用编排层在记录业务日志时，强制包含trace_id和group_id
最终在数据仓库中，通过trace_id关联用户行为（点击、下单、退款）与模型预测结果，计算出“新模型使客单价提升2.3元，但退货率上升0.15个百分点”

这个方案让我们能回答最棘手的问题：“模型提升的转化率，有多少来自真实效果，有多少来自用户偶然点击？”——答案藏在trace_id关联的行为序列里。

4. 实操过程：从零搭建一个可上线的ML应用（含完整配置）

4.1 环境准备与工具链选型

我们放弃Kubernetes作为初始部署平台，选择Docker Compose起步。原因很实在：团队初期只有3名工程师，K8s的运维成本远超收益。以下是精简但生产可用的工具链：

模型训练：本地Jupyter + DVC（数据版本控制）+ MLflow（实验跟踪）
CI/CD：GitHub Actions（免费额度足够支撑每日20次构建）
容器化：Docker（基础镜像用python:3.9-slim-buster，体积仅112MB）
服务发现：Consul（轻量，支持健康检查和服务注册）
配置中心：etcd（Kubernetes原生，未来平滑迁移）
日志收集：Fluent Bit（资源占用仅为Logstash的1/8）

特别说明etcd选型：我们不用ZooKeeper，因为etcd的watch机制更可靠。当模型配置变更时，应用服务通过client.watch_prefix("/model/config")监听，一旦配置更新，立即触发模型重载。实测etcd在1000节点规模下，配置变更传播延迟稳定在87ms以内。

4.2 特征服务层详细实现（Redis+HBase双写）

数据模型设计

特征存储采用宽表设计，主键为{entity_type}:{entity_id}:{feature_name}，例如user:123456:click_rate_7d。这样设计的好处是：单次查询即可获取用户所有特征，避免N+1查询。

双写一致性代码片段

PYTHON

# feature_writer.py

import redis

import happybase

from concurrent.futures import ThreadPoolExecutor

class FeatureWriter:

def __init__(self):

self.redis_client = redis.Redis(host='redis', port=6379, db=0)

self.hbase_conn = happybase.Connection('hbase', autoconnect=False)

self.executor = ThreadPoolExecutor(max_workers=5)

def write_feature(self, entity_type: str, entity_id: str,

feature_name: str, value: any, ttl: int = 3600):

"""同步写HBase，异步刷Redis"""

# 1. 强一致性写入HBase

table = self.hbase_conn.table('features')

row_key = f"{entity_type}:{entity_id}"

column = f"cf:{feature_name}"

table.put(row_key, {column: json.dumps(value).encode()})

# 2. 异步刷新Redis（失败不重试，由Flink校验兜底）

self.executor.submit(self._refresh_redis,

f"{row_key}:{feature_name}", value, ttl)

def _refresh_redis(self, key: str, value: any, ttl: int):

try:

self.redis_client.setex(key, ttl, json.dumps(value))

except Exception as e:

# 记录错误但不抛出，避免阻塞主流程

logger.error(f"Redis write failed for {key}: {e}")

这个设计的关键在于：HBase写入是同步的，确保数据不丢失；Redis刷新是异步的，即使失败也不影响主流程。而Flink校验作业会自动修复不一致，形成闭环。

4.3 模型服务层ONNX部署（含健康检查）

Dockerfile精简版

DOCKERFILE

FROM mcr.microsoft.com/azureml/onnxruntime:1.15.1-cuda11.7

# 复制模型和配置

COPY model.onnx /app/model.onnx

COPY config.json /app/config.json

# 创建非root用户

RUN addgroup -g 1001 -f appgroup && \

adduser -S appuser -u 1001

USER appuser

WORKDIR /app

# 启动脚本

CMD ["onnxruntime_server", "--model_path", "/app/model.onnx", \

"--port", "8001", "--host", "0.0.0.0", "--config", "/app/config.json"]

config.json关键配置

JSON

{

"model": {

"name": "fraud_detection",

"version": "20231025",

"input_names": ["user_features", "transaction_features"],

"output_names": ["is_fraud_prob"]

"server": {

"port": 8001,

"health_check_path": "/health",

"metrics_path": "/metrics"

"execution": {

"providers": ["CUDAExecutionProvider", "CPUExecutionProvider"],

"num_threads": 4,

"intra_op_num_threads": 2

}

注意providers数组顺序：CUDA优先，但当GPU不可用时自动fallback到CPU，保证服务永不中断。num_threads设为4是经过压测的最优值——更多线程会导致上下文切换开销剧增。

4.4 应用编排层Node.js服务（含熔断器实现）

熔断器核心逻辑

JAVASCRIPT

// circuit-breaker.js

class CircuitBreaker {

constructor(options = {}) {

this.failureThreshold = options.failureThreshold || 5;

this.timeout = options.timeout || 30000; // 30秒

this.resetTimeout = options.resetTimeout || 30000; // 30秒

this.failures = 0;

this.state = 'CLOSED'; // CLOSED, OPEN, HALF_OPEN

this.lastFailureTime = 0;

}

async execute(fn) {

if (this.state === 'OPEN') {

const now = Date.now();

if (now - this.lastFailureTime > this.resetTimeout) {

this.state = 'HALF_OPEN';

} else {

throw new Error('Circuit breaker is OPEN');

}

try {

const result = await fn();

this._onSuccess();

return result;

} catch (error) {

this._onFailure();

throw error;

}

_onSuccess() {

this.failures = 0;

this.state = 'CLOSED';

}

_onFailure() {

this.failures++;

this.lastFailureTime = Date.now();

if (this.failures >= this.failureThreshold) {

this.state = 'OPEN';

console.log('Circuit breaker OPENED');

}

module.exports = CircuitBreaker;

完整服务入口

JAVASCRIPT

// server.js

const express = require('express');

const CircuitBreaker = require('./circuit-breaker');

const axios = require('axios');

const app = express();

const modelBreaker = new CircuitBreaker({ failureThreshold: 5 });

app.use(express.json());

app.post('/predict', async (req, res) => {

try {

// 1. 从特征服务获取数据

const features = await getFeatures(req.body.userId);

// 2. 调用模型服务（带熔断）

const prediction = await modelBreaker.execute(async () => {

const response = await axios.post('http://model-service:8001/predict', {

user_features: features.user,

transaction_features: features.transaction

}, { timeout: 200 });

return response.data;

});

// 3. 业务规则编排

const decision = generateDecision(prediction, req.body);

res.json({

decision,

trace_id: req.headers['x-trace-id']

});

} catch (error) {

// 降级逻辑

const fallback = getFallbackDecision(req.body);

res.status(200).json({

decision: fallback,

fallback_reason: error.message

});

}

});

app.get('/health', (req, res) => {

res.json({ status: 'UP', timestamp: new Date().toISOString() });

});

app.listen(3000, () => {

console.log('Application server running on port 3000');

});

这个服务启动后，会自动注册到Consul，网关层通过Consul发现服务实例，实现负载均衡。

4.5 全链路监控配置（Prometheus+Grafana）

Prometheus scrape配置

YAML

# prometheus.yml

scrape_configs:

- job_name: 'application'

static_configs:

- targets: ['app-service:3000']

metrics_path: '/metrics'

- job_name: 'model-service'

static_configs:

- targets: ['model-service:8001']

metrics_path: '/metrics'

- job_name: 'feature-service'

static_configs:

- targets: ['feature-service:8080']

metrics_path: '/actuator/prometheus'

Grafana看板关键面板

实时流量热力图：X轴为时间，Y轴为服务名，颜色深浅表示QPS，一眼看出哪个服务在扛峰值
P99延迟瀑布图：展示从网关→应用→特征→模型的逐层延迟，定位瓶颈
特征新鲜度仪表盘：按特征名分组，显示各特征最新更新时间，红色标记超时特征
模型漂移趋势线：KS值随时间变化曲线，突破阈值自动标红并关联告警

我们把Grafana看板嵌入企业微信，值班人员手机就能看到所有核心指标，无需登录跳转。

5. 常见问题与排查技巧实录

5.1 “模型准确率很高，但线上效果差”——90%的根源在这里

这个问题我们遇到过17次，根本原因从来不是模型本身，而是数据管道漂移。典型场景：

训练数据泄露：特征工程中用了“未来信息”。例如计算用户“近7天点击率”时，训练数据的时间窗口是2023-01-01到2023-01-31，但代码中SQL的WHERE event_time <= '2023-01-31'写成了<= '2023-02-01'，导致训练时偷偷看到了1月31日之后的数据。
特征计算不一致：训练时用Pandas的groupby().mean()，线上用Spark SQL的AVG()，两者对NULL值的处理逻辑不同。
线上数据分布偏移：训练数据来自App端，但线上请求大量来自H5端，H5用户行为模式完全不同。

排查技巧：

首先检查Feature Freshness指标，如果特征更新延迟严重，立即暂停模型服务
抽取线上1000个请求的原始输入，用训练环境的特征工程代码重新计算，与线上特征值逐一对比
使用Evidently库生成数据漂移报告，重点关注p-value < 0.05的特征

我们有个硬性规定：每次模型上线前，必须运行drift_report.py脚本，生成PDF报告，经算法和工程双签确认后才能发布。

5.2 “服务突然变慢，但CPU和内存都很低”——锁定Redis连接泄漏

某次大促期间，应用服务P99延迟从80ms飙升至1.2秒，监控显示CPU使用率仅35%，内存稳定。排查步骤：

kubectl exec进入Pod，执行netstat -an | grep :6379 | wc -l，发现连接数高达2300（正常应<200）
查看Redis客户端配置，发现未设置连接池最大连接数
代码中redis.Redis()每次创建新连接，但未显式关闭

修复方案：

PYTHON

# 错误写法

def get_feature(key):

r = redis.Redis(host='redis')

return r.get(key)

# 正确写法：使用连接池

redis_pool = redis.ConnectionPool(

host='redis',

max_connections=100, # 严格限制

retry_on_timeout=True

)

r = redis.Redis(connection_pool=redis_pool)

上线后连接数稳定在87，延迟回归正常。这个教训告诉我们：监控不能只看CPU，更要盯住网络连接数、文件描述符数、线程数等底层指标。

5.3 “AB测试结果矛盾：A组转化率高，但GMV低”——归因逻辑漏洞

某次推荐模型AB测试显示A组点击率+2.1%，但最终成交额-0.8%。表面看是模型问题，实则归因错误：

A组用户被推了更多高单价商品，点击率高但转化率低
B组推了更多低价高频商品，点击率低但转化率高

根因分析：
我们漏掉了“商品价格分桶”维度。正确的归因应该按商品价格区间（0-50元、50-200元、200+元）分别统计点击率和GMV，再加权汇总。

解决方案：
在数据仓库中建立ab_test_analysis视图，强制包含以下字段：

trace_id（用于关联全链路）
group_id（A/B组标识）
product_price_bucket（价格分桶）
click_flag（是否点击）
order_amount（成交金额）

然后用SQL计算：

SQL

SELECT

group_id,

SUM(order_amount) / COUNT(*) as avg_gmv_per_user,

SUM(click_flag) * 100.0 / COUNT(*) as click_rate_pct

FROM ab_test_analysis

GROUP BY group_id;

这个视图成为所有AB测试的黄金标准，杜绝了维度遗漏导致的误判。

5.4 “模型更新后，部分用户预测结果突变”——特征缓存击穿

现象：模型版本v2上线后，约0.3%的用户预测概率从0.12突变为0.89，但特征值未变。

排查过程：

抓取异常用户的trace_id，在日志中搜索全链路
发现特征服务返回的user_click_rate_7d值为空（None）
追查Redis，发现该key TTL为0（永久缓存），但HBase中对应记录已被清理

根本原因：
特征写入时设置了ttl=0，但HBase的TTL清理策略与Redis不一致，导致Redis中残留了“幽灵特征”。

修复措施：

所有特征写入必须设置明确TTL（如ttl=3600）
增加Redis Key扫描任务，每日凌晨扫描*:*:*模式的key，删除TTL为0的key
在特征服务中增加空值检测：若Redis返回None，则主动触发HBase查询并刷新Redis

这个Bug让我们意识到：缓存不是银弹，必须有配套的治理机制。

5.5 “线上服务偶发503，但日志无错误”——gRPC Keepalive配置缺失

现象：服务运行一周后，偶发503错误，重启后立即恢复。

诊断：
kubectl logs无ERROR日志，但kubectl describe pod显示Readiness probe failed。

根因：
gRPC客户端未配置Keepalive，TCP连接在云环境的NAT网关超时（通常300秒）后被静默断开，但客户端仍认为连接有效，导致后续请求失败。

解决方案：
在gRPC客户端配置中添加：

PYTHON

channel = grpc.insecure_channel(

'model-service:8001',

options=[

('grpc.keepalive_time_ms', 30000), # 每30秒发keepalive

('grpc.keepalive_timeout_ms', 10000), # 10秒超时

('grpc.keepalive_permit_without_calls', True),

]

)

这个配置让连接在NAT超时前主动保活，彻底解决503问题。记住：云环境中的网络不是理想的，必须为各种“静默断连”做预案。

6. 实战经验总结：那些文档里不会写的真相

我在三个不同行业的ML应用落地中，踩过太多坑，有些教训至今想起来还头皮发麻。这里分享几个最痛的真相，没有修饰，全是血泪：

第一，永远不要相信“训练环境复现”。我们曾为一个金融模型花了两周时间，在训练环境完美复现线上问题，结果上线后问题依旧。最后发现，线上特征服务用的是Redis Cluster，而训练环境用的是单机Redis，Cluster的哈希槽分配导致某些key路由到不同节点，而我们的特征计算逻辑恰好依赖key的物理位置。解决方案？训练环境必须用和线上完全一致的中间件拓扑，哪怕多花三倍成本。

第二，监控告警的阈值必须动态调整。把Model Latency P99告警阈值设为固定200ms是愚蠢的。大促期间流量翻10倍，P99自然会上升。我们现在的做法是：用Prometheus的avg_over_time函数计算过去1小时的P99均值，告警阈值设为均值 * 1.5。这样既敏感又不误报。

第三，文档比代码更重要，但没人愿意写。我强制要求：每个模型上线前，必须提交一份《模型服务说明书》，包含：

输入字段清单（含类型、示例值、是否必填）
输出字段语义（如is_fraud_prob是0-1之间的浮点数，表示欺诈概率）
SLA承诺（P99延迟≤200ms，可用性99.95%）
降级策略（当延迟>500ms时，自动切换至规则引擎）
已知限制（如不支持用户ID含特殊字符）

这份文档必须由算法、工程、产品三方签字，它才是真正的合同，而不是口头承诺。

最后说个反直觉的经验：上线前的压测，要故意制造故障。我们有个固定流程：在压测峰值时，随机kill掉一个特征服务实例，观察熔断器是否在5秒内触发，降级是否生效，监控告警是否准时到达。只有通过这种“混沌工程”考验的服务，才允许上生产。因为真实世界里，故障永远不会按你预期的方式发生。

这个过程听起来繁琐，但每次大促前，当业务方说“这次完全没操心推荐系统”时，我就知道，那些熬过的夜、改过的配置、写过的文档，全都值了。ML Enabled Application的终极目标，不是证明模型有多聪明，而是让业务敢把关键决策交给它——这需要的不是算法深度，而是工程厚度。