1. 项目概述：这不是一次“部署”，而是一场从实验室到产线的系统性迁移
“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被无数数据科学家反复咀嚼、又悄悄咽下的苦涩真相：写完model.fit()并不等于项目结束，它往往只是真正挑战的起点。我在一线带过二十多个从0到1落地的机器学习项目，亲眼见过太多团队在Jupyter里调出98%的AUC后集体松一口气，结果上线第一周就因特征延迟3秒、模型响应超时、线上数据漂移未告警，被业务方连夜叫停。Part 4不是技术演进的第四个步骤，而是整个链条中承上启下的“临界点”——它直指那个最常被忽略却最致命的问题：当模型离开受控的Notebook环境，进入真实世界千变万化的数据流、不稳定的基础设施、严苛的SLA要求和持续演化的业务逻辑时，它还能不能活下来？这不是教你怎么打包Docker镜像，而是带你拆解一套可监控、可回滚、可演进、能扛住流量洪峰和数据脏乱的生产级ML服务骨架。核心关键词——模型服务化（Model Serving）、实时推理（Real-time Inference）、特征一致性（Feature Consistency）、可观测性（Observability）、CI/CD for ML——每一个词背后都对应着至少三个踩过的坑和两条血泪经验。适合谁看？刚把模型跑通的算法工程师、正被业务方追问“什么时候能上线”的数据平台负责人、以及所有以为“模型上线=项目交付”的技术管理者。你不需要精通Kubernetes，但得清楚为什么用gRPC比REST更适合高吞吐推理；你不必手写Prometheus exporter，但必须明白为什么只监控CPU和内存是自欺欺人。
2. 整体设计思路：为什么放弃“一键部署”，选择分层解耦架构
2.1 核心矛盾：Notebook的“确定性幻觉” vs 真实世界的“混沌本质”
在Jupyter里，pd.read_csv('data.csv')是确定的，model.predict(X_test)是瞬时的，plt.show()是所见即所得的。这种确定性是生产力的温床，也是生产事故的温床。真实世界里，data.csv可能是上游ETL任务失败后残留的空文件，X_test可能因API网关超时只传了前50%字段，plt.show()的图表可能因前端JS版本升级而渲染错位。Part 4的设计哲学，就是主动打破这种幻觉，用架构设计承认并管理不确定性。我们放弃“Notebook导出为API”的粗暴路径，转而采用四层解耦架构：特征层（Feature Layer）→ 模型层（Model Layer）→ 服务层（Serving Layer）→ 接入层（Ingress Layer）。每一层都有明确边界、独立生命周期和清晰契约（Contract）。比如特征层只负责提供feature_vector，不关心模型怎么用；模型层只接收标准向量，不解析原始JSON；服务层只做协议转换和负载均衡，不碰业务逻辑。这种解耦不是为了炫技，而是为了解决三个刚需：
- 故障隔离：上游特征计算异常，不会导致模型服务OOM崩溃，只会返回预设的降级特征；
- 独立演进：业务方要求新增一个用户画像标签，只需更新特征层SQL，模型和服务层完全无感；
- 灰度验证：新模型v2上线时，可让10%流量走v2，90%走v1，对比指标后再全量——这在单体Notebook部署里需要手动改代码、重启服务，风险极高。
提示：我见过最惨烈的案例，是某电商推荐模型直接把Jupyter Notebook用nbconvert转成Python脚本，塞进Flask路由里。结果大促期间特征计算耗时从200ms飙升到3s，Flask主线程被阻塞，整个API集群雪崩。根本原因在于没有分离“特征计算”和“模型推理”这两个耗时差异巨大的环节。
2.2 工具链选型：为什么是FastAPI + Triton + Feast + Prometheus，而不是Flask + ONNX + 自研？
工具选型不是拼配置参数，而是匹配场景约束。我们逐层拆解：
服务层（Serving Layer）为何选Triton而非Flask/Starlette？
Triton的核心价值不在“支持多框架”，而在统一的异步执行引擎和GPU资源调度。当你的模型是BERT-base（需GPU）+ LightGBM（CPU）+ 规则引擎（纯Python）的混合体时，Flask会把所有请求塞进同一个GIL线程池，GPU模型排队等CPU模型释放线程，吞吐量断崖下跌。Triton则为每类模型分配独立的执行队列，GPU模型走CUDA Stream，CPU模型走线程池，规则引擎走协程，三者互不抢占。实测同一套模型，在Triton下P99延迟稳定在120ms，Flask下波动在80ms~2.3s之间。参数选择上，我们固定--max_batch_size=32（平衡延迟与吞吐），启用--kind=ensemble组合多模型流水线，这是Flask无法原生支持的。特征层（Feature Layer）为何选Feast而非自建Redis缓存？
自建缓存解决的是“快”，Feast解决的是“准”和“稳”。Feast强制定义FeatureView（含源表、转换逻辑、TTL），所有特征计算必须通过get_online_features()接口，杜绝了算法同学在Notebook里手写SELECT * FROM user_profile WHERE user_id=xxx这种绕过一致性校验的操作。更重要的是，Feast的OnlineStore支持自动回填（Backfill）和在线/离线特征一致性校验（Consistency Check）。我们曾发现某次特征上线后，线上服务返回的user_age和离线训练用的user_age相差2岁——根源是离线ETL用了FLOOR(DATEDIFF(NOW(), birth_date)/365)，而线上SQL用了YEAR(NOW()) - YEAR(birth_date)。Feast的校验机制在灰度期就捕获了这个问题，避免了模型效果劣化。可观测性（Observability）为何用Prometheus+Grafana而非ELK？
ELK擅长日志全文检索，但ML服务的关键指标是结构化时序数据：每秒请求数（RPS）、P50/P90/P99延迟、特征缺失率、模型输出分布偏移（KS Statistic）、GPU显存占用。Prometheus的拉取模型（Pull Model）天然适配服务端指标暴露（/metrics端点），Grafana的面板能直接画出“延迟热力图”（按小时+模型版本维度），这是ELK做不到的。我们甚至用Prometheus的histogram_quantile()函数，实时计算“过去5分钟内，v1模型的P95延迟是否超过200ms”，触发企业微信告警。接入层（Ingress Layer）为何用Envoy而非Nginx？
Envoy的x-envoy-upstream-service-time头能精确记录后端服务处理时间（不含网络传输），配合Jaeger做分布式追踪，能定位到“是特征层耗时长，还是模型层卡顿”。Nginx只能记录总耗时，无法区分瓶颈。在一次故障排查中，Envoy的追踪链路直接显示90%耗时在feature-store服务，而非model-serving，让我们30分钟内定位到Feast的Redis连接池泄漏问题。
3. 核心细节解析：特征一致性、模型服务化与可观测性的落地铁三角
3.1 特征一致性：从“数据对齐”到“语义对齐”的硬核实践
特征一致性（Feature Consistency）常被简化为“线上线下特征值一样”，这是巨大误区。真正的挑战是语义一致性（Semantic Consistency）——即特征在离线训练和线上服务中，计算逻辑、数据源、时间窗口、缺失值处理方式完全一致。我们以一个典型风控特征7d_avg_transaction_amount为例，拆解三层对齐：
数据源对齐：离线训练用Hive表
ods_user_transaction_d（T+1分区），线上服务必须用同一张表的最新快照，而非MySQL里的实时交易表（存在主从延迟）。Feast通过BatchSource绑定Hive表，并在FeatureView中指定ttl=timedelta(days=7)，确保线上查询时自动过滤过期数据。计算逻辑对齐：离线SQL是
SELECT user_id, AVG(amount) FROM ods_user_transaction_d WHERE dt BETWEEN '2023-01-01' AND '2023-01-07' GROUP BY user_id。线上服务若用WHERE dt >= DATE_SUB(NOW(), INTERVAL 7 DAY)，会因时区（服务器UTC vs 业务CST）和NOW()精度（秒级vs毫秒级）导致结果偏差。解决方案是Feast强制要求所有BatchSource使用event_timestamp_column（如transaction_time），线上查询时传入as_of_timestamp参数（如2023-01-07T23:59:59Z），底层自动转换为transaction_time <= '2023-01-07T23:59:59Z' AND transaction_time >= '2023-01-01T00:00:00Z'，彻底规避时区陷阱。缺失值处理对齐：离线训练中，若某用户7天内无交易，
AVG()返回NULL，我们用COALESCE(AVG(amount), 0)填充为0。线上服务若直接返回NULL，模型输入就会报错。Feast的OnlineStore支持default_value参数，我们在FeatureView中定义default_value=0.0，确保线上永远返回0.0。
实操心得：我们开发了一个自动化校验脚本，每天凌晨运行：随机抽取1000个user_id，分别调用Feast的
get_online_features()和离线Hive SQL，对比7d_avg_transaction_amount值。当差异率>0.1%时，自动创建Jira工单并通知特征Owner。这个脚本上线后，特征不一致导致的模型效果下降事件归零。
3.2 模型服务化：Triton的配置艺术与性能压榨技巧
Triton不是装上就能用，它的配置文件config.pbtxt是性能的命门。以一个PyTorch图像分类模型为例，关键配置项解析：
name: "resnet50" platform: "pytorch_libtorch" max_batch_size: 32 input [ { name: "INPUT__0" data_type: TYPE_FP32 dims: [ 3, 224, 224 ] } ] output [ { name: "OUTPUT__0" data_type: TYPE_FP32 dims: [ 1000 ] } ] instance_group [ [ { count: 2 kind: KIND_GPU gpus: [0] } ] ] dynamic_batching { max_queue_delay_microseconds: 100 }max_batch_size: 32的计算依据：不是拍脑袋。我们用tritonperf工具压测，发现当batch_size=16时，GPU利用率65%，P99延迟85ms；batch_size=32时，GPU利用率82%，P99延迟112ms；batch_size=64时，GPU利用率95%，但P99延迟飙升至210ms（显存带宽瓶颈）。综合吞吐（TPS）和延迟，32是最优解。公式：Optimal Batch Size ≈ √(GPU Memory Bandwidth / Model Parameter Size)，实测误差<15%。instance_group中count: 2的深意：Triton为每个GPU实例启动一个独立进程，count: 2表示在GPU0上启动2个进程。这并非为了“多开吃满GPU”，而是应对模型冷启动（Cold Start）问题。当第一个请求到达时，Triton需加载模型权重到GPU显存（约1.2s），此时第二个请求会被排队。设置2个实例后，第一个实例加载时，第二个实例可立即处理请求，P99延迟降低40%。代价是显存占用增加2倍，但换来的是SLA保障。dynamic_batching的max_queue_delay_microseconds: 100：这是平衡延迟与吞吐的杠杆。值越小，请求越快被合批，延迟越低；值越大，合批成功率越高，吞吐越高。我们通过分析线上QPS波峰波谷，发现95%请求间隔<50ms，故设为100μs——既能保证大部分请求合批，又不让用户感知明显延迟。模型格式选择：PyTorch模型我们转为TorchScript（
.pt），而非ONNX。因为Triton对TorchScript的优化更激进（支持torch.jit.fusion），实测同模型下，TorchScript比ONNX快18%。转换命令：python -c " import torch model = torch.hub.load('pytorch/vision', 'resnet50', pretrained=True) model.eval() traced_model = torch.jit.trace(model, torch.randn(1,3,224,224)) traced_model.save('resnet50.pt') "
3.3 可观测性：不只是监控CPU，而是给模型装上“心电图”
ML服务的可观测性有三大盲区：数据盲区（输入数据质量未知）、模型盲区（内部状态不可见）、业务盲区（输出是否符合预期未知）。我们用Prometheus+自定义Exporter构建三维监控：
数据盲区监控：在Triton的
config.pbtxt中启用metrics，暴露nv_gpu_utilization、nv_gpu_memory_used_bytes。但更重要的是特征级监控。我们在Feast的OnlineStore中埋点，统计每秒各特征的miss_rate（查不到值的比例）。当user_credit_score的miss_rate从0.01%突增至5%，说明上游征信接口异常，立即触发降级策略（返回默认分值）。模型盲区监控：Triton原生暴露
inference_request_success、inference_request_failure，但这不够。我们开发了ModelOutputExporter，在模型预测后注入钩子（Hook），采集：- 输出分布：
torch.histc(output, bins=100)生成直方图，计算KL散度（与基线分布对比）； - 预测置信度：对分类模型，取
softmax(output).max(dim=1).values，监控P95置信度是否低于0.7； - 概率校准：用
sklearn.calibration.calibration_curve计算Brier Score，长期跟踪模型是否“过度自信”。
- 输出分布：
业务盲区监控：这才是最关键的。我们定义业务黄金指标（Golden Signals）：
recommendation_click_rate（推荐点击率）：下游业务API埋点，当该指标24小时环比下降>15%，自动关联分析是否新模型上线；fraud_detection_recall（欺诈召回率）：每日离线计算，对比新旧模型在相同测试集上的召回率；abuse_report_rate（滥用举报率）：用户举报接口，当该指标上升，说明模型可能误伤正常用户。
所有指标通过Prometheus Pushgateway上报，Grafana面板配置“异常检测告警”：使用anomaly_detector()函数（基于历史7天数据拟合季节性ARIMA模型），当指标偏离预测区间3σ时，自动告警。这比简单阈值告警（如>100）准确率高62%。
4. 实操过程：从Notebook到K8s集群的完整流水线
4.1 环境准备：本地开发机的最小可行验证（MVP）
在跳上K8s之前，先在本地MacBook Pro（M1 Max）上跑通全流程，验证架构可行性。关键步骤：
- 安装Triton Server：官方Docker镜像
nvcr.io/nvidia/tritonserver:23.09-py3（注意：M1芯片需用--platform linux/amd64强制运行x86容器，性能损失约15%，但足够验证逻辑）。 - 准备模型仓库：创建目录
models/resnet50/1/，放入model.pt和config.pbtxt（内容见3.2节）。 - 启动Triton：
docker run --rm -it --gpus=1 -p8000:8000 -p8001:8001 -p8002:8002 \ -v $(pwd)/models:/models \ nvcr.io/nvidia/tritonserver:23.09-py3 \ tritonserver --model-repository=/models --strict-model-config=false - 本地测试：用
tritonclientPython库发送请求：
此步骤验证了模型加载、推理、输出格式全部正确，耗时<5分钟。这是所有后续工作的基石，跳过此步直接上K8s，90%概率失败。from tritonclient.http import InferenceServerClient, InferInput, InferRequestedOutput client = InferenceServerClient(url="localhost:8000") inputs = [InferInput("INPUT__0", [1,3,224,224], "FP32")] inputs[0].set_data_from_numpy(np.random.rand(1,3,224,224).astype(np.float32)) outputs = [InferRequestedOutput("OUTPUT__0")] result = client.infer("resnet50", inputs, outputs=outputs) print(result.as_numpy("OUTPUT__0").shape) # 应输出 (1, 1000)
4.2 CI/CD流水线：GitOps驱动的模型发布
我们用GitHub Actions + Argo CD实现全自动发布。流程图如下（文字描述）：
- 开发者提交：在
ml-models仓库的main分支提交新模型文件（models/new_model/1/model.pt）和config.pbtxt。 - CI触发：GitHub Actions启动
test-modelJob：- 下载Triton Docker镜像；
- 启动临时Triton服务；
- 运行
pytest tests/test_inference.py（包含100个样本的端到端推理测试）； - 调用
tritonperf压测，验证P99延迟<150ms； - 全部通过才允许合并。
- CD触发：合并后，Argo CD监听
ml-models仓库，检测到models/目录变更，自动同步到K8s集群的model-repoPVC（Persistent Volume Claim）。 - Triton热重载：Triton配置
--model-control-mode=poll --repository-poll-secs=30，每30秒扫描model-repo目录，发现新模型或配置变更，自动加载，无需重启服务。实测重载时间<2秒，业务无感。
注意事项：PVC必须使用
ReadWriteMany访问模式（如NFS或EFS），否则多节点Triton实例无法共享模型仓库。我们曾因用ReadWriteOnce（仅单节点可写）导致部分Pod加载旧模型，引发AB测试数据污染。
4.3 K8s集群部署：生产级资源配置详解
在AWS EKS集群（3台g4dn.xlarge节点）上部署，核心YAML片段：
# triton-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: triton-server spec: replicas: 3 # 3副本保障高可用 selector: matchLabels: app: triton-server template: metadata: labels: app: triton-server spec: containers: - name: triton image: nvcr.io/nvidia/tritonserver:23.09-py3 args: [ "tritonserver", "--model-repository=/models", "--strict-model-config=false", "--grpc-port=8001", "--http-port=8000", "--metrics-port=8002", "--model-control-mode=poll", "--repository-poll-secs=30" ] ports: - containerPort: 8000 # HTTP - containerPort: 8001 # gRPC - containerPort: 8002 # Metrics resources: limits: nvidia.com/gpu: 1 # 每Pod独占1块GPU memory: "8Gi" # 防止OOM cpu: "4" # 保障推理线程 requests: nvidia.com/gpu: 1 memory: "6Gi" cpu: "2" volumeMounts: - name: model-repo mountPath: /models volumes: - name: model-repo persistentVolumeClaim: claimName: model-repo-pvc --- # service.yaml apiVersion: v1 kind: Service metadata: name: triton-service spec: selector: app: triton-server ports: - port: 8000 targetPort: 8000 name: http - port: 8001 targetPort: 8001 name: grpc type: ClusterIP # 内部服务，不暴露公网关键参数解释：
replicas: 3：非冗余设计。当一台节点宕机，剩余2台仍可承载100%流量（Triton单实例QPS可达3500，3实例理论峰值10500，我们业务峰值8200）。nvidia.com/gpu: 1：K8s Device Plugin自动分配GPU，避免多Pod争抢同一GPU。memory: "8Gi"：Triton自身+PyTorch模型加载需约5Gi，预留3Gi防OOM。实测若设为4Gi，大模型加载时必OOM。ClusterIP：Triton服务只供集群内其他服务（如特征服务、API网关）调用，绝不暴露公网，安全第一。
5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训
5.1 Triton模型加载失败：Failed to load 'model' version 1: Internal: unable to get model configuration
现象：Triton日志报错，model_repository目录下文件齐全，config.pbtxt语法检查通过（tritonserver --model-repository=/models --model-control-mode=none可启动）。
排查路径：
- 检查模型文件权限：Docker容器内UID为1001，若宿主机
model.pt属主是root（-rw-r--r-- 1 root root），容器内无法读取。解决方案：chown -R 1001:1001 models/。 - 验证模型格式：PyTorch模型必须是TorchScript（
.pt），不能是.pth（state_dict）。用torch.jit.load('model.pt')在Python中测试能否加载。 - 检查CUDA版本兼容性：Triton 23.09基于CUDA 12.2，若模型用CUDA 11.8编译，会报
undefined symbol: _ZN3c104cuda10getCurrentCUDADeviceIdEv。解决方案：在模型训练环境用conda install pytorch torchvision torchaudio pytorch-cuda=12.2 -c pytorch -c nvidia重装PyTorch。
5.2 特征服务延迟飙升：Feastget_online_featuresP99从50ms升至2s
现象：Grafana显示feast_online_store_query_latency_seconds突增，Redis监控显示connected_clients从200飙到2000。
根因分析：Feast的RedisOnlineStore默认connection_pool大小为100，当并发请求超100，新请求排队等待连接，导致延迟。而我们的业务QPS峰值达1500，远超100。
解决方案：
- 修改Feast配置
feature_store.yaml：online_store: type: redis connection_string: "redis://redis:6379/0" # 新增以下两行 redis_connection_pool_limit: 2000 redis_socket_timeout: 1000 - 在K8s中为Redis Pod扩容：
kubectl scale statefulset redis --replicas=3（主从架构，读写分离）。
实操心得：我们曾以为“Redis很快”，没做连接池压测。直到大促前夜才发现问题，紧急扩容。教训：所有中间件，必须按业务峰值QPS的3倍做连接池容量规划。
5.3 模型输出漂移：线上服务返回的预测概率与离线训练结果偏差>10%
现象：Prometheus监控model_output_kl_divergence告警，线上softmax(output)的KL散度达0.8（基线为0.05）。
排查步骤：
- 确认输入一致性：用
tritonclient抓取线上请求的原始输入tensor，保存为online_input.npy；用相同数据在本地复现离线推理，保存为offline_input.npy。np.allclose(online_input, offline_input)返回True，排除输入问题。 - 检查模型版本：
curl http://triton-service:8000/v2/models/resnet50/versions/1，确认线上加载的是version 1，而非version 2（旧版）。 - 终极杀手锏：TensorRT优化陷阱：Triton启用
--optimization-level=2时，会用TensorRT优化PyTorch模型，但某些算子（如torch.nn.functional.interpolate）的插值模式（bilinearvsnearest）在TensorRT中实现有微小差异。解决方案：在config.pbtxt中添加：
并在模型转换时，显式指定插值模式：optimization [ execution_accelerators [ gpu_execution_accelerator [ name: "tensorrt" parameters: { key: "precision_mode" value: "FP16" } ] ] ]F.interpolate(x, size=(224,224), mode='bilinear', align_corners=False)。
5.4 CI/CD流水线卡死：GitHub Actions的test-modelJob长时间Pending
现象：Job状态一直是Waiting for a runner，GitHub Marketplace显示runner在线。
根因：我们自建的GitHub Runner（EC2实例）磁盘空间不足（/分区98%满），导致Docker无法拉取nvcr.io/nvidia/tritonserver:23.09-py3（镜像约8GB）。
快速诊断：
# 登录Runner EC2 df -h # 发现 /dev/xvda1 98% docker system df -v # 显示 dangling images 占用12GB清理命令：
docker system prune -a -f # 清理所有悬空镜像、容器、网络 journalctl --disk-usage # 查看journal日志占用 journalctl --vacuum-size=500M # 限制日志大小注意：
docker system prune会删除所有未运行容器的镜像，需确保CI/CD流程中docker pull是每次Job都执行，而非依赖本地缓存。
6. 性能压测与稳定性验证：用真实流量说话
6.1 压测方案设计：不只是看QPS，更要测“韧性”
我们用k6（开源负载测试工具）模拟真实场景，而非简单ab压测。测试脚本load-test.js核心逻辑：
import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '30s', target: 100 }, // ramp-up { duration: '5m', target: 1000 }, // steady state { duration: '30s', target: 3000 }, // spike { duration: '2m', target: 0 }, // ramp-down ], }; export default function () { // 1. 先调用Feast获取特征（模拟真实链路） const featureRes = http.post('http://feast-service:8000/get-online-features', JSON.stringify({ features: ['user_age', '7d_avg_transaction_amount'], entity_rows: [{ user_id: 'u123' }] })); // 2. 用特征向量调用Triton（gRPC via HTTP/2） const inputVector = JSON.parse(featureRes.body).features; const tritonRes = http.post('http://triton-service:8000/v2/models/recommender/infer', JSON.stringify({ inputs: [{ name: 'INPUT__0', shape: [1, 100], datatype: 'FP32', data: inputVector }], outputs: [{ name: 'OUTPUT__0' }] })); check(tritonRes, { 'status is 200': (r) => r.status === 200, 'p95 latency < 150ms': (r) => r.timings.p95 < 150, }); sleep(0.1); // 模拟用户思考时间 }压测结果（3节点Triton集群）：
| 指标 | 数值 | 说明 |
|---|---|---|
| 峰值QPS | 2850 | 在3000 QPS压力下，P95延迟突破150ms阈值，故认定2850为安全上限 |
| P95延迟 | 128ms | 稳态1000 QPS下，P95稳定在120~135ms区间 |
| 错误率 | 0.002% | 主要为Feast超时（503），Triton自身错误率为0 |
| GPU利用率 | 85% | 3台g4dn.xlarge（每台1块T4 GPU），平均利用率达85%，未出现瓶颈 |
稳定性验证：连续运行72小时压测，监控kube_pod_container_status_restarts_total（Pod重启次数）为0，nv_gpu_dropped_pending_transactions（GPU丢弃事务）为0，证明服务在长周期高负载下稳定可靠。
6.2 故障注入测试：主动制造混乱，验证系统韧性
用Chaos Mesh（K8s原生混沌工程平台）进行故障演练：
- 网络延迟注入：给
triton-serverPod注入200ms网络延迟，观察上游API网关是否触发熔断（Hystrix配置timeoutInMilliseconds=500），验证降级策略有效性。 - GPU故障注入：
kubectl delete pod -l app=triton-server，强制杀死一个Pod，验证K8s自动重建+Triton热重载是否在10秒内恢复服务（实测8.3秒）。 - 特征服务中断：
kubectl scale deploy feast-server --replicas=0，模拟Feast宕机。此时Triton因无法获取特征，应返回预设错误码（503 Service Unavailable），而非无限等待。我们在API网关层配置了fallback，自动返回缓存特征，保障核心链路可用。
个人体会：混沌工程不是找茬，而是给系统做“压力体检”。我们每月1号固定执行一次全链路混沌演练，已提前发现并修复了7个潜在单点故障。最值得庆幸的是，去年双11零点，Feast Redis主节点因硬件故障宕机，而我们的降级策略（返回缓存特征）自动生效，推荐服务0降级，业务方全程无感知——这正是Part 4想达成的终极目标：让机器学习在真实世界里，像水电一样可靠。
