阅读 14

OneCode:错误码管理平台背后的几点思考

作者:张胜利  转载至微信公共号:方凳雅集


前言


OneCode是一个阿里内部的错误码管理平台,简单来说就是维护错误码和它对应的描述。它是一个极其简单的一对一关系,对它的操作也是极其简单的CRUD。在这个“极其简单”的背后,我想分享一下我的几点思考。


错误码是有价值的


我们在每个系统、每个应用中都有一套自己的错误码,这本身就表明我们认可错误码的价值。正如HTTP的Code,一看到5XX,我们就知道是服务端的问题,一看到4XX,就是客户端的问题。错误码给我们提供了一种快速过滤问题的方法。同时,我们也希望他人在看到错误码时,知道发生问题了和这个问题的原因,尽管不是每个人都能做到这一点。比如用户看到4XX错误,知道是己方的原因,而不是服务提供者的原因。


所以,错误码给服务提供方提供了一种快速排查问题的手段,给服务消费方提供了一个分析问题的方法


让错误码发挥价值


我们通常采用文档的形式,维护一份错误码,但这份错误码往往只有几个人知道,并且也不能保证维护的持续性,在发生问题时,我们第一反应也不是查找这份文档,此时,这份错误码并没有发挥真正的价值。


什么叫错误码发挥了价值呢?如果服务消费方看到一个错误码,知道Message或者有地方查询到对应的Message,并能做出初步判断;或者服务提供方拿到一个错误码,知道Message,能初步判定问题的原因。这两种情况,错误码都发挥了价值。


但现实情况往往会遇到阻力。


  1. 错误码透传问题:我们期望错误码可以透传,返回发生错误的错误码,在遇到错误时,可以直接定位到发生问题的地方,减轻运维成本,甚至客服同学也可根据客户的错误码反馈,初步做出判断,但现实是很少有系统做到这一点;
  2. 查找错误码描述信息问题:在系统接口调用层会有Message字段,但面向用户的Message大多是经过包装的;在处理问题时,需要找到错误码对应的真实描述信息,在哪里可以查找到呢?


所以,错误码发挥价值的简单判定方法是:不论是谁,都可根据错误码可初步判定错误的原因


错误码服务的人群


在错误码设计之前,我们需要先考虑一下我们的错误码服务的人群。



错误码的两端是“提供方”和“消费方”。我想向下深挖一下,谁是提供方,谁是消费方,因为这会影响到我们如何设计错误码。


对于服务端各系统之间的调用,不论是提供方,还是消费方,大多都是技术人员。而对于用户端,提供方是技术人员,而消费方不一而足,我们简单的把他们统一为非技术人员,可能是用户,可能是客服同学,也可能是产品或运营同学等。


所以,错误码服务两类人群:技术人员和非技术人员


错误码的设计原则


不论哪种设计规则,我们最终的目的都是:高效的解决问题。在实现这种目的的同时,我们要考虑服务的对象及服务对象的使用方式,即站在对方的立场上考虑一下。


通常大家在设计错误码规则时,会从“系统 -> 引用 -> 模块 -> 区分码”的多维度进行设计,这对于服务提供者来说非常有价值,知道是哪个模块出现了问题,但也要有辅助信息帮助了解到底哪里除了问题,比如调用了哪个方法、Message是什么。对于服务提供者来说,知道了Message,也大体知道了错误是什么。另一方面,对服务消费者来说,“系统 -> 引用 -> 模块 -> 区分码”这一整套的设计是无感的,徒增理解和交流的复杂度。


OneCode中错误码的唯一原则就是:简单。更多信息,通过错误码详情链接的形式触达。应用的设计主要是为了权限的控制,当然也可无应用的概念。应用错误码前缀,是对当前大部分已有应用的兼容,无他,更好,尤其是对非技术人员。


所以,OneCode的错误码设计规则的唯一原则就是:简单


OneCode:错误码管理中心


其实,我觉得OneCode像是荒野中的一株绿芽。错误码一直在野蛮中生长,每个系统都有自己的错误码规则,也有对应的参考文档。设计错误码之初我们都有雄心大略,制定标准,持续维护,但结果并不理想。OneCode现在还在生根发芽,还有半片绿叶护身,希望能给大家带来帮助。


关注下面的标签,发现更多相似文章
评论