如何定位解决问题

6.1 避免问题

1. 为什么会有问题，能不能避免

   随着环境变量增多，也意味着组合越多，出现异常可能性越大，在顶层设计处能解决的问题，直接解决掉，那么后续依赖于此数据的方法，就不需要对相同的问题解决，大大降低解决的复杂度和成本

   常见的使用案例：

   • 断言
   • 数据清洗
   • 数据修复

2. 方法太复杂，出错概率高

   避免上帝类，一个类装载的东西太多，解决的问题太多，违背了单一职责原则，在后期的维护中，维护成本越来越高，因为一旦放开就意味会产生滥用，要避免产生歧义和滥用

   ​

   领域划分，领域自治，领域间依靠事件通信，监听领域变化，完成自身领域的业务

   ​

   

   ​

   ​

​

常见使用案例：

• 跨进程：使用RocketMQ等来实现
• 进程内：使用Spring Event实现

// Spring的事件发布监听
UserCreatedEvent event = new UserCreatedEvent(userPO);
ApplicationContext.publish(event);

@EventListener
publish void handleEvent(UserCreatedEvent event) {
    // create oss bucket
    // ...
    
}

6.2 发现问题

6.2.1 如何发现

• 告警：主动发现

  无法预料的异常：非BizException都属于无法预料的异常，常见的有空指针、转换异常等等

  需要告警的异常：BizException又分为需要告警和不需要告警的异常后，因为一般的校验型业务异常，都不要告警的到开发，一般是作为提示，需要告警的异常，正常在支付时应该已经配置号密匙、商户等信息，但是在客户端请求时未找到，此时因作为环境异常，告警到具体的业务或者开发等等

• 工单系统：被动发现

  当客户遇到支付后，订单支付状态未变更，客户会根据操作指程到工单（客服）系统报告异常，由业务人员到业务平台查找原因

6.2.2 如何复现

场景日志类别：

• 客户端版本等信息
• 接口请求参数信息
• 服务器本身状态信息
• 业务数据信息

6.2.3 谁的问题

在大型系统，不仅企业内部的跨服务、跨部门调用，还有外部企业对接，要定位到哪一个环节出现了问题，避免扯皮

在系统设计，需要前瞻性思考，是否支持定位问题，如果运营反馈线上异常，我怎么知道是不是我负责的模块问题？

一个业务数据流，通常需要一个唯一流水号打通整个流程，这个可以是订单号

一次请求可以用traceId来打通所有调用链

6.3 解决问题

6.3.1 流程缺陷

• 产品设计缺陷

  评审流程是否规范，改进流程

• 研发设计缺陷

  代码评审、测试覆盖率、产品验收标准制定

6.3.3 普通BUG

• 数据订正

  数据备份，回滚方案制定

• 场景复现

  线上测试用例模拟重放

• 回归测试

  相关用例回归，保证覆盖率