核心监控指标体系设计
做市业务监控，说白了就是盯住几个关键数字。我做了这么多年量化系统，见过太多团队一上来就搞几百个指标，结果真正出问题时反而抓不住重点。今天咱们就聊聊最核心的四个维度：延迟、吞吐量、资金利用率、报价质量。
一、延迟指标：Tick-to-Trade 与 Order-to-Fill
延迟是做市商的命根子。你想想看，行情比别人慢1毫秒，报价就可能被套利者吃掉。我个人习惯把延迟拆成两段来看：
1. Tick-to-Trade（行情到交易）
这个指标衡量的是：从交易所行情Tick到达，到我们的交易系统发出订单，一共花了多少时间。我曾在项目中遇到过，某家交易所的行情推送偶尔会延迟50ms，但我们的系统没做检测，结果那段时间亏损惨重。
核心公式：
T2T = T_order_sent - T_tick_received单位：微秒（μs）或毫秒（ms）
这里要注意，Tick-to-Trade不是越短越好。我见过有人把系统优化到10微秒，但忽略了风控检查，结果一笔错单把一个月利润都赔进去了。嗯，平衡很重要。
2. Order-to-Fill（订单到成交）
这个指标更贴近实际交易体验。它衡量的是：订单发出去之后，到收到成交回报，一共花了多久。
避坑指南：我曾经以为Order-to-Fill只跟交易所速度有关，后来发现网络路径、网关处理、甚至操作系统内核参数都会影响。有一次排查了三天，最后发现是网卡的RSS队列没配置好。
| 延迟类型 | 正常范围 | 警戒线 | 故障线 |
|---|---|---|---|
| Tick-to-Trade | < 100μs | > 500μs | > 1ms |
| Order-to-Fill | < 1ms | > 5ms | > 20ms |
二、吞吐量指标
吞吐量说白了就是系统能扛多少活。做市业务有个特点：平时风平浪静，一旦行情波动，订单量可能瞬间暴涨10倍。我建议重点监控两个维度：
- 订单处理吞吐量：每秒能处理多少笔订单（含撤单）
- 行情处理吞吐量：每秒能处理多少笔行情Tick
我的经验：吞吐量监控不能只看平均值。有一次系统平均每秒处理5000笔订单，看起来很稳，但峰值到了8000笔时，队列直接打爆了。后来我加了个P99.9的监控，才真正发现问题。
为什么会这样？因为做市系统的订单到达是突发性的。你想想看，一个重大新闻出来，所有做市商同时调整报价，那瞬间的流量是平时的几十倍。
三、资金利用率指标
这个指标很多人容易忽略。做市业务本质上是资金生意，资金利用率直接决定了收益率。我习惯看三个子指标：
- 资金占用率：当前占用资金 / 总可用资金
- 资金周转率：日交易额 / 平均占用资金
- 资金成本率：融资成本 / 占用资金
核心公式：
资金利用率 = (年化收益 - 资金成本) / 平均占用资金我记得有个团队，策略收益很高，但资金利用率只有30%。说白了就是钱闲着，没发挥最大价值。后来他们优化了资金调度，收益率直接翻倍。
四、报价质量指标
报价质量是做市商的招牌。我见过太多团队只盯着延迟和吞吐量，结果报价质量一塌糊涂。这里有几个关键指标：
| 指标名称 | 说明 | 健康值 |
|---|---|---|
| 报价价差 | 买卖报价之间的差值 | 不超过市场平均价差的1.5倍 |
| 报价深度 | 各档位挂单数量 | 前3档合计不低于基准量 |
| 报价更新频率 | 每秒更新报价次数 | 不低于行情更新频率 |
| 报价偏离度 | 报价与市场公允价格的偏差 | < 0.1% |
我曾经踩过的坑：报价质量监控不能只看平均值。有一次我们的报价价差看起来很正常，但仔细一查，发现某个交易对的报价深度只有正常水平的10%。结果一个大单过来，直接把我们打穿了。从那以后，我要求每个交易对都要单独监控报价质量。
核心监控体系总览
说了这么多，咱们用一张图来总结一下。这张图展示了四个核心指标维度的关系：
这四个指标不是孤立的。延迟高了，报价质量就会下降；吞吐量不够，资金利用率就上不去。我建议团队在搭建监控系统时，先把这四个维度的基础指标跑起来，再逐步细化。
最后说一句：指标不是越多越好。我见过最成功的做市团队，核心监控面板上就不到20个指标。关键是每个指标都要有明确的阈值和告警策略。嗯，今天就聊到这里，下一章咱们聊聊具体的监控系统架构设计。