纳斯达克与 Facebook 上市首日：为什么在最重要的一次上市里，交易所的撮合系统会在开盘时卡住？

# 商业复盘备忘录：纳斯达克与 Facebook 上市首日

> 为什么在最重要的一次上市里，交易所的撮合系统会在开盘时卡住？
> 周期: 2012 - 2013 | 行业: 金融与科技
> 巅峰: 全球主要证券交易所之一，长期以电子交易系统承接大量科技公司上市，是当时最受关注的首次公开发行的承办方
> 终局: 在当年最大规模的科技公司上市首日出现撮合系统故障，开盘延迟、订单确认延迟数小时，做市商巨额损失，交易所此后被监管处以罚款并承担赔偿

## 核心概览
系统的设计上限，是按平时的流量估的，而上市首日是另一种流量。巅峰期全球主要证券交易所之一，长期以电子交易系统承接大量科技公司上市，是当时最受关注的首次公开发行的承办方；终局是在当年最大规模的科技公司上市首日出现撮合系统故障，开盘延迟、订单确认延迟数小时，做市商巨额损失，交易所此后被监管处以罚款并承担赔偿。

## 社区公投头号死因
1. [产品技术] 系统容量按常规交易量设计 (1,144 票)
2. [组织管理] 缺少异常情况下的降级预案 (961 票)
3. [战略决策] 上市前未做该场景的完整压力验证 (778 票)

## 可执行教训
### 关键系统的容量要按「最热的那一天」来设计
> 平均值够用，不代表峰值撑得住。

- ✅ 推荐做 (DOs):
  - 对特殊场景（上市、指数调整）做专项压力演练
  - 为撮合类系统准备可立即执行的降级流程
- ❌ 绝不能做 (DON'Ts):
  - 不要用日常流量验证关键系统
  - 不要在异常时让参与者自行猜测状态

## 救亡方案
### 先按极端场景重做容量与降级方案，再承接大型发行 — 良略编辑部
干预时点: 2012 年 5 月上市首日开盘出现故障后
- 必须断腕:
  - 停止在没有专项演练的情况下承接同量级发行
  - 停止用常规流量作为容量评估依据
  - 停止在异常时让参与者自行推断状态
- 破局动作:
  - 按极端订单模式重做容量评估与压力测试
  - 为撮合系统准备可一键切换的降级与恢复流程
  - 与做市商建立故障期的状态同步机制
- 预期结果: 交易所在大型发行中保持系统稳定，参与者无需承担无法确认状态的风险，也避免被监管处罚。

## 社区见解
### 系统的容量不是按平均流量算的，是按最容易出事的那一天算的。 — 良略编辑部 (工程师)
上市首日的订单行为与平时完全不同：集合竞价阶段的取消与修改量会成倍增加。交易所的系统按常规交易量设计，在这种流量模式下出现了连锁延迟，而更关键的是没有一条能立刻执行的降级路径——从出现异常到恢复用了数小时，期间做市商无法确认自己的成交状态，损失只能事后补偿。
- 如果重来一次的纠偏招式 关键系统真正的设计目标不是「平时够用」，而是「异常时能停下来」。

---
来源: 良略 · https://www.lianglue.com/c/nasdaq-facebook-ipo