分布式系统设计里常见的反模式在设计时把失败写出来可靠性也来自可观察性。关键动作记录关联标识、状态变化和重试次数但日志不应包含多余的个人数据或凭据。通过这些记录值班人员才能将用户反馈对应到具体链路并确认补偿是否完成。若某类失败无法自动恢复应把升级路径告诉用户和支持人员而不是悄悄吞掉错误。可靠性也来自可观察性。关键动作应记录关联标识、请求来源、状态变化和重试次数但日志不应包含多余的个人数据或凭据。通过这些记录值班人员才能将用户反馈对应到具体链路并确认补偿是否真正完成。接口文档应明确可重试、不可重试、结果未知和人工介入等状态。客户端不能只根据成功码猜测业务完成服务端也不能在部分失败时沉默。定期让下游超时、消息重复或消费者不可用检查告警、重试和人工操作是否符合设计发现的问题回写到契约与监控中。接口文档应明确成功之外的结果可重试错误、不可重试错误、请求已受理但结果未知以及需要人工介入的状态。客户端不能只根据 HTTP 成功码猜测业务完成服务端也不能在发生部分失败时沉默。对外展示什么状态应与内部补偿流程一致。故障演练可以从一条关键链路开始让下游超时、让消息重复、让消费者短暂不可用观察告警、重试和人工操作是否符合设计。演练发现的问题回写到契约和监控而不是只留在一次复盘文档中。每个跨服务动作都应有唯一标识并定义重复到达时如何处理。同步调用要有超时、取消和有限重试重试的间隔与上限应按依赖能力设置而不是所有错误都立即再试。对付款、库存等敏感动作调用方和接收方都应保存可对账的状态。异步并不等于没有责任。事件发布后若消费者失败需要知道谁负责重放、何时告警、如何避免重复副作用。补偿操作也要像正常接口一样设计权限与审计不能把“以后人工修”当作唯一方案。评审可以用故障问题替代架构口号消息晚到怎么办两个操作顺序颠倒怎么办依赖只成功一半怎么办用户重新提交怎么办。把答案写进接口契约和运行手册比在故障发生后临时猜测可靠得多。分布式系统的故障常常不是网络本身造成的而是设计没有写清失败语义。第一类问题是把重试当成免费保险。没有幂等键的重试会制造重复订单、重复通知或重复扣费。第二类问题是用同步调用串起所有环节任何慢依赖都能拖住整条链路。可以异步处理的索引、通知和统计应使用明确的事件与补偿机制。评审时不要只画成功路径。超时、部分成功、消息重复和顺序颠倒发生后谁负责恢复、用户看到什么、数据如何核对都应当提前说明。组件变多不等于系统更可靠能处理失败才算可靠。