第 20 课：生产运维

目标：让系统在没有你的时候也能正常运行，并在出问题时及时通知你。

一个典型场景（示意）

注：以下为合成示例，用于说明常见现象；数字为示意，不对应任何具体个人/账户。

2022 年，一位独立量化交易者上线了他精心打磨半年的自动交易系统。回测完美，模拟盘跑了三个月也很稳定。他信心满满地投入了 50 万美元实盘。

前两周，系统表现正常。第三周的周一凌晨，他被一条短信吵醒：账户余额不足。

检查发现：周五收盘后，数据源 API 改版，返回格式变了。系统解析失败，抛出异常，但异常被静默吞掉了。周末两天，系统没有任何日志输出（他以为周末不交易所以没关注）。周一开盘，系统恢复连接但状态混乱，执行了一系列荒谬的订单，包括一笔巨额做空。

等他发现时，账户已经亏损 40%。

问题出在哪里？

1. 没有健康检查：数据源故障没有被发现
2. 异常被吞掉：错误没有上报
3. 没有监控告警：周末两天零日志却没人知道
4. 没有熔断机制：状态异常时没有停止交易

这就是为什么"代码能跑"和"系统可靠"是两回事。运维不是事后补救，是系统设计的一部分。

20.1 监控体系

监控的四个层次

关键监控指标

健康检查设计

20.2 日志系统

日志的黄金法则

日志是产品，不是副产品。

日志分级

交易日志标准格式

{
  "timestamp": "2024-01-15T09:30:00.123Z",
  "level": "INFO",
  "service": "execution_agent",
  "trace_id": "tx_20240115_001",
  "event": "order_submitted",
  "data": {
    "symbol": "AAPL",
    "side": "BUY",
    "quantity": 100,
    "price": 180.50,
    "order_type": "LIMIT",
    "order_id": "ORD_12345"
  },
  "context": {
    "signal_id": "sig_20240115_001",
    "signal_strength": 0.75,
    "regime": "trending",
    "portfolio_value": 1000000
  }
}

关键字段：

• trace_id：贯穿从信号到成交的完整链路
• event：标准化事件名，便于统计分析
• context：决策依据，用于事后归因

20.3 告警系统

告警设计原则

告警通道

告警模板

🚨 [严重] 交易系统告警

时间: 2024-01-15 10:30:15 EST
服务: Risk Agent
事件: 回撤触发控制线

详情:
- 当前回撤: 10.2%
- 触发阈值: 10%
- 今日 P&L: -$52,000
- 账户净值: $948,000

已执行动作:
- 停止新开仓
- 开始减仓流程

需要你:
- 检查是否有异常交易
- 确认是否需要人工干预

仪表盘: https://dashboard.example.com/alerts/12345

告警抑制

20.4 容灾与恢复

故障分类

恢复流程

状态一致性检查

恢复后必须验证：

20.5 交易时段自动化

生产系统不应该依赖人类记得按"启动"按钮。

交易系统的运行不是 24/7 的 Web 服务，而是严格与市场交易时段绑定的。这一点经常被忽略，却是生产可靠性的关键环节。

20.5.1 时段调度设计

美股交易日调度（东部时间 ET）：

09:15  系统自动启动
       ├── 数据源连接检查
       ├── 券商 API 心跳验证
       ├── 持仓状态同步
       └── 开盘前检查清单自动执行

09:30  交易窗口开启
       └── Agent 开始接收信号并执行

16:00  交易窗口关闭
       └── 停止新开仓

16:05  收盘后处理
       ├── 收盘后检查自动执行
       ├── 日度 P&L 结算
       ├── 日志归档
       └── 日报推送

16:30  系统自动停止

20.5.2 关键要求

常见事故：系统在美国独立纪念日（7 月 4 日）尝试连接已关闭的交易所，触发大量告警。看似简单，却是生产环境中反复出现的问题。

20.6 日常运维清单

开盘前检查（每日必做）

收盘后检查（每日必做）

周度/月度检查

20.7 Provider 抽象模式

好的架构让你换掉数据源或券商时，只改配置不改代码。

生产系统应当为外部依赖定义清晰的接口抽象，使核心逻辑与具体供应商解耦：

数据源接口:
  Connect()     → 建立连接
  Subscribe()   → 订阅标的
  Stream()      → 接收实时行情

执行通道接口:
  SubmitOrder()  → 提交订单
  CancelOrder()  → 撤销订单
  QueryStatus()  → 查询状态

每个具体供应商（IB、Alpaca、Databento 等）实现这些接口。当你需要增加港股通道或切换数据源时，只需实现一个新的适配器，不需要修改策略逻辑、风控规则或监控系统。这也是实现多市场交易的前提条件。

20.8 模型部署与 CI/CD

20.8.1 为什么交易系统需要 CI/CD

每一次上线都是风险事件。CI/CD 让这个风险可控。

传统做法的问题：

20.8.2 交易系统的 CI/CD 流水线

20.8.3 各阶段详解

阶段一：Build（构建）

# 示例：GitHub Actions 配置
build:
  steps:
    - name: 检出代码
      uses: actions/checkout@v3

    - name: 安装依赖
      run: pip install -r requirements.txt

    - name: 类型检查
      run: mypy src/ --strict

    - name: 代码规范
      run: ruff check src/

    - name: 打包模型
      run: |
        python -m src.models.package \
          --model-path models/signal_v3.pkl \
          --output artifacts/

阶段二：Test（测试）

双层回测验证（Quality Gate）：

交易系统的回测验证不能只跑一种回测。建议在 CI/CD 流水线中强制执行双层验证：

第一层用于快速筛选：跑不过信号层面的策略直接淘汰，不浪费执行模拟的计算资源。第二层用于确认可交易性：通过了信号验证的策略，必须在包含订单管理、滑点模拟和成交概率的环境中再跑一遍。两层都通过才允许部署。

# 回测验证示例
def test_model_performance():
    """确保新模型在回测中达到最低标准"""
    results = run_backtest(
        model='models/signal_v3.pkl',
        start_date='2022-01-01',
        end_date='2023-12-31'
    )

    assert results['sharpe'] >= 1.0, f"夏普比率不足: {results['sharpe']}"
    assert results['max_drawdown'] <= 0.15, f"回撤过大: {results['max_drawdown']}"
    assert results['win_rate'] >= 0.45, f"胜率不足: {results['win_rate']}"

    # 过拟合检查
    in_sample_sr = results['in_sample_sharpe']
    out_sample_sr = results['out_sample_sharpe']
    assert out_sample_sr >= in_sample_sr * 0.7, "样本外表现衰减过大，可能过拟合"

阶段三：Stage（预发布）

影子模式（Shadow Mode）：

影子模式运行标准：

阶段四：Prod（生产）

灰度发布策略：

class CanaryDeployment:
    """金丝雀部署控制器"""

    def __init__(self, old_model, new_model):
        self.old_model = old_model
        self.new_model = new_model
        self.canary_weight = 0.05  # 从 5% 开始

    def get_signal(self, market_data: dict) -> dict:
        # 按权重分配流量
        if random.random() < self.canary_weight:
            signal = self.new_model.predict(market_data)
            signal['model_version'] = 'canary'
        else:
            signal = self.old_model.predict(market_data)
            signal['model_version'] = 'stable'
        return signal

    def promote_canary(self, new_weight: float):
        """提升金丝雀权重，逐步放量"""
        if new_weight > self.canary_weight:
            log.info(f"提升金丝雀权重: {self.canary_weight:.0%} → {new_weight:.0%}")
            self.canary_weight = new_weight

    def rollback(self):
        """回滚到稳定版本"""
        log.warning("金丝雀回滚！切回稳定版本")
        self.canary_weight = 0.0

20.8.4 模型版本管理

版本命名规范：

模型版本格式: v{major}.{minor}.{patch}-{timestamp}

示例:
  v2.3.1-20240115  # 2024年1月15日的 v2.3.1 版本

版本规则:
  major: 模型架构变化（如从 XGBoost 换成神经网络）
  minor: 特征或参数调整
  patch: bug 修复

模型注册表：

20.8.5 自动回滚

class AutoRollback:
    """自动回滚控制器"""

    def __init__(self, rollback_thresholds: dict):
        self.thresholds = rollback_thresholds
        self.metrics_buffer = []

    def check_and_rollback(self, current_metrics: dict) -> bool:
        """检查是否需要回滚"""

        # 即时回滚条件（单次触发）
        if current_metrics.get('error_rate', 0) > self.thresholds['max_error_rate']:
            self.trigger_rollback("错误率过高")
            return True

        if current_metrics.get('latency_p99', 0) > self.thresholds['max_latency']:
            self.trigger_rollback("延迟过高")
            return True

        # 累积回滚条件（趋势判断）
        self.metrics_buffer.append(current_metrics)
        if len(self.metrics_buffer) >= 10:  # 足够样本
            recent_sharpe = np.mean([m['sharpe'] for m in self.metrics_buffer[-10:]])
            if recent_sharpe < self.thresholds['min_sharpe']:
                self.trigger_rollback(f"夏普下降: {recent_sharpe:.2f}")
                return True

        return False

    def trigger_rollback(self, reason: str):
        """执行回滚"""
        log.error(f"触发自动回滚: {reason}")

        # 1. 切换到上一个稳定版本
        model_registry.activate('last_stable')

        # 2. 发送告警
        alert_system.send(
            level='critical',
            title='模型自动回滚',
            message=f'原因: {reason}'
        )

        # 3. 记录回滚事件
        audit_log.record('rollback', {'reason': reason})

20.8.6 CI/CD 实践清单

20.9 多智能体视角

Monitor Agent 的角色

Agent 间的健康协作

✅ 验收标准

完成本课后，用以下标准检验学习效果：

综合练习

设计你的运维体系：

1. 列出你需要监控的关键指标（至少 10 个）
2. 设计日志格式（包含必要字段）
3. 设计告警规则（指标、阈值、级别、通道）
4. 编写开盘前检查清单
5. 设计一个故障场景的恢复流程

本课交付物

完成本课后，你将获得：

1. 四层监控框架 - 基础设施/服务/应用/业务
2. 日志标准模板 - 结构化交易日志格式
3. 告警设计指南 - 级别、通道、抑制策略
4. 运维清单 - 开盘前/收盘后检查项
5. CI/CD 部署流水线 - 构建、测试、影子模式、灰度发布

本课要点回顾

• 理解监控的四个层次及其关键指标
• 掌握结构化日志的设计原则
• 理解告警系统的设计要点
• 掌握故障恢复流程和状态一致性检查
• 建立日常运维检查的习惯
• 设计 CI/CD 流水线实现模型安全部署

延伸阅读

• 第 19 课：执行系统 - 执行环节的监控重点
• 背景知识：执行模拟器实现 - 用于 CI/CD 测试的执行模拟
• 第 17 课：在线学习与策略进化 - 模型漂移检测的实现细节
• 附录 A：实盘交易记录标准指南 - 详细的日志规范

下一课预告

第 21 课：项目实战

理论到此结束。下一课我们将从零开始，构建一个完整的多智能体交易系统——整合前 20 课的所有知识，从架构设计到代码实现，从回测验证到生产部署。