10、系统与内部控制：交易系统准入与权限管理、算法交易合规控制、业务连续性计划与灾难恢复
做市商这行，说白了就是跟系统过日子。你策略再牛，模型再准，系统一崩全白搭。我见过太多团队，策略收益漂亮得很，结果一次权限泄露，或者算法失控，直接把利润全吐回去。所以今天咱们聊聊系统与内部控制，这块是合规框架的「地基」。
10.1 交易系统准入与权限管理
权限管理这事儿，我个人的习惯是「最小够用原则」。什么意思？就是每个角色、每个账户，只给完成工作所必需的最小权限。多一点都不行。
举个例子。交易员A负责做市BTC永续合约，那他就不该有修改风控参数的权限。风控经理需要查看所有交易员的敞口，但他不应该能下单。这些听起来简单，实际执行起来，坑不少。
- 职责分离：交易、风控、结算、系统管理，四个角色必须分开。不能同一个人既下单又审核订单。
- 最小权限：每个账户只给当前任务所需权限，用完即收回。
- 定期审计：每季度至少做一次权限盘点，看看有没有「僵尸账户」或者权限越级的情况。
我曾经遇到过一个案例。某家做市商，因为系统管理员离职后权限没及时回收，结果被外部攻击者利用，直接修改了交易参数。虽然没造成实际损失，但合规检查时被罚了一笔。嗯，从那以后，我每次做系统准入设计，都会加一条：离职权限必须在24小时内完成回收。
权限管理的技术实现，我建议用基于角色的访问控制（RBAC）模型。简单说，就是先定义角色，再把权限挂到角色上，最后把用户分配到角色。这样管理起来清晰，审计也方便。
# 伪代码示例：RBAC权限检查
def check_permission(user, action, resource):
role = get_user_role(user) # 获取用户角色
permissions = get_role_permissions(role) # 获取角色权限列表
if (action, resource) in permissions:
return True
else:
log_audit(user, action, resource, "DENIED")
return False
10.2 算法交易合规控制
算法交易是做市商的核心竞争力，但也是风险高发区。你想想看，一个高频算法跑起来，每秒可能发几百笔订单。一旦逻辑出问题，或者市场环境突变，后果不堪设想。
所以，算法交易必须加「缰绳」。我把它总结为三个关键控制点：杀单机制、最大订单量限制、价格偏离保护。
10.2.1 杀单机制（Kill Switch）
杀单机制，说白了就是一个「紧急停止按钮」。当算法行为异常时，能立刻切断所有订单流。我个人习惯设计两级杀单：
- 手动杀单：交易员或风控经理，在监控界面点击「紧急停止」按钮。这个按钮必须醒目，而且响应时间不能超过100毫秒。
- 自动杀单：系统检测到异常指标（如订单撤销率超过阈值、持仓量突变、连续亏损等），自动触发杀单。
我曾经在实盘环境中遇到过算法因为数据源故障，开始疯狂下单。幸好自动杀单机制在3秒内检测到订单撤销率从正常值飙到80%，直接切断了所有交易。那次要是晚10秒，损失可能就上百万了。
10.2.2 最大订单量限制
这个很好理解。就是给每个算法、每个交易员、每个交易对，设定一个最大订单量。超过这个量，系统直接拒绝。
我建议设置三个维度的限制：
| 维度 | 说明 | 示例值 |
|---|---|---|
| 单笔订单量 | 单次下单的最大数量 | BTC: 10张 |
| 累计订单量 | 单位时间内（如1分钟）累计下单总量 | 100张/分钟 |
| 持仓量 | 单个交易对的最大净持仓 | 500张 |
这些限制值不是拍脑袋定的。我一般会基于历史交易数据和压力测试结果来设定。比如，先跑一个月的历史回测，看看正常情况下的订单量分布，然后取99.5%分位数作为阈值。这样既能覆盖正常交易，又能拦住极端情况。
10.2.3 价格偏离保护
算法交易最怕什么？怕「胖手指」或者「市场闪崩」。价格偏离保护就是防止算法以离谱的价格成交。
具体做法：系统实时计算当前市场合理价格（比如取买一卖一价的中位数），然后设定一个偏离百分比。如果算法提交的订单价格偏离合理价格超过这个百分比，系统直接拒绝。
# 价格偏离检查示例
def check_price_deviation(order_price, market_price, max_deviation_pct):
deviation = abs(order_price - market_price) / market_price
if deviation > max_deviation_pct:
log_alert(f"价格偏离过大: {deviation:.2%}")
return False # 拒绝订单
return True
10.3 业务连续性计划（BCP）与灾难恢复（DR）
做市商是7x24小时运行的。系统不能停，停了就是真金白银的损失。所以BCP和DR不是「锦上添花」，而是「雪中送炭」。
我习惯把BCP和DR分开理解：
- BCP：业务怎么在中断后继续运行。比如机房断电了，交易员能不能在家办公？
- DR：系统怎么从灾难中恢复。比如服务器被攻击了，数据能不能恢复？
10.3.1 关键设计原则
做BCP/DR设计，我遵循三个原则：
- 冗余：所有关键组件都要有备份。服务器、网络、数据库、甚至交易员。我记得有一次，某家做市商的主交易员突然生病，结果没人能操作备用系统，导致当天交易暂停。这就是「人员冗余」没做好。
- 异地：主备机房必须物理隔离。最好在不同城市，甚至不同国家。这样即使一个机房遭遇自然灾害，另一个还能正常运行。
- 定期演练：BCP/DR计划不能只写在文档里。每季度至少做一次演练，模拟各种灾难场景。我见过最离谱的案例，某公司DR计划写了100页，结果演练时发现备份数据根本恢复不了——因为备份脚本早就坏了。
10.3.2 恢复时间目标（RTO）与恢复点目标（RPO）
这两个指标是BCP/DR的核心。简单说：
- RTO：系统从故障到恢复，最多能停多久？
- RPO：数据最多能丢多少？
对于做市商，我建议的指标如下：
| 系统类型 | RTO | RPO | 说明 |
|---|---|---|---|
| 交易系统 | < 1分钟 | 0（零数据丢失） | 交易系统不能停，数据不能丢 |
| 风控系统 | < 5分钟 | < 1秒 | 风控可以短暂中断，但数据要实时同步 |
| 结算系统 | < 1小时 | < 1分钟 | 结算可以晚一点，但数据不能丢太多 |
要达到RTO小于1分钟，必须用「主-主」或者「主-备」热切换架构。说白了，就是备用系统时刻在线，主系统一挂，流量立刻切过去。用户几乎无感知。
10.3.3 演练与持续改进
BCP/DR不是一次性工程。我每季度都会组织一次「红蓝对抗」演练。红队模拟攻击或故障，蓝队负责恢复。演练结束后，必须出报告，列出改进项。
- 主数据中心断电
- 网络攻击导致交易系统不可用
- 数据库损坏或数据被篡改
- 关键人员失联（如交易员、系统管理员）
每次演练，我都会发现一些「意外」。比如有一次，演练时发现备用系统的时钟没同步，导致订单时间戳错乱。还有一次，发现备份数据虽然恢复了，但权限配置没同步，导致交易员登录不了。这些细节，不演练根本发现不了。
10.4 本章小结
系统与内部控制，听起来枯燥，但它是做市商的生命线。权限管理管住「人」，算法合规管住「策略」，BCP/DR管住「系统」。三者缺一不可。
我见过太多团队，把精力全放在策略优化上，忽略了系统建设。结果一次小故障，就把几个月的利润全赔进去。所以，别嫌麻烦，把这些基础工作做扎实了，你才能安心做交易。
无相订单流研究社 微信Lucian808555