Stripe把800美元坑没了，他花3小时写了个监控

Stripe的Webhook（网络钩子）出问题的时候，你的订阅收入会像漏水的水管——悄无声息地流失。一位开发者最近吃了这个哑巴亏：一笔800美元月经常性收入（MRR）的流失，他直到客户投诉才发现。

这不是Stripe的bug，是监控的盲区。Webhook（网络钩子）是Stripe向你的服务器推送事件通知的机制，相当于订阅业务的神经系统。它正常工作时你毫无感知，崩溃时往往已经造成损失。

他花了3小时搭了一套实时异常检测系统。核心思路很简单：不再定时扫日志，而是让每个事件触发即时分析。

为什么定时检测不够用

常见的Webhook故障模式有四种：签名验证失败导致事件被丢弃、处理超时触发Stripe重试风暴、数据库写入失败造成静默丢单、以及欺诈攻击引发的短时支付异常。

Stripe后台不会自动标记这些问题。你看到的只是"事件已送达"的绿色对勾，至于你的服务器有没有正确处理、数据库有没有写入、业务逻辑有没有跑完——它不管。

定时任务的问题在于粒度太粗。如果你每15分钟扫一次日志，可能错过一场5分钟的欺诈攻击。事件驱动的检测把延迟压到秒级，异常发生时立刻告警。

架构设计很直接：Stripe推送事件 → FastAPI接收端 → 事件存储（SQLite/Postgres）→ 检测引擎 → 告警路由（邮件/Slack/Webhook）。

接收端的两个铁律

代码实现上有两条不可妥协的规则。

第一，必须验证签名。Stripe用HMAC-SHA256对payload签名，你的服务器要用Webhook密钥重新计算比对。跳过这步等于给伪造事件开门。

第二，必须先返回200，再做重活。Stripe的超时窗口很短，处理超时它会认为投递失败并发起重试。重试风暴可能压垮你的服务。正确做法是：收到事件立刻acknowledge（确认），异步处理后续逻辑。

检测引擎的设计是函数式流水线。每个检测器接收事件，返回Alert对象或None。这种设计让新增规则变得 trivial——写个函数扔进去就行。

一个具体检测器的实现

以"支付失败率异常"为例。检测器监听charge.failed和charge.succeeded两类事件，回溯过去1小时的数据。样本量不足10笔时保持沉默，避免误报。

当失败率超过阈值（比如15%），它生成一个包含严重级别、检测器名称、事件ID的告警对象。严重级别分四级：low/medium/high/critical，critical直接触发PagerDuty。

这种设计的关键是状态本地化。检测器不依赖外部状态服务，只查询事件存储。水平扩展时，每个实例都能独立运行，无需协调。

告警路由层支持多通道。Slack用于日常观察，邮件用于中等优先级，Webhook用于集成现有运维体系。 critical级别的告警会同时触发所有通道，确保不被淹没。

整个系统的资源消耗很低。SQLite在单机上能撑到每秒数千事件，Postgres则提供更高的并发和持久化保证。对于年营收百万美元级别的订阅业务，这套架构的硬件成本接近于零。

作者把代码开源了。但比代码更有价值的是这个思路：把监控从"事后审计"变成"实时免疫"。