事件概览：40 分钟全栈停摆
2023 年 3 月 17 日上午 8 点 39 分至 9 点 28 分（UTC），全球用户遇到 OKX 交易系统出现不同程度延迟或完全无法连接的情况。整个故障窗口约 49 分钟，瞬时高峰的θ-日志流量触发一连串级联故障，最终 强行减缓全部撮合队列 以保障市场秩序的完整。
在我们官方监控面板中，这段时间被定义为“交易中断事故（Trading Outage Incident）”，优先级达到最高级 P0。
完整时间线：每一分钟发生了什么
- 08:39:00 UTC
局部 API 延迟报警，SRE 群内首次响起机器人提示：“request latency spike > 500ms”。 - 08:45:00 UTC
影响面迅速扩散至 USDT 盈利合约区，主动买单与被动卖单同步堆积。 - 08:49:00 UTC
风险控制委员会 紧急下线全站撮合服务，同时发布停机通知，HTTP 503 状态页上线。 - 08:50:00 UTC
状态页确认“系统维护中”，提醒用户“行情信息仅供参考，无法下单”。 - 09:10:00 UTC
根因锁定：核心撮合集群的分布式日志回收脚本触发 瞬时间 7 倍峰值 IO，磁盘 IOPS 被打满。 - 09:18:15 UTC
预开盘功能先行复用，用户可取消原有挂单，资金划转到交易账户通道恢复。 - 09:28:15 UTC
全网交易服务 100% 恢复；盘口价差回归正常区间。
故障根因：为何一点“日志”就能拖垮全局
当日 8:39 之前，核心组件运行平稳。问题出在我们新上线 分布式搜索压缩日志模块：
- 日志轮转工具 Bug：压缩缓冲未限制大小，持续扫描历史文件产生异常循环。
- 瞬时磁盘 IOPS 激增：SSD 写入带宽在 5 秒内被掠空，CPU context switch 暴涨，导致撮合服务对外 timeout。
- 下游熔断触发：前端网关对接单 API 调用 排队 90 秒仍无响应，最终只能选择全局熔断市场。
一句话总结：
日志处理范式“从文件到搜索”切换中的缓存管理疏漏，导致高频交易生态中的 雪崩效应。
三步预防机制：让历史不再重演
1. 资源隔离与日志限幅
- 追加
max_log_block_size=32 MB的硬性阀值，达到即自动降维输出。 - 将日志采集层与撮合业务 部署在不同云资源池，避免资源竞争。
2. 可观测性再进化
- 新增 “磁盘 IOPS 瞬时利用率 > 70%” 的秒级警报。
- 服务网格侧引入 eBPF trace 采集上下文，做到 5 秒内定位问题栈。
3. 场景化演练与灰度闸刀
- 每月切一次演练日，实战模拟 “磁盘被打爆” 的极端场景。
- 灰度发布升级日志组件，滚动不超过 5% 流量，降低一次出错全军覆没的风险。
对用户的郑重承诺
- 透明度：所有重大故障均会在 10 分钟内以 Status 页 + 邮件 双通道同步，绝不藏着掖着。
- 赔偿方案：符合资格的单子，我们将统一发放 USDT 抵用券，到账耗时 ≤ 24 小时。
- 持续优化：全年故障复盘将由外部审计公司 Deloitte 提供二次评估，报告公开可读。
👉 加入 Telegram 官方频道，实时故障一键通知不遗漏
常见问题 FAQ
Q1：我在 8:45 下的限价单，没成交，会被系统丢失吗？
A：不会。未成交订单已标记为“保留”，将在恢复撮合后重新进入队列，若不想交易可直接手动撤单。
Q2：合约仓位在停机期间被强平，如何申请补偿？
A：请于故障结束 24 小时内在 “账户-资产-系统事件申诉” 板块提交凭证，我们会在 3 个工作日内完成审核并给出结果。
Q3：今后如何避免再次因“日志膨胀”导致中断？
A：我们已上线 自动缩减 与 资源隔离 双保险，并会在每条功能发布前增加 IO 负载沙箱测试。
Q4：这次事件会不会影响 USDT 充值/提现？
A：充值、提现通道完全独立，未受交易撮合服务影响，往返链上时间保持正常。
Q5：作为高频 API 用户，我第一时间想知道系统稳不稳定。有没有更快的方式？
A：您可在 开发者中心 订阅 HTTP 状态 Webhook，一旦 Status Code ≠ 200 立即推送。
OKX 团队将持续把 “零事故” 视为终极 KPI。感谢您的耐心与信任，我们深知交易不间断背后的 每一分每一秒都值得被守护。