监控与恢复
当预言机掉线、结算根滞后、队列积压或压力事件拓宽价差时,对资金交易者而言唯一重要的问题是出纳是否仍然可用。本页列出监视每个支付管道的四条监控轨道、每类故障的恢复姿态、可以在单笔交易内停止存款或提款的守护者暂停权限,以及恢复服务的已公布 SLA。目标是具体的:Sumsub 级 KYC 通过后 24 小时的支付窗口、对每个数据源与队列信号的亚分钟级检测,以及事件后在运营渠道公布的完全可见的对账。
四条监控轨道持续运行。每一条都有定义好的检测阈值、值班路由规则与有据可查的响应姿态——降级的平台状态总是在波及提款管道之前变得可见。
| 运营信号 | 检测目标 | 响应姿态 |
|---|---|---|
| 数据源新鲜度与市场姿态 | 预言机过期超出每源新鲜度预算;跨源分歧超出容忍;相对参考交易所的标记漂移 | 受影响市场在一个区块内切换为受约束模式(降低最大杠杆、加宽区间、不允许新增开仓) |
| 根发布与活跃度 | 距上次 commitSettlement 的时间、待处理提款的队列深度,以及运行时发布延迟 | 达到阈值时触发运营呼叫;若延迟超过 disputeWindowSec 且发布未恢复,则启用守护者暂停 |
| 网关与认证健康度 | 每层的认证错误率、跨层权限泄漏尝试、已签名订单重放尝试、速率限制饱和 | 每层的面级熔断器;准入层故障永远不会向运营者或多签面级联 |
| 国库与对账状态 | 运营钱包与深度冷存金库余额漂移、手续费清扫会计差异、保险储备敞口比率 | 每日向运营多签提交对账报告;任何超过 $1K 的未对账漂移在解决前阻止下一次手续费清扫 |
#平台持续监视什么
每个信号都喂入同一个值班传呼——跨越创始团队与工程负责人的单一轮值。没有安静时段。预言机与数据源告警直接路由到交易服务值班;根与发布告警路由到运行时值班并抄送运营负责人;网关与认证异常路由到平台值班;国库与对账漂移路由到运营多签签署人,因为任何以 Base 交易结束的事项都需要被请求共同签署修复的签署人在场。
每个信号也喂入公共平台面。受约束的市场在每个下单票据与订单簿头部显示其状态,并标注原因(预言机过期、源分歧、标记漂移)。待处理提款显示门控条件(根尚未提交、disputeWindowSec 进行中、人工审核、KYC 待办),使资金交易者无需联系客服就能读到其出纳为何被暂停。仍然把自己呈现为正常的降级平台,被视为比底层降级更严重的故障。
发布遵循同样的纪律。运行时与合约变更在部署前要通过回归与冒烟套件;合约升级要额外通过带 3-of-5 治理多签的安全审查窗口与 24 小时提案可见性延迟。运营性漂移——队列调优、数据源权重变更、权限轮换——在运营渠道记录,带上负责签署人与回滚路径。协议不仅由代码保障安全;它也由代码在生产中被变更、发布与监控的纪律来保障。
信号转为不健康
-> 市场姿态收紧或网关熔断器跳闸
-> 受影响面为用户标注其状态
-> 值班被传呼,国库类事件通知签署人集合
-> 若降级越过安全阈值,启用守护者暂停
-> 恢复等待新鲜数据 + 健康发布 + 已对账国库
-> 只有 3-of-5 治理多签可解除守护者暂停#恢复应如何运作
恢复是分级的,不是开关式的。在任一受保护面恢复完整权限之前,四个条件必须同时成立:预言机新鲜度已在预算内连续保持至少恢复后的浸泡窗口;运行时已提交合约接受为在历史中的结算根;网关层在公开、已认证、已签名订单与运营者四个面上的健康度全部为绿;运营钱包与深度冷存金库之间的对账完全匹配且无未解决漂移。任何一项缺失条件都会让受影响面保持在受约束模式。
对资金交易者而言,已公布的 SLA 是关键边界。低于 $5K 且不属于排行榜领奖台前三的提款,目标是 Sumsub 级 KYC 通过后 24 小时内释放;对已通过首付审核的用户,在门控条件清除后 4 小时内释放。高于 $5K 或位于领奖台前三的提款,从运营 2-of-3 多签开启审核工单起,目标同样为 24 小时窗口——较长的尾部是审核时间,而非签署时间。任何暂停提款的事件之后,解除暂停时会附带一份已发布对账,展示原因、受影响的余额状态以及按账户的修复。在事件发生之前应付的任何支付都不会因该事件而减少;保险储备为恢复过程产生的任何缺口提供兜底。
这就是 Dexter 所遵循的标准。秒级检测、一个区块内的姿态变更、每个降级面上的透明、只有在独立条件重新汇合后才进行恢复,以及一个多签将兑现或公布无法兑现原因的 24 小时出纳目标。