1. 课程导入
在金融业务场景中，Serving 层承担着实时风控、反欺诈、智能投顾、量化交易信号、信贷审批等关键在线推理任务。一次毫秒级的延迟抖动，可能意味着交易机会的错失；一次模型输出异常，可能直接触发资金损失或合规风险。因此，金融 Serving 的可观测性与故障诊断，不是“运维锦上添花”，而是保障资金安全与业务连续性的核心能力。
本课程面向金融科技工程师、SRE、算法工程与平台研发人员，目标是让你从“能跑通模型服务”进阶到“能看清服务内部、能定位复杂故障、能设计可观测体系”。
一、学习目标：从被动救火到主动洞察
完成本课程后，你应当具备以下四层能力：
- 看得见：为金融 Serving 建立覆盖指标（Metrics）、日志（Logs）、链路追踪（Traces）、事件（Events）与画像（Profiles）的统一观测面。
- 看得准：理解延迟、吞吐、错误率、饱和度、队列深度、批处理大小、GPU 利用率等指标在金融场景下的真实含义与告警阈值。
- 查得快：掌握从告警到根因的标准化诊断路径，能区分模型问题、特征问题、框架问题、资源问题与网络问题。
- 防得住：通过 SLO、错误预算、混沌工程与容量压测，把故障从事后复盘前移到事前预防。
核心价值一句话：金融 Serving 的可观测性，是把“模型上线后不可见的黑盒”变成“可度量、可归因、可回滚、可优化的白盒”，从而降低资金风险与客诉风险。
二、核心原理：可观测性的三根支柱与金融特化
可观测性经典三支柱是 Metrics、Logs、Traces。但在金融 Serving 中，还需要补充两个维度：模型行为观测与业务结果观测。模型行为包括输入特征分布漂移、输出置信度、预测延迟分位、批处理效率；业务结果包括授信通过率、欺诈拦截率、交易转化率、合规拒绝率。
三支柱与两补充的关系可以用下面的 SVG 结构图表示：
这五个维度不是孤立采集，而是通过统一的 TraceID、RequestID、模型版本号、特征版本号进行关联。只有关联，才能从“业务指标异常”一路下钻到“某个特征分片在某个 GPU 上排队超时”。
三、方法流程：故障诊断的标准路径
金融 Serving 故障诊断建议遵循“先止血、再定位、后复盘”的流程：
- 确认影响面：查看业务大盘，判断是全局故障、单模型故障还是单机房故障。
- 检查 SLO：对比错误预算消耗速率，决定是否触发回滚或降级。
- 分层排查：按接入层→特征层→模型层→资源层→依赖层逐层下钻。
- 关联证据：用 TraceID 串联日志与指标，确认根因假设。
- 执行恢复：回滚模型版本、切换特征源、扩容副本或限流降级。
- 沉淀复盘：补充告警、完善看板、增加混沌实验用例。
实战提示：金融场景下，回滚决策往往比根因定位更紧迫。建议提前配置“模型版本一键回滚”和“特征源热切换”能力，把恢复时间控制在分钟级。
四、案例场景：一次典型的线上延迟飙升
某消费金融公司风控模型 Serving 在晚高峰出现 P99 延迟从 80ms 飙升至 1.2s。初步排查发现 GPU 利用率仅 40%，CPU 也不高。通过链路追踪发现，耗时集中在特征获取阶段。进一步查看日志发现，某个外部征信接口超时重试。最终定位为第三方依赖抖动，而非模型本身问题。
# 典型排查命令示例
kubectl top pod -n risk-serving
kubectl logs risk-serving-7d9f8c-abc --since=10m | grep -i "timeout\|retry"
curl -s http://risk-serving:8080/metrics | grep -E "feature_fetch_latency|model_infer_latency"这个案例说明：没有链路追踪，很容易误判为模型或 GPU 问题；有了可观测性，才能快速把矛头指向依赖层。
五、常见误区与复盘要点
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 只看平均值，不看分位数 | 掩盖长尾延迟，金融交易超时被忽略 | 重点监控 P95、P99、P999 |
| 日志没有统一 TraceID | 无法串联请求全链路 | 入口生成 TraceID 并透传 |
| 告警阈值拍脑袋 | 误报多或漏报严重 | 基于历史分位与 SLO 动态设定 |
| 只观测模型，不观测特征 | 特征漂移导致静默故障 | 增加特征分布与缺失率监控 |
| 故障后只修不复盘 | 同类问题反复发生 | 建立故障库与混沌演练 |
特别注意：金融 Serving 的“静默故障”最危险——模型仍在返回结果，但结果已不可信。必须把模型置信度、特征漂移、输出分布纳入可观测范围，而不能只盯着 HTTP 200。
六、整体知识框架与实战路线图
本课程后续将围绕“观测体系搭建→指标与日志实战→链路追踪→故障诊断→混沌工程→复盘与优化”展开。建议学习路径如下：
- 第一阶段：掌握 Metrics、Logs、Traces 采集与关联，完成最小可观测闭环。
- 第二阶段：深入金融场景指标设计，包括延迟分位、批处理、GPU、特征漂移。
- 第三阶段：实战故障诊断，覆盖模型、特征、框架、资源、网络五类根因。
- 第四阶段：通过混沌工程与 SLO 管理，把可观测性转化为稳定性治理能力。
请记住：可观测性不是工具堆砌，而是“用数据回答未知问题”的能力。金融 Serving 的每一次故障，都是一次对观测体系的压力测试。学好本章，你将带着清晰的框架进入后续实战。