大多数讲 Webhook 可靠性的文章，都把丢失的事件当作数据问题。少了一行记录，你迟早会发现，然后回填。烦人，但可恢复，而且工程团队以外的人基本看不见。
身份事件打破了这种看法，因为两个方向并不对称。
一个始终没到达的 access.granted 事件，会造成一个进不去的用户，而进不去的用户几分钟内就会告诉你。它会自己上报。这个系统免费内置了一层由人构成的告警。
一个始终没到达的 access.revoked 事件，会造成一个仍然进得去的用户。没人会上报这件事。从中受益的人没有理由提起，其他人则都相信离职流程已经完成，因为你的身份认证平台说已经完成了。这个缺口会一直存在，直到审计发现它，而那可能是一年以后。
TL;DR
- 漏掉一次授权，是一张工单。漏掉一次撤销，是一扇没装警报的敞开的门
- 你的身份认证平台的控制台显示撤销成功了，因为在它那一侧确实成功了
- Clerk，以及其他基于 Svix 构建的产品，会在约 27.5 小时内尝试 8 次，然后在连续 5 天全部失败后停用端点
- 端点被停用本身就是一种无声的状态，而这恰恰是最要紧的那个状态
- 把 Webhook 接收端的可用性当作一项访问控制，而不是基础设施层面的日常维护
控制台显示不出来的失败
管理员把某人移出组织。身份认证平台更新自己的记录，让自己的会话失效，然后向你的端点发出 organizationMembership.deleted、user.deleted 或 session.revoked。
你的端点正在部署中，返回了 502。
在身份认证平台的控制台里，这条成员关系已经没了。在管理员看来，离职流程已经完成。你的应用里却还留着一行记录，说这个人是该组织的成员，而你基于最初那次授权签发的缓存会话或 API 令牌也仍然有效。
任何有人会看的地方都不会出现错误。平台的 Webhook 日志里确实有一次失败的投递，但除非已经怀疑出了问题，否则没人会去读 Webhook 日志。
重试能为你争取时间，然后就停了
Clerk 通过 Svix 发送 Webhook，不少其他身份认证和基础设施产品也是如此。它的重试计划是公开的，值得准确了解，因为它精确规定了你的端点能坏多久，Svix 才会停止重试一次撤销。
共八次尝试：“立即、5 秒、5 分钟、30 分钟、2 小时、5 小时、10 小时、10 小时（均在前一次之后累加）。”
总共约覆盖 27.5 小时，确实很大方，在我们的 Webhook 平台参考收录的发送方里也属于最长的一档。一次部署窗口、一次事故、一个糟糕的周五：都能从容扛过去。第八次尝试之后，Svix 会发送一个类型为 message.attempt.exhausted 的运维 Webhook，但只有当你给运维 Webhook 配了去处时，它才有用。
然后是第二道门槛：“如果发往某个端点的所有尝试在 5 天内都失败，该端点将被停用，并向你的账户发送一个运维 Webhook（EndpointDisabledEvent）。”这个计时还有一个限定条件：“只有在 24 小时内有多次投递失败，且第一次和最后一次失败相隔至少 12 小时，计时才会开始。”
仔细看停用状态。一旦端点被停用，新事件就不会再为它排队。你修好端点之后，它们也不会再被投递。这段时间里的每一次撤销都会一直处于未送达状态，直到有人发现并手动重发；而唯一的通知，是一个发往某个没人配置过接收地址的账户的运维 Webhook。
这种不对称是设计的输入
一旦你接受两个方向的代价不同，一些寻常的决策就会随之改变。
对移除访问权限的事件，要失败即拒绝（fail closed）。如果你的处理程序处理不了 session.revoked，正确的做法不是返回 200 再记一条警告。要返回 5xx，让重试计划启动起来，并确保你自己的告警会触发。对授权，你可以乐观一点。对撤销，你不能。
不要只依赖 Webhook。推送事件是对时延的优化，不是事实来源。定期调用身份认证平台的 API 对账，问一句“现在谁应该有访问权限”，就能把一次永久漏掉的撤销，变成下一轮扫描时自动修复的问题。这和 Webhook 与轮询里讲的混合方案是同一个道理，而身份认证正是它不再可选的场景。每小时跑一次，最坏的情况就是一小时的过期访问，而不是永远。
让你自己签发的会话按时过期。如果你的应用基于身份事件签发自己的会话或令牌，较短的 TTL 加上刷新时重新检查成员关系，就能让漏掉的撤销自行过期失效。长期有效的令牌，会把一次漏掉的 Webhook 变成无限期的访问。
这里顺序也很重要。一个在 member.removed 之后被重试的 member.added，会把你刚移除的人重新加回来，而没有任何事件被处理两次。版本保护模式，也就是只有当更新的时间戳比该行更新时才应用它，见同一个 Webhook 收到了两次。对访问控制来说，与其依赖时间戳比较，不如直接拒绝非法的状态转换。
弄清楚端点被停用时是什么样子。这是这一整类问题里最有价值的一个告警。如果你的身份 Webhook 安静的时间超过了平常的间隔，就说明出了问题，而“安静”正是停用状态的典型症状。一个“工作时间内 6 小时没有任何身份事件”的检查就能发现它。别的都发现不了。
审计问题怎么办
如果你要应对 SOC 2、ISO 27001 或任何客户的安全问卷，里面都会有一个关于及时撤销访问权限的问题。如果你的撤销路径只有一个 Webhook、没有对账，那么诚实的回答是：撤销访问通常很及时，除了它静默地没有发生的时候，而事后你分辨不出这两者。
这很难写进文档。但它可以用两样东西修好：一份记录每个到达的身份事件的持久化日志，以及一个你能拿出输出结果的对账任务。日志回答“我们被告知了什么、在什么时候”；扫描回答“我们有没有据此行动”。为什么一行可修改的数据库记录不足以回答第一个问题，我们在可检测篡改的 Webhook 日志里写过。
AnyHook 能做什么
结构上的问题在于：你的接收端的可用性已经成了访问控制的一部分，而建在应用基础设施上的接收端，继承的是应用的可用性。
把身份认证平台指向 in.anyhook.net/you/identity，就能把两者分开。AnyHook 在边缘节点保存事件并应答，约 1 秒完成，所以你这边的一次部署、一次冷启动或一次数据库宕机，根本不会造成投递失败。在此基础上：
- 对你自己端点的重试按 5 分钟、30 分钟、3 小时、18 小时，之后每天一次进行。在 Scale 套餐上（约 6 天），这比 Svix 的 27.5 小时更久；在 Pro 套餐上，最后一次尝试大约在第 22 小时，Free 套餐则在第 35 分钟，再往后，你要重放的就是已保存的事件
- 每一次撤销都在尝试投递之前保存下来，并做静态加密，所以“我们到底收没收到”有一个独立于你的应用日志的答案
- 有了按时间范围重放，出问题的部署窗口只需要重放一遍，而不必人工审计谁本该失去访问权限
- 连续失败 1 次、5 次和 20 次时的失败告警，远在任何平台的停用门槛之前就会到达
这些都不能取代对账扫描，你仍然应该跑一个。转发服务会保存它接收的每个事件；只有扫描能发现根本没发出的东西。
总结
授权会自我纠正，因为受影响的人会投诉。撤销不会，因为受影响的人不会投诉。正是这一点不对称，让身份 Webhook 值得比你其他集成更严格的可靠性标准，尽管它们的请求体看起来没什么两样。
移除权限时失败即拒绝，让你自己的会话过期，跑对账扫描，并给意外的安静加上告警。否则，你得到的就是一项故障模式为沉默的安全控制。