答案。

在分布式IT系统发展历程中，错误处理和故障场景的问题长期处于次要地位，让位于业务逻辑。然而，随着规模的扩大和基础设施的复杂化，逐渐证明未充分处理的错误场景会导致大规模故障和数据丢失。

问题在于，复杂系统会经历多种类型的故障：从个别服务不可用到数据不一致或通信通道的部分故障。客户常常仅将“故障”理解为明显的故障（例如，服务器不可用），而忽略了服务间错误的链条或用户体验的恶化。

有效的解决方案基于系统方法：

• 发现所有可能的故障点。
• 与架构师、QA、设计师和运维工程师共同开发详尽的故障场景。
• 与业务部门协调系统的行为（例如，是否可以延迟订单或需要缓存操作）。
• 对所有错误消息和处理路线进行明确文档记录。

关键特点：

• 处理不仅是致命的，还包括软性/浮动故障（例如，外部服务的临时不可用）。
• 包括UI功能和功能退化的场景。
• 在需求开发的所有阶段区分业务错误和技术故障。

渗透性问题。

应用层异常和基础设施层异常之间有什么区别？

候选人经常将业务错误（例如，“用户未找到”）与真实故障（例如，“数据库不可用”）混淆。应用程序必须清晰地区分这两类异常，并提供不同的处理策略（回滚、通知、警报）。

对于内部API，应该模拟哪些故障场景，如果它不是公开的？

故障场景对任何API都是相关的：即使是内部API，故障随时可能发生（即使在同一自动化环中），必须明确模拟，以便能正常处理不可靠/缺失的数据。

为了最大化用户体验，系统是否应当隐藏所有错误？

不，可以完全隐藏错误会导致用户误导。重要的是在信息量（让用户理解下一步该怎么做）和安全性（不泄露实现细节）之间找到平衡。

常见错误与反模式

• 非正式的故障处理（留在“默认”捕获中）。
• 在部分故障情况下缺乏退化场景（例如，微服务的示例——不工作购物车完全阻止订单处理）。
• 忽视“静默”故障的积累（没有针对特殊情况的警报/监控）。

实际案例

负面案例： 在一个大型电子商务项目中，业务分析师将所有网络错误的处理留给架构决定。在紧急更新和邮件服务故障时，系统未发送订单通知，用户无法理解他们的订单是否已创建。

优点：

• 简化了需求描述。

缺点：

• 数据丢失（无法证明订单的创建）。
• 产品上线后的维护成本增加。

正面案例： 业务分析师与架构师为每个关键服务建模了单独的场景：邮件队列不可用、支付网关失效、搜索服务退化。为客户编写了用户友好的消息。

优点：

• 增强客户对平台的信任。
• 最小化运营风险。

缺点：

• 文档量和测试复杂性增加。