🔐 灾备与安全:密钥、权限与审计

技术故障的逐项预案表(检测→响应→恢复)、交易安全的四道门(密钥/权限/审计/对账)、个人的灾备底线清单——量化系统的「不猝死」工程。

量化系统的两类致命故障:技术性猝死(进程崩溃、断网、机房故障——持仓无人管理)与安全性事故(密钥泄露、误操作、账实不符——损失直接且难追回)。本篇按「故障模式 → 预案」的结构给出「不猝死」的工程清单。

技术灾备:故障模式清单

逐项预案化(每项都要有「检测 → 自动/手动响应 → 恢复」三步):

故障检测响应预案
策略进程崩溃心跳超时(见日志监控 )自动重启 + 状态恢复(从账本重建持仓);重启失败 → Kill Switch + 电话
行情断流最后 tick 时间戳超时切备用行情源(主备双源是底配);全断 → 撤全部未成交委托 + 冻结新单(用旧价格下单是重大事故源)
券商通道故障委托回报超时/废单率激增切备用券商通道;同时段禁止「盲目重发订单」(重复下单比不下单更糟)——每笔订单带唯一 ID,重发前先查单
服务器/机房故障健康检查云上双可用区部署;个人至少「本地 + 云端应急脚本」(云端能执行撤单与平仓清单)
数据错误(上游污染)质量校验(见数据清洗 )短路流水线 + 冻结交易——「宁可停一天」写进制度

每一条都对应真实事故的形态:行情断流时「用最后一条行情继续发单」的僵尸策略、通道故障后盲目重发导致的双倍持仓、上游数据污染引发的连环错误交易——每一种都比「不下单」贵得多。

演练是灾备的灵魂:每季度一次「故障演习」(拔网线、杀进程、停行情源,验证自动响应与人工流程)——没演练过的预案在真故障时的可用性接近于零(与 Kill Switch 的演练纪律同源,见事中风控 )。

备份的最小集:每日收盘后备份「账本 + 配置 + 因子库 + 代码仓库」四件套到独立介质——账本(订单、成交、持仓、资金)是法律与对账的根基,优先级最高(3-2-1 原则:三份副本、两种介质、一份异地)。

交易安全:四道门

① 密钥管理

  • 密钥不入仓库(API key、券商密码、数据商账号——.gitignore 的第一行,见Git );环境变量或加密配置注入,不写在代码里;
  • 最小权限:下单 API 密钥尽量申请「只交易不提现」权限(多数券商 API 天然无提现能力,这是结构性的安全垫);交易密钥与查询密钥分开;
  • 定期轮换:每季度轮换交易密钥;员工离职即作废全部权限(机构场景);
  • 泄露即作废:任何疑似泄露(误提交、日志打印、截图外发)——立即作废重置,不要抱侥幸。判断标准不是「有没有人真的看到」,而是「有没有可能被看到」。

② 权限分离

个人量化的最低形态也适用:「看」与「动」分离——日常监控仪表盘只读;下单操作走独立通道(且加二次确认);风控参数的修改与策略代码的部署用不同的 git 权限/审批。机构版再加:交易员与风控的物理权限分离(风控能 Kill 却不能下单,见角色分工 )。

③ 审计日志

每一笔交易决策都要能回答「谁、何时、依据什么信息、经过什么审批」:订单全生命周期日志(信号版本、风控检查结果、人工干预记录)不可篡改地留存(append-only + 定期归档异地)。它的用途是三重的:监管合规(机构刚需,程序化报备时代尤其如此)、纠纷仲裁(「那天为什么买了它」)、事故复盘(见事后风控 )。个人版的最小实现:结构化日志 + 每日快照上传云端——「不留痕的操作不做」应该成为肌肉记忆。

④ 对账(Reconciliation)

账实相符是安全体系的最终裁判:每日收盘后三方对账——本地账本 vs 券商对账单 vs 交易所结算数据。任何差异(哪怕一分钱)当日排查。对账能抓住的安全问题:误下单、重复下单、未预期的持仓变动、甚至盗用——它是最朴素也是最可靠的最后防线(对账流水线接入 DAG,见调度 )。一个实操细节:对账脚本发现的差异要分档(金额差异 vs 数量差异 vs 持仓差异),持仓差异(券商有仓、本地无记录)优先级最高——那可能是账户被盗用的信号。

个人的灾备底线(一小时能建完)

  1. 云端应急脚本:能查持仓、能撤全部委托、能按清单平仓(存在手机可达的地方);
  2. 券商手机 App 保持登录可用(终极后备通道);
  3. 每日自动备份账本与配置到云盘;
  4. 一张纸写清「系统挂了的三步流程」贴在墙上(慌乱时的执行靠的是预写好的清单,不是聪明)。

关联阅读:故障的检测机制日志与监控 ;Kill Switch 的工程事中风控 ;事故的复盘方法事后风控 。