生产系统与运维 on 云栖

量化系统架构：研究层、数据层与交易层

Mon, 01 Jan 0001 00:00:00 +0000

策略代码只占量化系统的 20%——剩下 80% 是让研究可持续、交易可信赖的基础设施。本篇讲架构的两个根本决策：研究与生产怎么分离、系统怎么分层，以及单体/微服务的务实选型。

第一原则：研究环境与生产环境的分离

研究环境：交互式（Notebook）、数据宽松（可以全量拉取）、允许试错、性能不重要。生产环境：无人值守、数据严格（只走校验过的管道）、拒绝意外（任何变更走发布流程）、可靠性至上。

两者隔离的原因不是洁癖，而是保护研究结论的可信度与生产系统的稳定性：研究代码直接连生产数据库 → 一次探索性的重查询拖垮生产；生产逻辑随手改 → 回测环境与实盘环境漂移，「回测通过」失去意义。连接两个世界的唯一通道是「发布流程」：研究代码 → 代码审查 + 回测复核 → 打版本 → 部署到生产（流程见策略上线）。

环境一致性的三个保证：依赖锁定（同一份 lock 文件，见代码质量）、同一因子代码（研究与回测共用实现，禁止「研究版重写一遍」）、数据快照版本（回测引用的数据版本在生产可追溯，见因子存储）。

三层架构：数据层、研究层、交易层

数据层（完整设计见因子存储与调度）：核心 SLA 是「17:00 前完成当日数据落地与质量校验」——它是全系统的时间锚点，迟到会连锁推迟信号、调仓与监控。数据层的事故是全系统事故之母：一条复权因子错误会让所有量价因子、所有策略同时出错，且难以追溯——所以数据层的质量检查投入产出比最高。

研究层：重点不是算力而是可复现性——每个实验可追溯到代码版本 + 数据版本 + 参数；算力按需加（向量化因子计算用不了多少），管理不当的研究环境才是时间黑洞。研究层的常见病不是「算力不够」而是「实验不可考」：跑过 200 个实验却说不清哪个对应哪份代码哪份数据——实验登记表 + manifest 是解药。

交易层的关键设计：信号服务与执行服务的解耦——信号服务输出「目标组合」（策略逻辑），执行服务负责「从当前持仓到目标组合」（下单、拆单、重试）。解耦的好处：换券商只改执行层；同一策略换执行算法不用动信号代码；风控检查插在两层之间天然清晰（限额校验作用于「订单流」而不是「目标权重」）。

微服务 vs 单体：诚实的选型

微服务的适用条件：多团队并行开发（模块边界 = 团队边界才有效）、不同模块的伸缩/部署节奏差异大（信号服务日频部署、行情网关毫秒级稳定性）、故障隔离要求高（执行故障不能拖垮监控）。

单体的适用条件：1–3 人团队、策略数少、变更频率低——一个「模块化单体」（清晰的目录结构 + 接口分离 + 单进程内分模块）的运维成本是微服务的十分之一。

最常见的错误是反过来：个人研究者搭了一个五节点的「分布式量化平台」，然后花 80% 时间修基础设施、20% 时间研究——架构复杂度必须与研究规模匹配（第 04 章因子库的同款元原则）。个人量化的推荐形态：一个进程内的模块化单体（数据/策略/执行/风控四模块）+ cron 调度 + 外部推送告警，见学习路径的工程极简版。

演进路径：什么时候升级架构

触发升级的信号（对应升级动作）：

因子数 > 50 或计算时长影响决策 → 数据层独立 + 增量计算（见调度与数据库）；
策略数 > 3 且共享标的池 → 信号/执行解耦 + 子账户记账（见多策略）；
出现第一次「生产事故找不到原因」 → 结构化日志与监控先行补课（见日志与监控）——监控比任何架构升级都优先；
团队 > 5 人 → 模块边界正式化（接口契约 + 独立部署），此时微服务才开始划算。

反向的忠告同样重要：如果上面四条信号一个都没出现，你现在的「简陋」架构就是最优架构——为不存在的规模设计系统，是把研究时间兑换成工程快感的慢性手术。

关联阅读：各层的工程细节调度与数据库、DevOps ；交易层的执行引擎执行算法；可靠性的底线灾备与安全。

策略上线流程：审查、仿真、灰度与回滚

Mon, 01 Jan 0001 00:00:00 +0000

「回测通过」与「可以上实盘」之间隔着四道关卡，每道都在过滤一类回测看不见的风险。跳关的个人量化者与跳关的机构一样多，后果也一样。

关卡一：代码审查与回测复核

审查的重点不是代码风格（那是 CI 的事），而是策略逻辑的三类高危错误：

前视与时序错误：信号时间协议逐行核（T 信号 → T+1 成交）；财报数据的公告日对齐（见数据清洗）——研究代码里「顺手」写的对齐，上线后就是前视偏差的实弹；
口径漂移：研究时的因子实现 vs 上线时的实现必须同一份代码（禁止重写，见架构）；参数从研究配置到生产配置的搬运要有 diff 审查（参数抄错是最经典的上线事故）；
边界与异常路径：停牌/涨跌停/资金不足/数据缺失时策略的行为——研究回测里没触发的分支，实盘总会触发（Murphy 定律的量化版）。

回测复核（独立复现）：由另一个人/另一套代码（至少另一份配置）从原始数据重跑该策略——结果与研究报告的偏差 > 阈值（如年化 ±2%）即打回。它防的是「研究不可复现」与「报告选择性展示」——这是机构投研流程里最值得个人借鉴的一道闸（个人版：一个月后自己换个环境盲重跑一次）。

关卡二：仿真盘（Paper Trading）

定义：用真实行情、真实信号逻辑生成交易，但不下单（或下单到模拟账户）——它是「策略在当下的真实世界里会怎么做」的实时预演。

仿真要验证的三件事：

工程正确性：数据管道、信号生成、目标组合的生成是否每日准点无误——回测里不存在的「运维正确性」只有仿真能测（见日志与监控）；
信号的当下有效性：策略逻辑在最近（未参与研究的）市场里是否仍然成立——防「回测过拟合 + 市场已变」的双重风险；
预测的实现路径：仿真记录「目标持仓 → 假设成交价」，与未来的真实执行对照，校准执行假设（见TCA ）。

时长与通过标准要预注册（防「跑两周感觉不错就上」）：常规建议 4–8 周（≥ 20 个调仓截面），通过标准含工程可用率（> 99%）与信号质量（滚动 IC 不低于历史 25 分位，见因子库的监控口径）。

仿真的固有局限要心里有数：无真实冲击（你的仿真成交价不含自己的市场影响）、无成交失败（限价单仿真里常「理想成交」）、无资金交互（保证金、T+1 资金链）——这些缺口正是关卡三要补的。

关卡三：灰度与逐步放量

阶梯设计（以目标资金为 100%）：

1
2
3


10%（2–4 周）→ 30%（2–4 周）→ 60% → 100%
每级升级条件：该级绩效 vs 预期偏差 < 阈值 && 执行指标（滑点、成交率）达标 && 无风控违规
每级降级条件：偏差超阈值 → 停在该级排查；触发熔断 → 退回上一级（见[事中风控](/quant/real-time-risk/)）

灰度期重点观察的三组对照：

实盘 vs 仿真：缺口应主要来自执行成本（可解释）——缺口不可解释 = 有东西在仿真里是假的；
实盘 vs 回测同期：分年度式的小段对照，超额衰减在预期范围内（30%–50% 的衰减是常态，见回测偏差）；
执行指标趋势：滑点随规模放大 vs 容量曲线的预测（见再平衡与容量）——放量到某级滑点突增 = 摸到容量边界。

灰度的心理纪律：每一级的停留时间按预注册的日历执行，不因「跑得好」提前升级（好绩效可能是运气，灰度期本就不该按绩效决策）——这条被违反的概率超过 90%，违反的代价在下一轮回撤时结算。

关卡四：回滚预案

上线那天就要能回答：「如果下个月要撤下这个策略，需要几步、多久、会遗留什么？」

版本回滚：策略代码/参数/因子版本的三位一体快照（git tag + 配置快照 + 因子库版本号），回滚 = 恢复快照 + 重建持仓对齐（见Git ）；
持仓清算预案：下线时的清仓计划（分几天、按什么流动性约束、对市场的冲击预估）——大资金策略的「退出成本」必须在上线前算过（清仓冲击的估算同流动性分析）；
依赖解耦：策略下线不能拖垮共享基础设施（数据管道、监控、其他策略的因子库）——下线清单里逐项核对共享依赖。

关联阅读：上线的架构前提系统架构；上线后的持续保障灾备与安全；灰度期的实验方法论实验设计与 A/B 。

任务调度与时序数据库

Mon, 01 Jan 0001 00:00:00 +0000

量化系统的每日运转是一条定时流水线：行情落地 → 校验 → 因子计算 → 信号 → 订单 → 归档。「几点跑什么」的可靠性直接等于策略的可靠性——本篇讲流水线的组织方式（调度）与底下的存储选型（数据库）。

调度：从 cron 到 DAG

cron 的问题：用「猜时间」表达依赖——「17:05 跑因子计算」隐含假设「数据 17:00 前一定就绪」，一旦数据迟到，因子计算用的是残缺数据（且无人知晓）。DAG 调度（Airflow/Prefect/Dagster）的正确姿势：声明依赖而不是猜时间——

1
2


# Airflow 风格的依赖声明（伪代码）
data_landing >> data_quality_check >> factor_compute >> signal_gen >> orders

每个任务的触发条件是「上游任务成功」，而不是「到了某个钟点」。数据的迟到不再是事故（流水线自动顺延），而是可告警的异常（SLA 超时告警，见日志与监控）。

DAG 的四个实务要点：

每个任务幂等且可重跑：任务失败重跑不能产生重复数据（写临时表 + 原子切换，见因子存储）——幂等是「放心重跑」的前提，而重跑是流水线的日常；
质量校验是 DAG 的显式节点：校验失败 → 下游全部短路 + 告警——「宁可今天不交易，不可用坏数据交易」（检查项见数据清洗）；
回填（backfill）是一等公民：数据源修复后「重算某区间的因子」是高频操作——DAG 支持按日期区间重跑（前提是任务幂等）；
个人量化的最小版：一个带依赖检查与失败告警的 Python 调度脚本（检查上游文件时间戳 → 失败则通知并退出）就能覆盖 90% 需求——cron + 防御式脚本，晚于需要再上 Airflow。

存储选型：按访问模式选库

量化数据的核心访问模式是「按日期截面读全部股票」+「按股票读全部历史」，两类负载的最佳载体不同：

存储	适合	特点
Parquet 文件 + 本地盘	个人/小团队的一切	按日期分区的宽表，Pandas/Polars 直读，零运维；文件即快照，版本管理容易
ClickHouse / DuckDB	因子数多、需要切片查询	列存 OLAP，长表（date, code, factor, value）亿行级秒查；DuckDB 单机零运维，ClickHouse 需要服务化
Arctic/ArcticDB（Mongo 系）	时序面板为主	tick/分钟级高频面板的专用形态，版本化内置
PostgreSQL / MySQL	元数据、订单、账户	事务型账本（订单流、持仓、审计记录）——交易账本不用 OLAP 库，要事务保证
Redis / 内存	盘中实时状态	行情缓存、实时信号状态、秒级刷新的监控指标

选型的两条经验：先文件后数据库（Parquet 阶段撑到因子数过百、数据量过 TB 再上 OLAP——大多数个人研究者永远停在 Parquet 就够了）；账本与行情分离（订单/持仓/资金是法律意义上的记录，进事务库并备份，与行情库的故障域隔离）。

每日流水线参考蓝图

1
2
3
4
5
6
7
8
9


15:30 行情接收（收盘后）
15:45 数据落地（行情表 + 复权因子更新）
16:00 质量校验（新鲜度/缺失/极值，任一失败 → 短路+告警）
16:15 财报/公告事件增量（PIT 追加）
16:30 因子计算（增量）→ 因子库版本切换
16:50 信号生成（目标组合）
17:00 风控预检（限额校验）+ 订单生成
17:05 日报推送（净值/持仓/信号/异常）+ 心跳
（次日）开盘：订单执行 → 成交回报落账 → 当日 TCA

三个设计细节：所有节点写「运行指纹」（输入数据版本 + 代码版本 + 输出版本，见Git ）——三个月后任何一天的信号可完整追溯；人工干预的入口预设计（「今日跳过交易」「手动覆盖目标持仓」要有一键且留痕的通道——总有引擎判断不了的日子）；盘后流水线的总时长预算（从收盘到日报 < 2 小时），超时即优化信号（流水线太长 = 数据迟到时的应对余量太小）。

关联阅读：流水线上游数据清洗与因子存储；下游策略上线；全链路的 CI 化DevOps 。

低延迟基础（选读）

Mon, 01 Jan 0001 00:00:00 +0000

延迟优化是量化里投入产出比最极端的领域：对某些策略，每快 1 微秒都是真金白银；对另一些策略，快 100 毫秒一文不值。本篇的价值不在「怎么优化」，而在帮你判断自己是否在需要优化的阵营里——多数人不在，而知道这一点省钱省心。

延迟的解剖：一条链路的完整预算

一笔「行情进来 → 订单出去」的端到端延迟，逐段拆开（数字为国内期货/股票高频的典型量级）：

段	内容	典型延迟	优化手段
①	交易所撮合 → 你的网卡（物理）	机房内 1–5 μs / 城内专线 30–300 μs / 跨城 5–30 ms	托管（colocation）是唯一解
②	网卡 → 内核 → 应用（协议栈）	内核态 5–20 μs / 内核旁路 0.5–2 μs	OpenOnload/DPDK、SR-IOV
③	行情解析（二进制 → 结构化）	0.3–2 μs/条	零拷贝、预编译解析器、FPGA
④	策略计算	0.5–10 μs	无堆分配、无锁队列、缓存友好
⑤	风控检查	0.2–2 μs	热路径最小化（预计算限额位图）
⑥	订单构造 + 发出	0.3–1 μs	预序列化订单模板
⑦	你的网卡 → 交易所撮合	同 ①	同 ①

读懂这张表的两个推论：其一，优化永远从「占比最大者」下手——没测过链路分布就优化代码，是延迟工程的第一浪费（典型错误：花两周把策略计算从 5μs 压到 3μs，而行情链路占了 300μs）；其二，①⑦ 的物理段占了大头，机房位置比代码快慢重要一个数量级——这就是托管费贵过工程师工资的原因。

微秒级竞争的门槛清单

低延迟高频（做市、抢单类）的完整门槛，按投入排序：

托管（colocation）：服务器放交易所机房内——入场券（几十万/年起），机房内物理距离都在微秒级；
网络硬件：交易所专线、内核旁路（Solarflare/OpenOnload 或 DPDK，绕过操作系统网络栈）、FPGA/ASIC 行情解析与订单编码（硬件线路完成处理，纳秒级）；
软件栈：C++（无 GC、无系统调用热路径）、无锁数据结构、CPU 亲和性（isolated core + 大页内存）、极简风控（风控逻辑在热路径上每加一层检查都是微秒）；
持续军备：对手在升级，你必须跟着升级——低延迟不是一次性投入而是持续折旧。

这个清单的用途是自检：如果任何一项对你不可及，「拼速度」的赛道直接排除——能做的是「速度不敏感的高频」（统计型日内回归、非抢单类空间策略），避开与顶级机构的军备竞赛。

一个「微秒的价值」算例

做市商的盈亏与排队位置的关系值得算一次：

1
2
3
4
5


某期货品种：日成交 200 万手，做市商日均成交 2 万手（吃单方对手盘的 1%）
买单排队第 1 位 vs 第 3 位的差异：成交率差约 30%，且第 1 位能挑到「反向单」
（知情单更常打穿厚档）→ 每手期望差 ≈ 0.3 跳 × 跳值 1 元 = 0.3 元
年差值 = 2 万手/日 × 240 日 × 0.3 元 = 144 万元/年
为这 144 万买的设备 + 托管年成本 80–150 万 → 微秒的生意账成立

而同一个「5 微秒」卖给日频多因子策略：价值 = 0。延迟的价值 = 策略 alpha 的时效性 × 抢到与抢不到的概率差——公式两侧都要算。

什么策略值得为延迟付费

做市：排队位置直接决定成交率与被逆向选择的比例——延迟就是库存管理的武器，值得微秒级投入；
跨市场套利（期现、跨所）：价差存在的时间以毫秒计——谁先到谁吃肉，纯粹的延迟竞赛；
统计型日内/短反转：信号半衰期以分钟计——百毫秒级的执行差异已足够，微秒无意义；
日频多因子：信号半衰期以天计——延迟优化价值趋近于零，把预算花在成本与容量上（见执行算法）。

一个反直觉的提醒：中低频策略的「延迟」瓶颈常在分钟到小时级——数据落地时间、信号计算时长、人工审批环节。把「决策到下单」从 40 分钟压到 5 分钟（自动化流水线，见调度）的收益，远大于任何微秒级工程——先优化自己的流程延迟，再考虑机器延迟。

个人可及的「延迟卫生」

不进军高频也有低分位的延迟改进空间（目标：把可控的秒级浪费清零）：

时钟同步：NTP 对齐本机时钟（日志时间戳可信的前提）——排查「信号与成交的时序」时这是地基；
行情落地的及时性：收盘数据的获取时间从「晚上十点」提到「收盘后十分钟」（数据源与定时任务优化）——它决定次日信号的生成窗口；
下单路径的精简：信号 → 订单之间去掉人工环节（邮件、Excel 中转）；API 直连券商优于网页端手工；
监控延迟指标：记录「行情时间戳 → 订单时间戳」的分布——先有度量，才知道哪里值得改（日志体系见日志与监控）。

关联阅读：速度竞赛的商业本质高频交易概论；延迟敏感的策略类型策略频率分类；工程栈的选择其他语言生态。

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

Mon, 01 Jan 0001 00:00:00 +0000

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

技术灾备：故障模式清单

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

故障	检测	响应预案
策略进程崩溃	心跳超时（见日志监控）	自动重启 + 状态恢复（从账本重建持仓）；重启失败 → 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 持仓差异），持仓差异（券商有仓、本地无记录）优先级最高——那可能是账户被盗用的信号。

个人的灾备底线（一小时能建完）

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

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

DevOps 与 CI/CD

Mon, 01 Jan 0001 00:00:00 +0000

软件工程的 CI/CD（持续集成/持续部署）在量化里有一个特殊的翻译：每一次代码变更，都要自动证明「回测结果没有意外变坏」。本篇讲量化 CI 的特有检查项与部署自动化——它对个人研究者的价值不是「专业感」，而是把「我不记得上次改了什么」从根源上消灭。

量化 CI 的检查流水线

每次 git push / PR 触发，依次通过四层：

第一层：代码质量（快速反馈，秒级）

lint（ruff）+ 格式（black）+ 类型检查（mypy）+ 单元测试（pytest）——与一般软件工程相同（工具链见代码质量），失败即终止，反馈周期要短（< 5 分钟）——反馈越慢，越有人绕过它。

第二层：策略特有的静态检查（量化独有）

前视模式扫描：规则化的代码检查——「信号计算函数内访问了当日/未来列」「merge 后未校验对齐」「shift 方向错误」的高危模式清单。规则只能抓常见形态，但抓到一个都是真事故。可执行的起步版：一个 ruff 自定义规则 + 一份「禁用 API 清单」（如禁止在信号函数内调用 shift(-n)）；
魔法数字与口径审计：成本费率、涨跌停幅度等制度参数是否引用统一配置（而非散落硬编码，见A 股执行的参数卡）——「印花税从 0.1% 降到 0.05%」的政策变更（2023 年 8 月真实发生），散落硬编码的仓库要改十处、漏三处；
依赖注入检查：因子/策略函数的输入是否全部显式传参（禁止隐式读全局数据——它是「研究环境对、生产环境错」的常见根源）。

第三层：回测回归测试（核心闸门，分钟级）

固定基准数据集 + 固定策略集：对一组「守门策略」（1–2 个简单已验证策略）在基准数据上跑回测，与上次通过版本的净值曲线 diff：

diff 为零或极小（< 数值噪声）→ 通过；
有变化 → 必须能解释：本次变更预期影响什么？变化的方向与幅度是否匹配？

这条闸门的杀手级用途：它把「我只是改了一行工具代码，不影响策略」变成自动证伪——无数「顺手的小改动」造成的静默策略变化，都在这里现形。一个典型场景：重构数据加载模块时顺手改了默认复权方式，三个策略的净值曲线同时漂移 2%——没有回归测试，这要在实盘偏差出现后才被发现（那时已经亏了）。守门策略的选择要点：覆盖主要代码路径（至少一条含财务因子、一条纯量价）、绩效指标稳定（本身不是高方差的策略）。

第四层：性能与数据契约

因子计算的运行时长上限（超时报警——计算退化常暗示数据结构变化）；输出数据的 schema 校验（列名/类型/日期连续性）——数据契约是研究层与生产层之间的合同（见架构的环境一致性）。

部署自动化

CI 全绿之后的 CD（持续部署）按风险分级：

数据管道与因子计算：自动部署（夜车流水线，见调度）——前提是第二、三、四层全绿；部署后自动跑一次「冒烟回测」（最近 20 日）验证；
信号/策略代码：半自动——CI 绿 + 人工点批准（审批记录留痕，见安全）；部署后先影子模式运行一个交易日（与旧版本并行对比信号 diff）再正式接管；
风控参数与限额：最高审查级别——双人审批 + 变更窗口（不在盘中改限额）；
回滚：每次部署保留「一键回滚到上一版本」（镜像/快照化），回滚也是部署、也要走审计（与回滚预案衔接）。

部署频率的真相：量化系统的正确节奏是「低频而严格」——策略代码的变更以周/月计（每笔变更都过全闸门），数据与监控的变更可以日频。「持续部署」在量化里的正确读法是「持续验证、谨慎部署」。

一个人的 CI：GitHub Actions 最小配置

个人研究者半天可建的最小 CI（GitHub Actions / Gitea Actions / 本地 pre-commit + 定时跑）：

1
2
3
4
5
6
7


# .github/workflows/quant-ci.yml 核心步骤示意
on: [pull_request]
jobs:
 lint: # ruff + mypy （1 分钟）
 unit: # pytest 单元测试 （2 分钟）
 regression: # 守门策略回测回归 （10 分钟，结果与基准 diff）
 smoke: # 最近 20 日因子冒烟 （5 分钟）

投入产出的账：搭建 1 天 + 每次变更多等 15 分钟 ↔ 换来「任何历史版本可复现、任何静默破坏被拦截」——对以年为单位的策略资金，这是整个工程体系里性价比最高的单项投资。

关联阅读：闸门背后的检查依据回测偏差与代码质量；部署的完整流程策略上线；变更的版本管理Git 。