事故，以及可以对我们期待什么

我们宕机会对你做什么

会让你停止贷记。这是设计的一部分，也是你在贷记路径前面放一道闸门时接受的交换。

我们返回 5xx 且不带裁决。你的客户端按 HOLD 处理。入金排队。没有任何一笔在我们放行之前被贷记，也没有任何东西丢失——只是这些裁决还没有做出。

不存在任何一种模式，能让我们的不可用变成一个 CREDIT。如果你找到了一个，那是你客户端的 bug，而且它比这次故障更值得你的注意力。

可用性承诺覆盖什么

可用性。只有可用性。

服务水平约束的是 API 是否应答，不是某个具体判断是否正确。我们不对任何执法事件、任何发行方承诺具体的提前量——这个间隔是发行方治理结构的副产品，不是我们供给的能力，发行方随时可以改变执行方式且不告诉任何人。

我们承诺的是：有信号时第一时间送到你手上；看不见时明说，而不是返回一个安静的空结果。coverage_health 就是为此存在的。

我们会告诉你什么，在哪里告诉

渠道	承载什么
运行状态页	当前可用性与进行中的事故。
coverage.health_changed webhook	你账户作用域内的盲区与恢复。
GET /v1/coverage	同样的内容，按需查询，逐权威。
事后复盘	什么坏了、对裁决的影响是什么、改了什么。

覆盖降级与服务不可用是两回事，分开报告。我们可以完全可用却看不见；API 会在每个响应上说出来，而不是让这两者塌缩成同一盏绿灯。

联系我们时手边要有什么

标识符	从哪来
request_id	每个 Problem 响应体上都有。
decision_id	裁决接口任何 200 响应上。
Foreshock-Delivery-Id	webhook 投递的请求头。
event_id	webhook 投递的响应体。
UTC 时间戳	你的和我们的，好把两条时间线对齐。

不要把地址簿、用户数据截图或原始入金记录发给我们。上面这些引用足够我们在自己这一侧定位记录，也是我们唯一会要的东西。

你自己的事故演练

有两种失败值得在发生前先排练。

我们宕机、你在挂起。 谁决定继续挂？谁去和受影响的用户沟通？队列深到什么程度要叫资深的人？答案不能是「我们把闸门关掉」——闸门关掉的那个状态，恰恰是损失真正发生的状态。

你的 webhook 接收端宕了而你没发现。 投递会重试最长 24 小时，然后进死信并在你的账户上告警。把追赶流程排练一遍：从最后持久化的游标跑暴露面游标循环，对账，确认本地匹配集与变更流一致。一个一直安静的接收端，和一个一直安静的世界，在你不去查的时候是分不出来的。

我们永远不会做的事

转移资金。冻结任何东西。代表你行动。产品里没有任何能转移价值的能力，系统里也没有任何能做到这件事的私钥。事故期间我们能采取的动作集合，与平常一天完全相同：告诉你我们看得见什么，以及我们看不见什么。