实盘工程：执行、监控与故障处理
本课目标：梳理从回测走向实盘的工程差距清单，搭建下单执行、监控告警和故障处理三大模块的基本框架。
回测系统是实验室，实盘系统是生产线。实验室里跑通的东西，放到生产线上会遇到一整类新问题：数据晚到、接口断线、订单部分成交、程序半夜崩溃。实盘工程的目标不是消灭故障——故障一定会发生——而是让每一类故障都有预案、有告警、有兜底。本文讨论工程方法，不构成投资建议。
回测与实盘的差距清单
先把差距列出来，才知道要补什么：
| 维度 | 回测世界 | 实盘世界 |
|---|---|---|
| 数据 | 干净、完整、瞬间可得 | 会迟到、会缺失、会出错 |
| 成交 | 按假设价格全额成交 | 部分成交、滑点、排队不成交 |
| 时间 | 一次性跑完全部历史 | 必须在交易时段内按时完成每一步 |
| 状态 | 无状态，随时重跑 | 有持仓、有在途订单，重启需恢复状态 |
| 错误 | 抛异常就停 | 停下来本身就是风险敞口 |
这张表的每一行都对应一块工程投入。最容易被低估的是最后两行：实盘系统是有状态的长期运行服务，崩溃后如何恢复现场（当前持仓、未完成订单、今日已发信号）必须在设计之初就考虑。一个实用的设计原则是让关键步骤幂等：同一个信号重复执行不会重复下单，重启后重跑当日流程能得到一致的结果。做到这一点，大部分”崩溃后不敢重启”的恐惧都会消失。
国内实盘通道概览
个人和小团队做 A 股程序化，常见的通道大致几类：券商提供的量化终端（如 QMT、PTrade 等，提供行情、下单接口和策略运行环境）、券商开放的接口服务，以及面向机构的专业交易系统。选择时关心几个维度就够了：
- 接口稳定性与文档质量，是否支持你需要的委托类型；
- 数据推送的及时性，以及历史数据能否满足研究复现；
- 资金门槛、费率，以及合规要求——务必通过正规渠道接入，遵守券商和交易所对程序化交易的报备与管理规定。
通道只是水管，不必神化。真正决定实盘质量的是你自己在水管两端搭的东西：信号生产和执行监控。
下单执行：拆单与限价保护
把一个目标持仓变成一串订单，中间有大量细节。两个最基本的机制：
拆单：大单直接砸进盘口会造成冲击。基本做法是把母单拆成子单，按时间或按成交量比例逐步执行，控制单笔子单占盘口挂单量和近期成交量的比例。
限价保护：永远不要裸发市价单。用”对手价加减若干跳”的限价单代替市价单，既保证大概率成交，又给滑点上了锁。
def make_child_orders(target_qty: int, max_child: int, side: str, ref_price: float, protect_ticks: int = 3, tick: float = 0.01): """把母单拆成子单，并给出限价保护价格""" sign = 1 if side == 'buy' else -1 limit_price = round(ref_price + sign * protect_ticks * tick, 2) qtys = [] remain = target_qty while remain > 0: q = min(max_child, remain) qtys.append({'qty': q, 'limit': limit_price}) remain -= q return qtys在此之上还有两个必答题：子单超时未成交怎么办（撤单重报？追价几次为止？）；尾盘还没完成怎么办（放弃剩余量还是收盘前集中处理）。这些规则要事先写死在代码里，不能留给盘中临时决定。
执行层还有一条常被忽视的原则：执行质量要量化。每天记录每笔成交相对信号价或到达价的滑点，按标的流动性分组统计。只有持续测量，你才知道回测里的成本假设是否贴近现实，也才有依据去改进拆单参数。执行是少数几乎”纯靠工程就能改善收益”的环节，值得投入。
监控告警：四条防线
实盘监控的原则是：每一个环节都假设它会坏，并为它安排一个观察者。至少要覆盖四层：
- 数据监控：行情是否按时到达、时间戳是否连续、关键字段是否出现异常值（如价格为零、成交量倒挂）。数据坏了，后面全错；
- 信号监控：今日信号是否按时生成、信号分布是否偏离历史常态（比如突然要求换手全部持仓，往往是上游数据出错而不是市场机会）；
- 持仓与风险监控：实际持仓与目标持仓的偏差、总敞口、单票集中度是否越界；
- 成交对账：每日收盘后，系统记录的持仓和资金必须与券商结算数据逐笔核对，任何不一致都要当日查明原因。
告警要分级：提示类进日志、异常类发消息、致命类（如持仓对不上、风控线触发）必须打电话或用能把人叫醒的方式。所有告警都要避免”狼来了”——长期误报的告警等于没有告警。
故障演练与手动接管
预案写在纸上没用，要演练。建议定期做几类演习：
- 断线演练：盘中主动切断行情或交易连接，验证系统能否正确暂停、重连后能否恢复状态而不重复下单；
- 脏数据演练：注入一条异常行情，验证数据校验层能否拦截；
- 手动接管演练：假设程序完全不可用，你是否能在几分钟内用券商客户端手工查清当前持仓、撤掉所有在途订单、必要时手工平仓。手动接管的操作步骤应该写成一页纸的清单贴在手边。
另外准备一个”一键停止”开关：立即停止发新单并撤掉全部未成交订单，但不平仓。多数故障场景下，先冻结局面再排查，比慌乱操作好得多。每次真实故障之后，把经过和处理写进故障记录，并检查现有告警为什么没有更早发现它——故障记录积累一年，就是你最贴身的运维手册。
本课小结
- 实盘与回测的核心差距在于：数据会坏、成交不确定、系统有状态、停机本身就是风险；
- 通道选型看稳定性、接口能力与合规，剩下的质量取决于你自己的执行与监控层；
- 下单执行的两块基石是拆单和限价保护，超时与尾盘处理规则必须事先固化；
- 监控覆盖数据、信号、持仓、对账四层，告警分级且严控误报；
- 故障不可避免，可演练的预案和一页纸的手动接管清单是最后防线。
动手练习：为你的策略写一份《手动接管清单》：假设程序在持仓状态下彻底崩溃，列出从”发现故障”到”局面受控”的每一步操作（查持仓、撤单、评估是否平仓、记录现场），然后找一个非交易时段，用模拟环境把整个流程完整走一遍并计时。