题干与适用场景
你的 B2B SaaS 通过 Webhook 把账单、权限或订单事件发送给客户。客户经常因为自己的端点超时、返回 5xx 或部署失误而漏处理事件，支持团队只能手工查日志。请判断是否应提供客户可用的事件重放控制台，并说明 MVP、指标与边界。
这是一道产品与 integrations 面试题。公开的 integrations 面试题把重放处理、幂等、退避和客户可见健康面板列为回答要点；Stripe 文档说明事件可能重复、无序，失败会自动重试，Dashboard 与 CLI 还提供不同的手动重试窗口；GitHub 文档也把失败交付的重新投递作为 Webhook 能力的一部分。
面试官考察点
面试官要听到你把“客户想要一个按钮”拆成问题规模、风险、价值和可交付范围。强回答会区分自动重试与人工重放、消息到达与业务成功、原始事件与新投递尝试，并说明谁能重放、能重放多久以及如何避免重复副作用。
普通回答只说“做一个重试按钮”。强回答会提出事件保留、权限、审计、限流、幂等提示、失败原因和成功标准，并说明什么时候不该做通用重放，而应优先提供查询 API、对账或人工支持工具。
回答前需要澄清的问题
- 客户要恢复的是“未送达事件”，还是要把已送达事件再次发送给新端点？后者需要不同的权限和数据保留策略。
- 事件是否包含个人数据、支付数据或租户机密？这决定脱敏、加密、导出和操作审计要求。
- 当前自动重试覆盖多久、失败率和支持工单占比是多少？没有基线就无法证明控制台创造价值。
- 客户端是否已经用事件 ID 做幂等？如果没有，产品必须明确重放可能再次触发副作用。
30 秒回答框架
“我会先验证失败交付的规模、客户损失和支持成本，再决定是否做。若价值成立，我会先做只针对失败事件的重放：保存不可变载荷和投递结果，限制租户管理员在保留窗口内操作，执行限流、权限和审计，并把每次重放视为一次新的投递尝试。指标看恢复成功率、重复副作用、支持工单和存储成本；若数据敏感或客户端没有幂等，我会先提供对账和人工审批，而不是开放任意重放。”
分步骤深入解答
先画出现状链路：事件产生、签名、投递、客户返回状态、自动重试、最终失败。Stripe 的公开行为显示，生产环境会进行指数退避重试，Dashboard 手动重试窗口可到事件创建后 15 天，CLI 可到 30 天；这些数字应作为竞品参考，不能直接当成你的产品承诺。失败事件要记录端点、状态码、响应时间、最后一次尝试和下一步动作。
再做价值判断。若失败事件少、客户能通过拉取 API 自行补偿、重放会引发高额重复扣款，先做查询与对账更稳妥。若失败集中在部署窗口，且支持人员反复执行同一恢复动作，控制台能把恢复时间和支持成本降下来。成功标准应同时包含恢复成功率、重复业务操作率、每个租户的重放量和数据保留成本。
MVP 只允许重放“最终失败且仍在保留期内”的事件。事件载荷保持不可变；按钮创建一个新的 delivery attempt，带原事件 ID、attempt ID、操作者、原因和时间。签名、时间戳和重放标记的具体格式要与现有协议兼容，不能让客户误以为这是首次发送。对于敏感载荷，默认遮蔽正文，只给状态和事件 ID，必要时走二次授权。
幂等与顺序必须显式处理。Stripe 明确不保证事件顺序，也提醒端点可能收到同一事件多次，因此产品应在界面和文档中要求按事件 ID 去重，并提示“重放不会撤销已发生的业务副作用”。如果客户需要补齐中间事件，提供按时间范围筛选和逐个确认，避免一次性重放整段历史。
安全和成本是发布门槛：仅租户管理员或特定权限可操作；每租户和每端点设置速率上限；重复点击使用幂等键；审计日志记录操作者、事件、目标端点和结果；保留期限、加密和删除策略与隐私政策一致。批量重放应排队并可取消，避免把恢复动作变成新的流量洪峰。
替代方案有三种。第一，继续依赖自动重试和支持团队手工操作，开发成本最低但恢复慢且不可规模化。第二，只开放事件查询与拉取 API，把补偿逻辑交给客户，适合有成熟工程团队的客户。第三，做完整事件仓库和任意时间范围回放，能力最强但存储、合规和误操作风险最高。MVP 选择失败事件重放，只有当指标证明客户确实需要历史回放时才扩大范围。
高质量示范回答
我不会把它定义成“要不要加一个按钮”，而会先看失败交付的后果。假设失败主要发生在客户发布期间，支持团队每周都要人工确认并重新发送，且事件载荷可以按租户加密保存，我会做一个受限 MVP。第一版只展示最终失败事件，保存不可变载荷、状态码和最近尝试；租户管理员在 15 天的默认保留窗口内发起重放，每次操作都要有权限、原因、限流和审计记录。重放创建新的投递尝试，不改变原事件 ID，并明确要求客户按事件 ID 幂等。
我会同时保留自动重试，因为手动重放不能替代正常交付。指标包括失败事件恢复率、重放后的重复副作用、支持工单解决时间、每租户重放量和存储成本。若重复扣款或隐私风险上升，我会先收紧到人工审批或只开放对账 API；若恢复率和支持成本都改善，再考虑批量重放与更长保留期。
常见错误
- 错误表现 → 把重放当作再次触发业务；失败原因 → 客户可能已处理成功但响应丢失；修正方法 → 将投递尝试与业务事件分开，要求事件 ID 幂等。
- 错误表现 → 允许用户编辑历史载荷后直接发送；失败原因 → 破坏签名、审计和事件事实；修正方法 → 原始载荷只读，测试变体进入隔离的沙盒流程。
- 错误表现 → 默认永久保存所有 Webhook 正文；失败原因 → 放大隐私、合规和存储成本；修正方法 → 设租户级保留、加密、删除和脱敏策略。
- 错误表现 → 用“重放次数”作为唯一成功指标；失败原因 → 重放越多可能表示系统越不可靠；修正方法 → 结合恢复率、重复副作用、支持成本和端点健康度。
追问及应对
如果客户要求重放 90 天前的支付事件，你改什么？
先验证是否仍有合法保留依据，以及原始载荷是否包含支付或个人数据。若没有长期保留必要性，我会提供事件 ID、当前资源查询和对账结果，不直接恢复正文。若业务确实需要 90 天恢复，则采用分层存储、租户授权、二次审批和更严格审计，并把长期存储成本计入套餐或用量。
如果重放后客户发生重复扣款，谁负责？
产品不能用免责声明替代控制。界面应显示事件已可能成功、要求客户端幂等，并对高风险事件默认关闭自助重放或要求二次确认。服务端按事件 ID 和 attempt ID 记录，提供预览、速率限制和撤销排队任务；责任边界写入协议，同时保留可调查的审计链。
如果一次端点故障影响一百万个事件，如何避免恢复造成新事故？
先暂停自动重放，按端点健康度和错误类型分批恢复。队列设置每租户配额、指数退避、并发上限和熔断；先发送小样本，观察 2xx、延迟、重复副作用和下游队列深度，再逐步放量。控制台展示预计排队量和取消入口，支持团队可在异常时停止批次。
为什么不直接提供任意时间范围的全量回放？
任意回放把查询、合规和业务补偿混成一个危险操作。除非已有稳定事件仓库、版本化载荷、权限模型和客户幂等基础，否则先解决最终失败事件的恢复闭环。产品路线应由失败分布、客户价值和安全证据推动，而不是由功能完整度推动。