金融系统·稳定性治理·SRE·故障复盘
一次金融系统雪崩的完整复盘
从用户投诉到稳定性体系重建
故障持续时间
1–3 小时
发现方式
用户投诉
影响范围
核心交易链路全线
一、那个午夜发生了什么
午夜，某主流币对突然出现单边行情。
市场开始剧烈波动的瞬间，交易网站的访问量急速攀升——大量用户涌入，每一个用户连接都意味着一条新的 WebSocket 长连接被建立。
问题在于，这套 WebSocket 服务同时承担了两个职责：对外，维护所有用户的实时连接；对内，负责系统内部行情数据的订阅与推送。两个职责耦合在同一个服务里，意味着外部流量的冲击会直接穿透到内部数据链路，没有任何隔离。
连接数在几分钟内陡增。WebSocket 服务的 CPU 开始飙升，处理延迟从毫秒级变成秒级。这时候，雪崩开始了。
Avalanche chain
柜台服务——整个交易系统的核心，负责处理用户买卖订单——依赖 WebSocket 服务获取实时行情数据。当 WebSocket 服务响应变慢，柜台服务收到的行情开始滞后，订单处理堆积，柜台服务的响应时间也随之拉长。
用户侧的体验是：交易页面卡住了，行情不动了，订单提交没有反应。
没有任何监控告警提前响起。发现问题，是因为用户投诉电话打进来了。
从发现故障到服务恢复，花了将近三个小时。
二、为什么监控没有提前发出警报
事后复盘，监控系统其实是有告警的——只是告警来得太晚，而且告警的时候是大量服务同时异常，根本看不出从哪里开始出的问题。
更根本的问题是：我们的监控覆盖的是单一维度的指标——CPU、内存、QPS。这次故障的真实信号是 WebSocket 连接数的趋势性积累，在任何单点指标上都看不出来，每个服务单独看都是「正常的」。
告警盲区
故障期间监控看到的现象： 交易量出现短暂波动（升高）后恢复 ↓ 但服务并没有真正恢复到正常状态 ↓ 故障仍在延续，我们误判了恢复信号
真正需要的，是跨服务依赖链路的整体视角——当 A 服务的某个指标趋势异常，能自动关联到依赖 A 的 B、C 服务的健康状态，而不是等到所有服务都报警了，再人肉排查根因。
| 传统单点监控 | 链路依赖监控 | |
|---|---|---|
| 视角 | 单个服务的指标 | 跨服务的依赖健康度 |
| 告警时机 | 服务已经崩了 | 趋势异常时提前预警 |
| 根因定位 | 人肉排查 | 自动关联传导链 |
| 这次表现 | 大量服务同时告警，无法定位 | 应在连接数陡增时即告警 |
三、雪崩是怎么一步步传导的
为什么 WebSocket 服务会同时承担内外两个职责？这是一个历史设计决策——当时的出发点是合理的：
- 内外部数据使用同一个数据源，放在一个服务里可以保证数据一致性
- 避免跨服务调用带来的延迟和数据不一致性问题
- 初期架构更简单，开发成本更低
这个决策在低流量下是合理的。但它埋下了一个隐患：外部用户流量和内部系统数据流之间没有任何隔离层。一旦外部流量激增，内部数据管道也会随之被拖垮。
这不是一个低级错误，而是一个在当时合理、在后来成为定时炸弹的架构取舍。很多系统都有这样的「历史包袱」。
Architecture (schematic)
外部用户 ──┐
行情数据源 ─┘
│（两个职责耦合，无隔离）
↓
问题的本质：一个没有做服务边界隔离的设计，在极端流量下暴露了致命的耦合。
四、扩容解决了什么，没解决什么
通过快速定位到 WebSocket 服务是根因，我们做了紧急扩容——增加服务器容量，分担连接压力。
扩容是正确的应急决策：它快速止损，避免了问题继续放大，为后续的分析和修复争取了时间。
但扩容是缓解器，不是根治方案：
三个未解决的问题
- ✗ 没有熔断机制
WebSocket 服务变慢时，柜台服务仍然持续依赖它；没有任何「感知到依赖异常就降级」的能力 - ✗ 没有连接数限流
新连接仍然可以无限制地建立；下次流量峰值来了，同样会崩 - ✗ 没有故障预案
整个定位过程靠人肉排查；下次还是一样慢
下次单边行情来，同样的链路还会以同样的方式崩塌。只是时间早晚的问题。
五、真正的体系化解法
金融系统的稳定性，靠堆机器解决不了，靠体系才能解决。
这次故障之后，我们推动了四个方向的改进：
连接数上限管控
给 WebSocket 服务设置最大连接数限制，超出后新连接排队或拒绝。从根本上限制单次流量冲击的破坏上限，防止资源被无限占用。
外部服务熔断限流
在依赖 WebSocket 的柜台服务侧加入熔断逻辑——当依赖服务响应超时，自动降级而非无限等待。阻断雪崩的传导链，保住核心交易功能的基本可用。
监控告警体系完善
补充连接数趋势监控、服务依赖健康度视图。告警从「单点异常」升级为「链路异常」，能在问题成形之前感知到风险趋势，而不是等到崩了再告警。
故障 SOP 机制建立
针对常见故障类型制定标准化应急预案，明确定位步骤和止血动作。不再依赖个人经验和运气，让任何值班工程师都能在最短时间内完成正确的处置。
| 改进前 | 改进后 | |
|---|---|---|
| 故障发现 | 用户投诉 | 连接数趋势告警 |
| 影响范围 | 全链路雪崩 | 熔断隔离，核心功能保留 |
| 定位时间 | 1–3 小时 | 有 SOP，目标 < 15 分钟 |
| 根本隐患 | 无限连接 + 无隔离 | 限流 + 熔断双重保护 |
六、这不是一家公司的问题
写完这篇复盘，我意识到一件事：这次故障的每一个环节——监控不全面、架构有历史包袱、靠扩容止血、改进不彻底——我在接触过的其他金融公司里，几乎都见过。
这是行业性的体系缺失，不是个别公司的技术失误。大多数金融技术团队都在用大量人力成本维持稳定性，靠经验丰富的工程师「守」着系统，而不是靠体系「管」着系统。
真正的稳定性工程，不是救火，是防火。
当下一次单边行情来临，你们的系统准备好了吗？