模型即产品：构建可审计、可持续的机器学习交付契约

1. 项目概述：这不是一次“部署上线”，而是一场系统性交付实战

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被日常讨论轻描淡写带过的真相。它不是教你怎么把model.fit()换成model.predict()，也不是演示一个Flask接口加个@app.route('/predict')就叫“上生产”。我带团队落地过17个跨行业ML项目，从银行反欺诈模型到工厂设备振动异常检测，再到连锁药店的销量动态补货系统，每一次真正进入业务主流程、承担决策责任、接受7×24小时高并发调用、被财务系统对账、被运维监控告警、被法务合规审查的那一刻，我才彻底明白：Notebook和Production之间，隔着的不是代码，而是一整套工程契约、数据契约与组织契约。Part 4之所以关键，是因为它直面前三部分（数据管道搭建、模型训练标准化、离线评估闭环）之后最硬的骨头——模型如何在真实业务流中持续、可信、可审计地产生价值，而不是成为运维半夜三点的告警源头或业务方反复质疑的“黑盒幻觉”。它解决的是“模型上线后第二天就失效”“A/B测试结果和线上效果对不上”“模型突然预测全错但日志里找不到线索”这类让算法工程师头皮发麻、让业务负责人失去信任的真实困境。适合正在把第一个模型从实验室推向核心业务系统的工程师、MLOps实践者、技术型产品经理，以及那些已经写完requirements.txt却卡在“怎么才算真正交付”的技术负责人。你不需要是Kubernetes专家，但必须愿意直面日志、指标、版本号和变更审批单。

2. 内容整体设计与思路拆解：为什么“模型服务化”只是起点，而非终点

2.1 核心设计哲学：从“模型即服务”转向“模型即产品”

很多团队卡在Part 4，根本原因在于思维定式没转过来。他们以为把模型打包成Docker镜像、跑在K8s上、暴露一个HTTP端点，就完成了“Production”。这是典型的“模型即服务”（Model-as-a-Service）思维——关注的是技术可达性。而Part 4要推行的是“模型即产品”（Model-as-a-Product）思维——关注的是业务可用性、可维护性与可持续性。前者问：“能不能调通？”；后者问：“调通了，业务敢不敢用？出了问题谁负责？下次迭代要不要停机？数据漂移了怎么通知？模型效果下滑了怎么回滚？”

我见过最典型的失败案例是一家电商公司，其推荐模型在Jupyter里AUC高达0.92，上线后首周GMV不升反降3%。排查发现：模型依赖的用户实时点击流特征延迟平均达47秒，而业务规则要求特征新鲜度必须<5秒；同时，模型服务未做请求级熔断，当特征服务短暂抖动时，大量请求堆积导致P99延迟飙升至8秒，前端直接超时放弃，用户看到的全是“加载中…”。问题根源不在模型本身，而在整个交付链路缺乏契约意识——没有明确定义特征SLA、没有定义服务SLO、没有建立效果监控基线。Part 4的设计，就是围绕这三类契约展开：数据契约（Data Contract）、服务契约（Service Contract）、效果契约（Performance Contract）。每一个契约都对应一套可验证、可审计、可自动化的机制，而非文档里的漂亮话。

2.2 架构选型逻辑：拒绝“大而全”，拥抱“小而准”的分层治理

市面上MLOps平台琳琅满目，从开源的MLflow、KServe到商业的SageMaker、Azure ML，但Part 4的实践坚决反对“一揽子采购”。我们采用的是分层解耦、按需组装策略：

• 底层基础设施层（Infra Layer）：不自建K8s集群，而是直接使用云厂商托管的EKS/AKS/GKE。理由很实在：90%的MLOps团队没有专职SRE，自己维护K8s控制平面的故障率、升级复杂度、安全补丁压力远超模型迭代需求。托管服务把etcd崩溃、API Server雪崩这些“脏活”屏蔽掉，让我们专注在模型交付本身。

• 中间件编排层（Orchestration Layer）：弃用Airflow做模型训练流水线，改用Prefect。不是因为Airflow不好，而是Airflow的DAG定义强耦合于Python脚本执行，难以表达“特征计算失败时自动触发数据质量检查”这类条件分支逻辑。Prefect的Task状态驱动（if task.state.is_failed(): run_data_quality_check()）更贴合ML工作流的不确定性本质。对于实时推理，我们不用KServe的复杂CRD，而是用轻量级的Triton Inference Server + 自研的Feature Gateway。Triton原生支持多框架、动态批处理、GPU显存优化，而Feature Gateway则统一处理特征拉取、缓存、拼接、Schema校验——它才是连接离线数仓与在线服务的“翻译官”。

• 上层治理层（Governance Layer）：这是Part 4的真正核心。我们不依赖平台内置的“模型注册表”，而是构建了基于GitOps的模型元数据仓库（Model Metadata Repo）。每个模型发布都对应一个Git PR，包含：模型二进制哈希、训练数据快照ID、特征清单及版本、SLO声明（如P95延迟≤200ms，错误率≤0.5%）、监控指标配置（Prometheus exporter配置）、回滚预案（指向前一稳定版本的Docker镜像tag）。Git commit就是部署审批单，PR评论区就是跨职能评审会。法务要看数据使用授权？看Git提交记录里的data_usage_policy.md；运维要查资源配额？看k8s_resources.yaml；算法要对比历史版本效果？metrics_comparison.csv已由CI流水线自动生成并附在PR描述中。

这种分层不是炫技，而是为了应对现实约束：算法团队想快速试错（需要灵活的训练框架），运维团队要保障稳定性（需要确定的资源边界），合规团队要留痕审计（需要不可篡改的变更记录）。大一统平台往往在某一层妥协，而分层架构让每层都能选最趁手的工具。

2.3 关键取舍：为什么放弃“全自动回滚”，坚持“人工确认式发布”

几乎所有MLOps教程都鼓吹“自动检测效果下降→自动回滚到上一版”。我们在Part 4中明确禁用此功能，改为“自动告警+人工确认+一键回滚”。原因有三：

1. 业务影响不可逆：模型效果下降≠业务受损。例如，风控模型AUC下降0.02，可能只是因近期营销活动导致用户行为分布轻微偏移，实际坏账率未变；但若自动回滚，可能切回一个对新客识别率更低的旧模型，反而增加坏账。效果指标必须与业务指标（如逾期率、转化率）联动判断，而业务指标存在天然滞后性（坏账需30天后才确认），无法实时驱动自动化。

2. 归因复杂度极高：线上效果下滑，90%的案例根源不在模型本身。可能是上游特征ETL任务延迟、数据源Schema变更未同步、网络抖动导致特征缺失填充异常、甚至CDN缓存了旧版前端JS导致埋点数据错乱。自动回滚会掩盖真正的根因，让问题变成“玄学”。

3. 责任边界模糊：谁有权决定“现在必须回滚”？算法工程师？SRE？业务方？没有清晰的RACI矩阵（Responsible, Accountable, Consulted, Informed）前，自动化就是甩锅。

因此，我们的方案是：监控系统（Grafana+Prometheus）一旦检测到SLO违规（如连续5分钟P95延迟>250ms），立即触发企业微信/钉钉告警，并生成一份《影响分析报告》自动发送给算法、SRE、业务PM三方。报告包含：异常时间段、受影响的API端点、关联的特征服务状态、近1小时特征数据分布变化热力图、历史同时间段基线对比。人工确认不是低效，而是强制跨职能对齐的仪式感。确认后，运维只需在Git仓库中合并一条“回滚PR”，CI/CD流水线自动拉取旧版镜像、更新K8s Deployment，全程<90秒。效率不输自动，但可控性与可追溯性天壤之别。

3. 核心细节解析与实操要点：让每个环节都经得起推敲

3.1 数据契约：特征版本化与Schema强校验

数据是模型的血液，而特征就是经过加工的“血细胞”。Part 4的第一道防线，是确保每次推理请求拿到的特征，在类型、范围、缺失率上与训练时完全一致。我们不依赖“相信上游”，而是用代码强制契约。

特征版本化（Feature Versioning）：
所有特征计算逻辑（SQL或PySpark脚本）必须存放在独立的feature-repoGit仓库中，每个提交打语义化标签（v1.2.0）。模型训练时，train.py中明确声明所用特征版本：

# train.py from feature_repo import get_feature_data feature_data = get_feature_data( version="v1.2.0", # 硬编码，非环境变量 start_date="2024-01-01", end_date="2024-01-31" )

训练完成的模型文件（.pkl或.onnx）中，嵌入该特征版本号作为元数据。推理服务启动时，首先校验自身加载的特征服务版本是否匹配模型元数据中的声明，不匹配则直接panic退出，拒绝提供任何服务。这杜绝了“模型用v1.1训练，服务却连着v1.2特征库”的经典灾难。

Schema强校验（Schema Validation）：
特征Gateway在返回特征向量前，执行两层校验：

• 静态校验：加载预定义的feature_schema.json（存于Git），检查字段名、数据类型（int64,float32,string）、是否允许为空、枚举值范围（如user_gender只能是["M","F","O"]）。
• 动态校验：对本次请求的实时特征数据，计算统计摘要（缺失率、数值型字段的min/max/std、字符串长度分布），与训练期保存的schema_stats.pkl（同样Git管理）进行比对。若缺失率突增>5%，或某数值字段std偏离训练期均值2个标准差，则标记该请求为DATA_DRIFT，记录到专用日志流，并返回带X-Warning: DataDriftDetected头的响应，供业务方决定是否降级处理。

提示：schema_stats.pkl不是训练时一次性快照，而是每日凌晨由离线作业重新计算并覆盖。它本身也是Git管理的，每次更新都触发一次“特征健康度”邮件简报，发送给算法和数据工程师。

3.2 服务契约：SLO定义、可观测性与熔断降级

服务契约的核心是回答：“业务方能指望这个模型服务做到什么程度？”答案不能是“尽力而为”，而必须是量化、可测量、可追责的SLO。

SLO定义与分级：
我们为每个模型服务定义三级SLO：

• 黄金指标（Golden Signals）：success_rate（HTTP 2xx/全部请求）、latency_p95（毫秒）、error_budget_burn_rate（错误预算消耗速率）。例如，推荐服务SLO：success_rate ≥ 99.95%,latency_p95 ≤ 200ms,error_budget_burn_rate < 1.0（每月允许0.05%错误率，即4.32分钟宕机）。
• 业务指标（Business Metrics）：ctr（点击率）、conversion_rate（转化率）。这些不直接用于服务治理，但与黄金指标联动告警。例如，若success_rate正常但ctr连续2小时下降>10%，则触发“效果异常”告警，而非“服务异常”。
• 资源指标（Resource Metrics）：cpu_utilization,gpu_memory_used,feature_cache_hit_rate。这些是根因分析的线索，不设SLO阈值，但纳入监控大盘。

可观测性三支柱落地：

• Logging：拒绝print()和logging.info()。所有日志结构化为JSON，强制包含request_id（全链路追踪ID）、model_version、feature_version、inference_time_ms、input_hash（输入特征的SHA256，用于复现问题）。日志通过Fluent Bit收集到Loki，支持按request_id秒级检索完整调用链。
• Metrics：使用Prometheus Client暴露指标。关键自定义指标包括：model_inference_total{model="rec_v2",version="1.3.0",status="success"}、feature_fetch_latency_seconds_bucket{feature="user_click_7d",le="100"}。Grafana大盘按模型维度聚合，首页显示各模型SLO达成率热力图。
• Tracing：集成OpenTelemetry，自动注入trace_id。特别追踪特征拉取路径：[Frontend] → [Feature Gateway] → [Redis Cache] → [Flink Job] → [ClickHouse]。当延迟高时，一眼看出瓶颈在缓存未命中还是下游数据库慢。

熔断降级（Circuit Breaking & Fallback）：
我们采用Netflix Hystrix思想，但实现更轻量。在Feature Gateway中嵌入熔断器：

• 当feature_fetch_latency_seconds_count{le="500"}在1分钟内低于总请求数的95%，开启熔断。
• 熔断期间，Gateway不再调用下游特征服务，而是返回预存的“兜底特征”（fallback_features.json，Git管理，每日自动更新）。
• 同时，Gateway将当前请求标记为DEGRADED，记录到单独日志流，并触发“特征服务健康度”告警。

注意：兜底特征不是随机值，而是训练期统计的全局均值/众数。例如，user_age用全量用户中位数，item_price用品类均价。它保证服务不挂，且预测结果在业务可接受范围内波动，而非完全失真。

3.3 效果契约：在线评估闭环与AB测试基础设施

离线评估（AUC、F1）只是入场券，Part 4的终极目标是建立在线效果评估闭环——让模型效果像服务器CPU一样，被实时、客观、无偏见地度量。

Shadow Mode（影子模式）部署：
新模型上线前，必经Shadow Mode：

1. 流量100%走旧模型（v1.2.0），但同时将完全相同的请求体异步发送给新模型（v1.3.0）进行推理。
2. 新模型输出不参与业务决策，仅记录到shadow_resultsKafka Topic，包含：request_id,old_prediction,new_prediction,timestamp,business_outcome（如该次推荐后用户是否点击）。
3. 实时Flink作业消费shadow_results，计算new_prediction与business_outcome的相关性（如点击率提升幅度），并与old_prediction对比。
4. 连续72小时，新模型在关键业务指标上稳定优于旧模型≥2%，方可进入AB测试。

Shadow Mode的价值在于：零业务风险下获取真实世界效果数据。它绕开了离线评估的最大陷阱——“用过去的数据预测未来的分布”。用户行为是活的，只有在真实流量中，才能看到模型对新交互模式（如新UI、新活动）的适应能力。

AB测试基础设施：
我们不依赖第三方AB平台，而是用K8s Service Mesh（Istio）实现精准流量分割：

• 定义两个K8s Service：model-v1-2和model-v1-3，分别指向不同版本的Pod。
• Istio VirtualService按request_id哈希（确保同一用户始终路由到同一版本）将流量按比例分发（如95%→v1.2, 5%→v1.3）。
• 所有请求头注入X-Model-Version: v1.2，供业务方在埋点日志中区分。
• AB结果分析不靠Excel，而是用预置的SQL模板查询BigQuery：

  SELECT model_version, COUNT(*) as impressions, SUM(IF(click=1,1,0)) as clicks, SUM(IF(purchase=1,1,0)) as purchases, DIVIDE(SUM(IF(click=1,1,0)), COUNT(*)) as ctr FROM `project.dataset.ab_logs` WHERE event_time >= '2024-01-01' AND model_version IN ('v1.2','v1.3') GROUP BY model_version

  结果自动渲染到Grafana AB对比面板，支持T检验P值计算。决策依据不是“看起来好”，而是“统计显著且业务价值达标”。

4. 实操过程与核心环节实现：从代码到上线的完整链路

4.1 模型发布全流程：一次标准发布的12个关键步骤

以发布一个新版本的搜索排序模型（search-rank-v2.1.0）为例，完整流程如下。每一步都有自动化脚本支撑，但关键决策点需人工确认。

1. 【算法】本地开发与验证：在Notebook中完成特征工程、模型训练、离线评估。导出模型为ONNX格式，生成model.onnx和metadata.json（含特征版本、SLO声明、作者、变更说明）。

2. 【算法】提交模型资产：将model.onnx、metadata.json、requirements.txt（仅含推理依赖，如onnxruntime==1.16.0）推送到model-registryGit仓库的search-rank目录下，分支feat/v2.1.0。

3. 【CI】自动化校验：GitHub Actions触发：

   • 校验metadata.json格式合法性（JSON Schema）；
   • 用onnx.checker.check_model()验证ONNX模型完整性；
   • 运行pytest tests/test_inference.py，用合成数据测试推理接口是否返回预期结构。

4. 【CI】构建Docker镜像：校验通过后，自动构建Docker镜像：

   FROM nvcr.io/nvidia/pytorch:23.10-py3 COPY model.onnx /app/model.onnx COPY metadata.json /app/metadata.json COPY requirements.txt /app/requirements.txt RUN pip install -r requirements.txt CMD ["python", "server.py"]

   镜像Tag为search-rank:v2.1.0-<git_commit_hash>，推送到私有Harbor仓库。

5. 【算法】创建发布PR：在model-registry仓库发起PR，目标分支main。PR描述中必须填写：

   • 变更摘要（如“优化长尾Query召回，提升尾部Query CTR 1.2%”）；
   • 关联的Jira Ticket（如ML-456）；
   • 离线评估报告链接（MLflow UI截图）；
   • Shadow Mode预期观察指标（如“重点关注Query长度>10字的CTR提升”）。

6. 【跨职能】PR评审：

   • SRE：检查metadata.json中的resources字段（CPU/MEM/GPU request）是否合理，是否与集群现有配额冲突；
   • 数据工程师：核对metadata.json中feature_versions是否与feature-repo中对应版本兼容；
   • 法务：确认metadata.json中data_usage_policy符合最新合规要求；
   • 业务PM：确认变更摘要与业务目标对齐，无歧义。

7. 【算法】启动Shadow Mode：PR合并后，CI自动触发Shadow Mode部署脚本：

   • 更新K8s ConfigMap，添加新模型配置；
   • 重启Feature Gateway，加载新配置；
   • 向Kafka发送shadow_start事件，启动Flink影子分析作业。

8. 【算法/SRE】监控Shadow结果：每日晨会查看Grafana Shadow Dashboard，重点关注：

   • shadow_new_vs_old_ctr_diff（新旧模型CTR差异趋势）；
   • shadow_request_volume（确保流量覆盖足够多样本）；
   • shadow_data_drift_alerts（是否有特征漂移告警）。

9. 【算法】申请AB测试：Shadow数据达标（72小时CTR提升≥1.5%且P<0.01）后，在内部系统提交AB测试申请，指定流量比例（建议从1%开始）、测试周期（至少7天）、核心观测指标（CTR、GMV、停留时长）。

10. 【SRE】执行AB分流：收到申请后，SRE执行Istio命令，创建VirtualService，将1%流量路由至search-rank-v2.1.0Service。

11. 【算法/业务】AB结果分析：测试结束，自动运行AB分析SQL，生成PDF报告。报告需包含：

    • 统计显著性结论（T检验P值、置信区间）；
    • 业务影响估算（如“预计全量上线后月GMV提升$230K”）；
    • 风险提示（如“新模型对iOS用户CTR提升显著，但Android端持平，需进一步分析”）。

12. 【CTO/业务VP】上线决策会议：基于AB报告，召开15分钟短会。若结论为“显著正向且无重大风险”，则批准全量发布。SRE执行最后一步：更新K8s Service的Selector，将100%流量切至v2.1.0。整个流程从代码提交到全量上线，平均耗时5.2个工作日，其中70%时间花在跨职能对齐与数据验证上，而非技术操作。

4.2 关键配置详解：metadata.json与SLO监控配置

metadata.json是模型的“数字身份证”，其结构直接影响后续所有自动化流程。以下是search-rank-v2.1.0的精简示例及关键字段解读：

{ "model_name": "search-rank", "version": "2.1.0", "author": "zhang.san@company.com", "created_at": "2024-01-15T08:23:45Z", "description": "Optimized for long-tail queries (>10 chars), using new user intent features.", "framework": "onnx", "input_schema": { "query_text": {"type": "string", "max_length": 100}, "user_features": {"type": "object", "properties": {"age": {"type": "integer"}, "gender": {"type": "string"}}}, "item_features": {"type": "array", "items": {"type": "object", "properties": {"price": {"type": "number"}}}} }, "output_schema": {"score": {"type": "number"}}, "feature_versions": { "user_click_30d": "v1.4.0", "item_price_trend": "v2.0.1", "query_intent_embedding": "v3.2.0" }, "slo": { "success_rate": {"target": 0.9995, "window": "30d"}, "latency_p95_ms": {"target": 200, "window": "1h"}, "error_budget_monthly_minutes": 4.32 }, "resources": { "cpu_request": "2", "memory_request": "4Gi", "gpu_request": "1" }, "data_usage_policy": "GDPR_Compliant_v2.1", "rollback_to": "v2.0.0" }

• input_schema与output_schema：不仅是文档，更是运行时校验依据。推理服务启动时，会根据此Schema生成Pydantic模型，对每次请求的JSON Body进行严格校验，非法输入直接400返回，不进入模型计算。这避免了“类型错误导致模型崩溃”的低级事故。

• slo字段：error_budget_monthly_minutes是success_rateSLO的具象化。计算公式为：30天 * 24小时 * 60分钟 * (1 - 0.9995) = 4.32分钟。Prometheus监控规则直接基于此计算error_budget_burn_rate：

  (sum(rate(http_requests_total{status=~"5.."}[30d])) * 4.32 * 60) / (sum(rate(http_requests_total[30d])) * 30 * 24 * 60 * 60)

  值>1.0即表示错误预算已超支，触发最高优先级告警。

• resources字段：K8s Deployment模板中，resources.requests直接读取此值。SRE评审PR时，会用kubectl describe nodes检查集群剩余GPU资源，若gpu_request=1但节点只剩0.5 GPU，则PR被拒绝，强制算法团队优化模型（如量化）或申请扩容。

SLO监控配置（Prometheus Rule）示例：

groups: - name: search-rank-slo rules: - alert: SearchRankSuccessRateBelowTarget expr: | 1 - sum(rate(http_requests_total{job="search-rank",status=~"5.."}[30d])) / sum(rate(http_requests_total{job="search-rank"}[30d])) < 0.9995 for: 10m labels: severity: critical annotations: summary: "Search Rank success rate below 99.95% for 30d window" description: "Current rate is {{ $value | humanizePercentage }}" - alert: SearchRankLatencyP95AboveTarget expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="search-rank"}[1h])) by (le)) > 0.2 for: 5m labels: severity: warning annotations: summary: "Search Rank P95 latency above 200ms for 1h window" description: "Current P95 is {{ $value | humanize }}s"

4.3 实操现场记录：一次紧急回滚的完整复盘

2024年1月18日 22:17，search-rank-v2.1.0全量上线后第37分钟，Grafana告警：SearchRankLatencyP95AboveTarget触发。P95延迟从180ms飙升至310ms，且持续上升。

Step 1：初步定位（22:17-22:22）

• 查看search-rankK8s Pod日志：大量FeatureFetchTimeout错误，指向query_intent_embedding特征服务。
• 检查query_intent_embedding服务监控：其P95延迟从80ms升至1200ms，且CPU使用率100%。
• 原因锁定：上游Flink作业因新加入的用户行为日志格式变更（新增event_subtype字段），导致反序列化失败，任务重启风暴，拖垮整个特征服务。

Step 2：启动应急响应（22:22-22:25）

• SRE执行kubectl scale deploy query-intent-embedding --replicas=0，强制停止故障服务。
• Feature Gateway自动切换至熔断状态，开始返回兜底特征（fallback_features.json）。
• 监控显示：search-rankP95延迟回落至210ms（仍略高，因兜底特征计算开销），success_rate维持99.98%。

Step 3：人工确认回滚（22:25-22:28）

• SRE在Git仓库创建PRrevert-search-rank-to-v2.0.0，内容为将search-rankService的Selector从version=v2.1.0改为version=v2.0.0。
• @算法负责人张三审核：确认v2.0.0在Shadow Mode中表现稳定，且无已知兼容性问题。
• @业务PM李四确认：v2.0.0虽CTR略低，但延迟稳定，用户体验不受损。

Step 4：执行回滚（22:28-22:29）

• PR合并，CI/CD自动更新K8s Deployment。
• search-rankPod滚动更新，22:29:15，所有Pod切换至v2.0.0。
• 监控显示：P95延迟瞬间回落至175ms，success_rate回升至99.995%。

Step 5：事后复盘（1月19日 10:00）

• 根本原因：Flink作业未做Schema兼容性校验，上游日志变更未通知下游。
• 改进项：
  • 在Flink作业中加入Avro Schema Registry校验，不兼容变更直接失败告警；
  • Feature Gateway增加feature_service_health探针，当特征服务延迟>500ms持续1分钟，自动触发降级，无需等待SLO告警；
  • 将query_intent_embedding服务的SLOlatency_p95_ms从500收紧至300，提前暴露风险。

这次回滚耗时12分钟，全程无人工SSH登录服务器，所有操作均可审计、可重放。它证明了Part 4设计的有效性：当技术故障发生时，流程比英雄主义更可靠。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 典型问题速查表

5.2 独家避坑技巧：来自血泪教训的3条铁律

铁律一：永远不要在模型服务中做特征计算，只做特征拼接
新手常犯错误：在server.py里写def get_user_features(user_id): return db.query(...)。这会导致：

• 数据库连接池耗尽（每个请求都建新连接）；
• 模型服务与数据库强耦合，DB慢=模型慢；
• 无法统一做特征缓存、降级、监控。
  正确做法：特征计算必须在独立的Feature Service中完成，模型服务只通过HTTP/gRPC调用Feature Service，拿到的是已计算好的、带版本号的特征向量。Feature Service负责一切：缓存（Redis）、降级（兜底值）、监控（延迟、错误率）、限流（防止打垮DB）。模型服务越“傻”，系统越稳。

铁律二：SLO的“窗口”必须与业务节奏匹配，而非技术直觉
很多人设latency_p95窗口为1h，认为“小时级足够快”。但业务视角不同：

• 电商大促期间，流量呈尖峰脉冲，1小时内可能经历3次峰值。用1h窗口会平滑掉峰值延迟，掩盖真实问题。
• 而夜间低峰期，1h窗口可能因样本少导致统计失真。
  我们的实践：对`