0
点赞
收藏
分享

微信扫一扫

如何定位解决问题

6.1 避免问题

  1. 为什么会有问题,能不能避免
    随着环境变量增多,也意味着组合越多,出现异常可能性越大,在顶层设计处能解决的问题,直接解决掉,那么后续依赖于此数据的方法,就不需要对相同的问题解决,大大降低解决的复杂度和成本
    常见的使用案例:
  • 断言
  • 数据清洗
  • 数据修复
  1. 方法太复杂,出错概率高
    避免上帝类,一个类装载的东西太多,解决的问题太多,违背了单一职责原则,在后期的维护中,维护成本越来越高,因为一旦放开就意味会产生滥用,要避免产生歧义和滥用

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

如何定位解决问题_复杂度


常见使用案例:

  • 跨进程:使用​​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 谁的问题

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

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

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

如何定位解决问题_数据_02

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

如何定位解决问题_复杂度_03

6.3 解决问题

6.3.1 流程缺陷
  • 产品设计缺陷
    评审流程是否规范,改进流程
  • 研发设计缺陷
    代码评审、测试覆盖率、产品验收标准制定
6.3.3 普通BUG
  • 数据订正
    数据备份,回滚方案制定
  • 场景复现
    线上测试用例模拟重放
  • 回归测试
    相关用例回归,保证覆盖率
举报

相关推荐

0 条评论