生产环境中的 Algo 策略监控与异常处理

一个实盘 algo 的评判标准是出问题时它怎么做，不是一切正常时它怎么做。监控不是仪表盘——它是对特定故障条件的自动响应集合，每个条件有阈值和定义好的动作。

四层监控

1. 基础设施。 CPU、内存、磁盘、网络、时钟漂移。NTP 漂移超 50ms、内存占用超 80%、任一阶段心跳停 30 秒，告警。动作：呼叫运维并冻结新单。

2. 连接性。 券商 websocket、REST 延迟、订单回执时间。websocket 静默 10 秒、REST 往返超滚动中位数 2 倍、订单回执超 5 秒，告警。动作：撤挂单、停提交。

3. 策略行为。 滚动 Sharpe、相对预期的滑点、成交率、拒单率。滚动 50 笔 Sharpe 跌破 0、实现滑点超回测 2 倍、拒单率超 5%，告警。动作：仓位减半等审查。

4. 盈亏。 实现的日盈亏和从峰值起的回撤。日亏到 2%（警告）、3%（停新入场）、5%（全平）。这些是硬限，不是软警告。

错误分类

每个异常都要归到四类之一：

• 瞬时（网络抖动、限频）：退避重试，30 秒内最多 3 次。
• 数据质量（缺口、陈旧报价、坏 tick）：跳过信号、记日志、继续。永远别在脏数据上交易。
• 订单拒单（保证金不足、精度）：记下券商消息、修单、别盲重试。
• 未知：停。你没分类过的错误，是你无法安全恢复的错误。

熔断开关层级

三级，严重程度递增：

1. 软熔断：停新入场，让现有仓位跑到目标。用于策略级异常。
2. 硬熔断：撤所有挂单，不平仓。用于连接或数据问题。
3. 全平：撤单并市价平掉所有仓位。用于基础设施故障或盈亏越线。把它绑到一个看门狗上——主进程 30 秒无响应就触发。一个卡死的 bot 比没 bot 更危险。

恢复流程

任何停机后，别自动恢复。跑手动检查清单：

• 把券商持仓和内部状态对账。
• 确认原因是修好了，不是暂时消失。
• 在 paper 模式下重启 30 分钟。
• 第一个交易日回缩到 25% 仓位。

该记什么

每笔订单：时间戳、意图动作、券商回执、成交价、相对信号价的滑点。每个异常：类型、上下文、采取的动作、解决。没这本日志，事后复盘就是猜，下个月同一个 bug 还会回来。

被监控的 algo 失败得安全。不被监控的 algo 失败得灾难性。那 50 行告警代码是系统里最便宜的保险。