10.3 多重应急开关
10.3 多重应急开关
本节摘要：前面所有防线——权限、作用域、决策门——都假设系统在正常运行。应急开关回答相反的问题：系统失控时，怎么用最少的操作把它按住。QuantDinger 提供多重应急开关（官方文档口径为四重，具体名称以官方文档为准），本节按作用范围讲解四类：停新单（最常用、代价最小）、撤单（清掉在途意图）、平仓（了结风险敞口，不可逆性陡增）、断网熔断类（切断整个执行通道）。然后是"谁在什么时候按"：自动触发的条件清单与人工决策矩阵，以及两者如何衔接。最后给出每月一次的一键停单演练方案——开关不演练，等于没有；演练要测的不是"按钮存在"，而是"按下去之后系统行为真的变了"。工具与开关的状态可见性设计，思想上承《Harness 工程：从零打造智能体运行环境》第 04 章《工具系统》。
学习目标
- 描述四类应急开关各自的作用范围与代价梯度。
- 区分自动触发与人工按下两类场景，理解衔接机制。
- 组织每月一次的一键停单演练并留下演练记录。
- 避免两类事故：开关失效未察觉、误触高代价开关。
一、四类开关：作用范围与代价梯度
多重应急开关（文档口径为四重，名称以官方文档为准）按代价从小到大排列：
代价梯度（越往下越重，恢复越难） ① 停新单 ── 不再接受/发出新订单，已有持仓不动 ② 撤单 ── 撤掉所有在途挂单，持仓不动 ③ 平仓 ── 了结风险敞口（主动行为，改变持仓） ④ 断网熔断类 ── 切断执行通道（系统级隔离，最重）
| 开关 | 作用范围 | 按下后 | 适用情形 | 恢复 |
|---|---|---|---|---|
| 停新单 | 新订单流 | 系统保留行情与监控，不再交易 | 数据异常、策略异常、决策门异常 | 低成本，随时 |
| 撤单 | 在途订单 | 未成交挂单全部撤销 | 挂单逻辑失控、重复挂单 | 低成本 |
| 平仓 | 持仓 | 敞口了结 | 风险失控、长期离场决策 | 不可逆：仓位已变 |
| 断网熔断类 | 执行通道 | 系统与交易所通道切断 | 疑似入侵、连环异常、全面事故 | 需人工逐项恢复 |
使用纪律的第一条：从最轻的开始。大多数事故停新单就足够——它保留了全部观察能力，代价最小，而且随时可逆。平仓与断网是重武器，按下前应当已经明确知道"为什么要承受它的代价"。第二条：开关动作必须留痕。谁（或哪个自动条件）在何时按了什么开关、当时系统状态如何，进审计日志——事后复盘的第一份材料就是它。
二、谁在什么时候按：自动与人工
自动触发（系统自判，条件示意，阈值按第 8.3 节口径设定）：
| 条件 | 建议动作 | 说明 |
|---|---|---|
| 订单延迟持续越限 | 停新单+撤单 | 链路异常时挂单最危险 |
| 短时间重复订单 | 停新单 | 重试逻辑失控 |
| 敞口越过硬限 | 停新单，告警 | 收缩交还人工 |
| 对账事故级差异 | 全部四类按序评估 | 第 8.3 节三级事故 |
人工决策（你按下，矩阵承接第 8.3 节）：
| 场景 | 首选开关 | 理由 |
|---|---|---|
| 行情数据异常 | 停新单 | 错误数据上不决策 |
| 决策门服务长时间不可用 | 停新单 | fail-open 的兜底人工版 |
| 出行/生病无法盯盘 | 停新单 | 运维连续性 |
| 确认账户安全事件 | 断网熔断类 | 先隔离再排查 |
衔接机制是设计出来的，不是临场发挥：自动触发只碰轻开关（停新单、撤单），重开关（平仓、断网）永远留给人工——自动平仓在极端行情下的执行质量本身就是不可控的。自动触发后必须告警到人，人工在时限内决定升级还是解除；超时未响应的升级路径也要事先约定（示意做法：停新单告警三十分钟无人响应即自动撤单，具体阈值自行书面约定）。
衔接机制：自动只碰轻开关，重武器留给人工 指标越限 ──▶ 自动触发：停新单(+撤单) ──▶ 告警到人 ──▶ 人工决策 │ ├─ 解除（记录理由） │ ├─ 升级平仓（重武器） │ └─ 升级断网（重武器） └─ 超时未响应 ──▶ 按书面预案自动升级
这张图里最长的那条路——"超时未响应、按预案自动升级"——是最容易被漏设计的分支：它意味着系统在无人在场时也会从轻开关升到重开关，升级到哪一级、以什么节奏升，必须写进预案并演练过，否则它就是一个从未被人审过的自动化决策。
三、每月一次：一键停单演练
开关的最大风险不是"没有"，而是"以为有、用时无"——配置漂移、进程重启、权限变更，任何一项都可能让开关悄悄失效。对策是演练（节奏为示意建议：每月一次）：
| 步骤 | 动作 | 通过标准 |
|---|---|---|
| 1 | 选低峰时段，通知相关方 | 演练窗口成文 |
| 2 | 记录演练前状态（在途订单、策略运行） | 快照留档 |
| 3 | 按下停新单开关 | 操作留痕 |
| 4 | 观察新订单流是否停止 | 订单流归零，行情与监控保留 |
| 5 | 触发一次测试信号 | 确认被拦截而非延迟发出 |
| 6 | 解除开关，观察恢复 | 订单流恢复正常 |
| 7 | 演练记录归档（时间、步骤、异常） | 与上次记录对比无漂移 |
四个要点。第 4 步的"行情与监控保留"与第 5 步的"测试信号被拦截"是演练的核心断言——停新单停的是交易，不是观察；被拦的信号要有明确记录而不是静默消失。第 7 步的对比是演练的长期价值：开关的生效时间、拦截行为若随版本升级缓慢变化，逐月对比是唯一能发现的方式。演练范围建议逐月轮换覆盖：本月停新单，下月撤单与告警链路，平仓与断网类至少每季度在测试网环境走一遍完整流程（呼应第 8.1 节测试网清单第 7 项）。
逐月对比长什么样？两条示意记录：
| 字段 | 第 3 次（上月） | 第 4 次（本月） | 解读 |
|---|---|---|---|
| 按下到订单流归零 | 8 秒 | 35 秒 | 变慢：查生效路径是否有配置漂移 |
| 测试信号 | 被拦截并记录 | 被拦截并记录 | 断言保持 |
| 行情与监控 | 保留 | 保留 | 断言保持 |
| 恢复耗时 | 约 1 分钟 | 约 1 分钟 | 正常 |
第二列到第三列的 8 秒变 35 秒，就是逐月记录的价值所在：单看本月，"35 秒内订单流停止"看起来也正常；对照上月 8 秒，才知道有什么东西变了——可能只是版本升级改变了告警传播路径，也可能是开关绑定悄悄失效了一半。没有逐月记录，这类缓慢漂移永远不会被发现，直到真正的事故把它暴露出来；而那时你缺的不只是开关，还有"它从哪天开始坏"的线索。
四、开关自身的可观测性
开关是系统里少数"不常用但必须可靠"的组件，它自己也要被监控：
| 监控项 | 异常形态 | 动作 |
|---|---|---|
| 开关状态当前值 | 状态与预期不符（如演练后未恢复） | 告警并人工核对 |
| 开关生效延迟 | 按下到订单流实际停止的时间变长 | 排查执行路径 |
| 开关操作日志 | 出现非预期主体操作 | 安全事件，按第 8.3 节事故级处理 |
| 自动触发条件健康 | 触发条件依赖的指标断流 | 告警，条件失效等于开关失明 |
最后一行容易被忽略：自动开关依赖的指标（延迟、敞口）如果本身断流，开关就成了聋子——指标新鲜度纳入第 11 章可观测层后，这里自动受益。
五、常见问题与排查
| 问题 | 排查方向 | 要点 |
|---|---|---|
| 按下停新单后仍有订单发出 | 在途订单与生效延迟 | 区分存量在途与新增，超预期即查开关绑定 |
| 想演练平仓但没有测试网 | 平仓不可逆 | 生产环境永远不"试按"，只做流程推演 |
| 自动触发频繁误动作 | 阈值过敏感 | 回第 8.3 节口径重新标定，不直接关自动 |
| 告警到了但人不在场 | 升级路径 | 书面约定的超时自动升级就是为此设计的 |
| 开关状态显示与实际不符 | 状态同步链路 | 按开关自身可观测性一节的四项排查 |
第一行值得展开：停新单生效后仍看到订单，先别急着判定开关失效——按下那一刻已经在构造或已发出的订单属于存量，会自然走完；判定标准是"按下之后有没有新增订单产生"。区分这两个集合的办法是拿按下时间戳对照订单的创建时间戳，而不是肉眼看着成交列表心慌。真正的新增漏出，按开关失效处理，走上一节监控表的排查路径。
本节要点回顾
- 四类开关代价递增：停新单最轻也最常用，平仓与断网是重武器，从轻开始是纪律。
- 自动触发只碰轻开关并必须告警到人；重开关永远人工，升级路径事先书面约定。
- 演练四断言：订单流归零、观察能力保留、测试信号被拦、恢复正常；逐月记录对比发现漂移。
- 开关自身要被监控：状态、生效延迟、操作日志、触发条件的健康，四项缺一不可。
到此，研究、回测、模拟、实盘、决策门、智能体通道与应急刹车全部就位。最后一章收口生产化：Prometheus 与 Grafana 盯住一切、PostgreSQL 的备份与恢复演练保住一切数据、版本升级先 migration 后起服务，以及多租户 SaaS 能力——把这套系统从"我的工具"变成"可以服务多人的平台"之前，先把它变成"不会弄丢自己的系统"。