4. 操作风险：系统故障、网络延迟、人为误操作、API接口异常
操作风险，说白了就是「人」和「系统」带来的不确定性。做市商这个行当，你想想看，每天处理几百万笔订单，毫秒级的竞争环境，任何一个环节出问题，都可能造成真金白银的损失。我个人习惯把操作风险分成四类：系统故障、网络延迟、人为误操作、API接口异常。咱们一个一个聊。
4.1 系统故障：你的交易引擎会「死」吗？
系统故障是最直接的风险。服务器宕机、数据库崩溃、内存泄漏、磁盘写满……我在项目中遇到过最离谱的一次，是某个交易所的行情推送模块因为日志文件把磁盘撑爆了，导致整个做市策略停了整整三分钟。三分钟，在加密货币市场里，足够让价差从0.1%变成5%。
怎么防？核心思路就四个字：冗余 + 隔离。
系统故障防护要点：
- 多活部署：至少两个数据中心，主备切换时间控制在1秒以内。我建议用Keepalived + HAProxy做TCP层的健康检查和自动切换。
- 进程级隔离：行情接收、策略计算、订单发送、风控检查，这四个模块必须跑在不同的进程里。一个挂了，不能影响其他。
- 资源监控：CPU、内存、磁盘、网络IO，全部打点上报。阈值告警要提前设好，比如磁盘使用率超过80%就发警报。
- 熔断机制：如果某个模块连续失败超过N次，自动熔断，不再发送新订单。等人工确认后再恢复。
嗯，这里要注意：熔断不是让你永远停掉策略。它只是给你争取一个「冷静期」。我曾经见过一个团队，熔断触发后没人管，结果错过了整个交易日的行情。
4.2 网络延迟：毫秒级的生死线
做市商赚的是什么？说白了就是「速度差价」。你的订单比别人慢1毫秒，可能就吃不到单了。网络延迟的风险，不只是「慢」，还有「抖动」——忽快忽慢的延迟才是最要命的。
为什么会这样？因为网络路径上任何一个节点出问题，比如交换机缓存溢出、光纤被挖断、DNS解析超时，都会导致延迟飙升。我在项目中遇到过，某个交易所的API服务器突然从1ms延迟变成200ms，持续了30秒。那30秒里，我们的报价全部成了「废单」。
我的网络延迟优化清单：
- 同机房托管：把服务器放在交易所的机房里，物理距离最短。这是最直接的办法。
- 专线连接：别走公网。公网延迟不稳定，专线虽然贵，但值得。
- UDP vs TCP：行情数据用UDP，订单数据用TCP。UDP丢包可以重传，但TCP的拥塞控制会带来额外延迟。
- 延迟监控：每个交易所、每个API端点的延迟都要打点。我习惯用百分位统计，P99超过50ms就告警。
你想想看，如果延迟监控发现某个交易所的P99延迟从10ms涨到了100ms，你会怎么做？我建议立即降低该交易所的报价权重，甚至暂停交易。等延迟恢复正常再恢复。
4.3 人为误操作：最防不胜防的风险
系统可以自动化，但人总是会犯错。我记得有一次，一个同事在配置文件中把「最小下单数量」写成了「最大下单数量」，结果策略直接下了1000个比特币的买单。还好风控系统在订单发送前拦截了，不然……嗯，后果不敢想。
人为误操作的类型很多：参数配错、脚本跑错环境、误删数据库、忘记更新API密钥……怎么防？核心是「权限最小化」和「操作可追溯」。
人为误操作防护三板斧：
- 操作审批流：任何配置修改、参数调整、策略上线，都必须经过二级审批。不能一个人说了算。
- 沙箱环境：所有变更先在沙箱里跑一遍，确认没问题再上生产。沙箱的数据要和生产隔离。
- 操作日志：谁、什么时间、改了哪个参数、改之前是什么值、改之后是什么值，全部记录。出了问题能回溯。
我曾经见过一个团队，因为操作日志没开，出了事故后根本查不到是谁改的配置。最后只能全员背锅。所以，日志不是用来「看」的，是用来「查」的。
4.4 API接口异常：交易所也会「抽风」
做市商依赖交易所的API。但交易所的API并不总是可靠的。常见的API异常包括：限频（Rate Limit）、返回错误码、数据格式变化、甚至直接断连。
我记得有一次，某个交易所突然改了订单返回的JSON字段名，从「order_id」改成了「id」。我们的解析代码没跟上，结果所有订单状态都解析失败，策略以为订单全被取消了，又重新下了大量重复单……那叫一个乱。
API异常处理策略：
- 限频管理：每个API的调用频率要严格控制。我习惯用令牌桶算法，每秒最多N次请求，超过就排队或丢弃。
- 错误码分类处理：不同的错误码要有不同的处理逻辑。比如「429 Too Many Requests」就降频重试，「503 Service Unavailable」就暂停交易。
- 数据格式校验：每次API返回的数据，都要做字段存在性和类型校验。发现异常立即告警，并暂停该交易所的交易。
- 心跳检测：每隔几秒发一个ping请求，如果连续几次没响应，就认为该交易所失联，自动切换到备用交易所。
你想想看，如果API返回的数据里突然多了一个字段，或者少了一个字段，你的解析代码能处理吗？我建议所有API解析都用「宽松模式」——遇到未知字段就忽略，遇到缺失字段就报错并告警。
4.5 操作风险的整体框架
说了这么多，咱们用一张图来总结操作风险的防护体系。这张图是我自己画的一个框架，核心逻辑是「预防 -> 检测 -> 响应 -> 恢复」四个阶段。
这张图里，预防阶段做的是「别让问题发生」，检测阶段是「出了问题要知道」，响应阶段是「快速止血」，恢复阶段是「回到正常状态」。四个阶段缺一不可。
我的个人习惯：每周做一次操作风险演练。模拟系统故障、网络延迟、API异常等场景，看看团队能不能在5分钟内响应。第一次演练的时候，我们花了15分钟才找到问题根源。练了三个月后，缩短到了2分钟。嗯，熟能生巧。
操作风险不像市场风险那样可以用模型量化，但它造成的损失往往更直接。我见过太多团队，技术很牛，策略很赚钱，最后栽在「一个配置参数写错了」这种小问题上。所以，别忽视操作风险。它不性感，但它能要命。