交易知识库

简体中文

English

简体中文

English

Appearance

05 · 运行与自动化环境 ​

分析脚本写好了，下一步是让它长期、稳定、自动地跑起来——这一步的坑不比策略本身少：服务器选错、时区不对、密钥泄露、日志丢失、半夜没人知道程序挂了……

本篇写给个人量化/自动化玩家：从服务器选型（国内外厂商怎么选、网络问题怎么解）到配置建议（2C4G 到底够不够），从部署运维（systemd/cron/pm2）到日志监控、时间同步、成本预算，最后是一份必须背下来的安全基线。

⚠️ 风险提示

自动化环境的每一条疏漏都可能转化为真实资金损失：API Key 泄露、服务器被入侵、时区错位导致订单在错误时间发出、程序静默崩溃导致错过**止损**。加密交易所 API 的使用受平台条款与所在地区法规约束，访问境外服务请自行确认合规性。文中价格与配置参数均为参考，以各厂商最新报价为准。本文内容仅用于学习与研究，不构成任何投资建议，市场有风险，投资需谨慎。

一、个人服务器的选择 ​

1.1 云服务器对比 ​

厂商定位特色适合场景
阿里云/腾讯云国内头部云厂商国内节点快、备案便利、生态完整访问 A 股/期货数据、国内服务
搬瓦工（BandwagonHost）等海外 VPS性价比线路商直连优化线路、便宜访问境外 API（加密交易所、国际数据源）
AWS/GCP/Azure 国际区国际巨头全球节点、稳定性天花板对可靠性要求高的生产环境
各厂商轻量应用服务器入门级低配低价（如 2C2G 一年几百元）个人日线级策略够用

1.2 国内访问交易所 API 的网络问题 ​

  • 加密交易所 API（币安/OKX/Bybit 等）域名在境内无法直连或极不稳定，国内服务器访问境外 API 走的是国际出口，延迟高、抖动大、易被墙阻断；
  • 常见解法（各有利弊，自行评估合规性）：
    • 境外服务器（香港/新加坡/东京/美西）：直接部署在境外节点，物理延迟最低，是个人量化的主流选择；
    • 代理/中转：国内服务器 + 代理访问境外 API——引入额外故障点，不推荐用于自动化；
  • 结论：访问哪个市场的数据/API，服务器就放哪个区域——做 A 股放国内（或内地可达线路），做加密放境外。

1.3 加密交易所 API 对境外服务器的偏好 ​

  • 加密交易所对数据中心 IP 的访问更稳定（云厂商 IP 段少被误伤），且延迟低：香港/新加坡节点访问币安、OKX、Bybit 等亚州中心交易所体验好；
  • 用住宅 IP 或小机房 IP 反而不稳定——正规云厂商的境外节点即可；
  • 注意：部分交易所对特定地区 IP 有服务限制，IP 所在地也要匹配你的账户合规状态，以各平台条款为准。

二、服务器配置建议：2C4G 够不够 ​

场景建议配置说明
日线级研究/定时任务（每日收盘后跑一遍）1C2G 起脚本跑几分钟就结束，根本用不满
分钟级数据采集 + WebSocket 常驻2C2G~2C4G内存主要吃在行情缓冲与日志
回测/参数寻优按需升配大回测吃 CPU 与内存，跑完再降配
多标的 tick 级高频4C8G 起步高频的数据量与延迟要求不在个人教程讨论范围

结论：2C4G 对绝大多数个人量化完全够用。真正容易爆的不是配置，而是：

  • 日志不轮转把磁盘写满（见第四节）；
  • 内存泄漏长期不重启；
  • 数据量增长后没有清理策略（历史行情文件越积越大）。

💡 选配置的原则：先小后大

选配置的原则：先小后大——1C2G 起步跑通，遇到瓶颈再升配，云厂商升配都是一键的事；把预算留给「稳定」（见第六节）。

三、操作系统与部署 ​

3.1 Linux 基本命令（够用清单） ​

bash
# 常用的就这么几条
ssh user@ip            # 登录服务器
ls / cd / pwd          # 目录
mkdir -p /opt/trader   # 建目录
nano / vim 配置        # 改文件
htop / top             # 看资源占用
df -h                  # 看磁盘
crontab -e             # 定时任务
systemctl status xxx   # 看服务状态

3.2 进程管理：pm2 vs systemd ​

方式特色适用
pm2Node 生态常用，一键守护/重启/日志聚合快速上手、脚本多样（也支持 python）
systemd系统级服务管理，开机自启、崩溃重启、日志统一生产级推荐，Ubuntu 自带

systemd 示例（/etc/systemd/system/trader.service，教学示意）：

ini
[Unit]
Description=trader bot
After=network-online.target

[Service]
User=trader
WorkingDirectory=/opt/trader
ExecStart=/usr/bin/python3 /opt/trader/main.py
Restart=always
RestartSec=10
EnvironmentFile=/opt/trader/.env   # 密钥放这，不写进代码

[Install]
WantedBy=multi-user.target
bash
systemctl daemon-reload
systemctl enable --now trader
journalctl -u trader -f        # 实时看日志

⚠️ 别用 nohup 裸跑

别用 nohup 裸跑：掉线、崩溃后没人会把它拉起来，等于没有自动化。

3.3 cron 定时任务 ​

  • crontab -e 添加每日任务，示例：每天 15:05 跑复盘、每日 20:00 增量拉数据；
  • cron 的坑：环境变量与登录 shell 不同（脚本里用绝对路径、显式指定 Python）、时区问题见第五节。

四、日志与监控 ​

4.1 日志轮转 ​

  • 日志只增不删会把磁盘写满（最常见的「程序没挂、系统挂了」事故）；
  • logrotate 按天切分 + 保留 7-14 天，或 Python 内用 logging.handlers.RotatingFileHandler；
  • 日志分级：交易日志（成交/订单）与调试日志分开存，查问题时互不干扰。

4.2 错误告警：推送到手机 ​

告警的意义是「半夜出问题时你能被叫醒」。常用通道与思路（示例见 15-量化实战篇-04）：

通道思路
Telegram Bot海外环境最常用，一条 HTTP 请求即可推送，可带 Markdown/图片
钉钉/企业微信机器人国内环境方便，webhook 签名机制按官方文档实现
邮件兜底通道，延迟高但可靠（收件箱告警规则再转手机推送）
bash
# 思路示例：脚本异常时推送到钉钉（密钥与 webhook 以官方文档为准）
curl -s -X POST "$WEBHOOK_URL" \
  -H 'Content-Type: application/json' \
  -d '{"msgtype":"text","text":{"content":"交易脚本异常: 请检查 /opt/trader/logs"}}'

💡 告警要带上下文

告警要带上下文：时间、标的、错误类型、影响范围——半夜收到一句「有错误」等于没收到。

4.3 监控什么 ​

监控项手段
进程存活systemd Restart + **心跳上报（脚本定期发 alive 消息，超时未收到即告警）
数据新鲜度检查最新 K 线/数据更新时间戳，超过 N 分钟未更新即告警
磁盘/内存定时脚本检查 df -h、free -m，超阈值告警
策略信号连续 N 根 K 线无信号、或信号频率异常，都要人工确认

五、时间同步：交易服务器的时区坑 ​

  • 时区规则：服务器统一 UTC 存储与运行，展示层再转本地时间；定时任务的执行时刻必须按目标交易所时区换算；
  • NTP 同步：timedatectl set-ntp true 保持时钟同步，机器时钟漂移会让时间戳与交易所不一致（对 WebSocket 心跳、限频窗口、K 线边界都有影响）；
  • 经典事故：服务器设在 UTC-8（美西）运行 A 股 15:00 收盘任务，实际触发时间是北京时间 07:00；或加密脚本按「服务器本地 0 点」切日线，切到的是美东时间边界——K 线收盘时刻、资金费率结算时刻、交割时刻，全部以交易所官方时区为准；
  • 建议：脚本内显式指定时区（Python 用 zoneinfo/pytz，勿依赖系统本地时间）；cron 用 CRON_TZ 明确时区。

六、成本预算：个人量化每月花多少 ​

项目参考价（以最新报价为准）说明
境外 VPS（2C2G）约 10-30 美元/月搬瓦工/云厂商轻量，加密自动化主力
国内轻量服务器（2C2G）约 30-100 元/月（新用户优惠价更低）A 股数据定时任务
数据源0-100 元/月免费接口为主，Tushare 积分/米筐按需
告警通道0 元Telegram/钉钉 webhook 免费
域名（可选）约几十元/年访问管理界面用

合计：个人量化「起步配置」每月约 50-200 元人民币，完全跑得动日线级策略与定时研究。 花钱顺序建议：服务器 > 数据 > 其他；先 1C2G 起步，别一上来就买最贵的。

七、安全基线（必须背下来） ​

7.1 SSH 与防火墙 ​

  • 禁用密码登录，只用 SSH 密钥登录（PermitRootLogin no + PasswordAuthentication no）；
  • 防火墙只放行必要端口（SSH、应用端口），其余默认拒绝；
  • 参考流程：生成密钥 → 公钥放服务器 ~/.ssh/authorized_keys → 测试密钥登录成功后再关密码。

7.2 API Key 隔离 ​

规则说明
最小权限只开「交易 + 读取」，绝不开提现权限；能开 **IP 白名单**就开
不落盘进代码密钥放 .env（权限 600），systemd 用 EnvironmentFile 注入
不进 git密钥进过 git 历史视为已泄露，立即吊销重建
隔离账户自动化用一个单独的子账户/子密钥，与主账户资金隔离
定期轮换每 3-6 个月重建一次 API Key

7.3 加密交易所 API Key 泄露的常见路径 ​

  1. 代码仓库：把 Key/Secret 提交进 GitHub——盗币脚本全网扫描公开仓库的密钥是常态（见 15-量化实战篇-04 的真实案例）；
  2. 聊天记录/网盘：截图、文档、群文件里传密钥；
  3. 服务器被入侵：密码登录开着、SSH 密钥 777 权限、面板弱口令——入侵后第一件事就是翻 .env；
  4. 第三方工具：把密钥填进来路不明的「量化工具/跟单软件」；
  5. 日志泄露：代码里 print(secret) 或把密钥写进日志文件。

泄密后的动作：立即到交易所吊销该 Key（手机 App 可操作）→ 转移受影响资产 → 排查泄露路径 → 换新密钥。

💀 密钥进过 git 历史就视为已泄露

只开「交易 + 读取」，绝不开提现权限；密钥进过 git 历史就视为已泄露，立即吊销重建。 盗币脚本全网扫描公开仓库的密钥是常态——进过 git、聊天记录、日志的密钥一律更换。

八、下一步 ​

环境搭好之后，把策略代码放上去跑起来——代码与策略从 15-量化实战篇 开始；工程层面的系统设计再对照 10-系统对接篇 的监控与安全章节查漏补缺。

⚠️ 风险提示

服务器是自动化交易的「现场」：入侵、密钥泄露、时区错误、静默崩溃、日志写满、网络断流，任何一个环节都可能造成无法挽回的资金损失。境外服务器与加密 API 的使用须自行确认所在地法规与平台条款；文中所有价格与配置为参考值，以各厂商最新报价为准。本文所有命令与方案仅用于学习与研究，不构成任何投资建议；自动化上线前请完成安全加固、小资金验证与人工干预预案，市场有风险，投资需谨慎。

相关阅读 ​

仅供学习与研究，不构成任何投资建议。市场有风险，投资需谨慎。

Kline Buty · 交易知识库