OneCode：錯誤碼管理平臺背後的幾點思考

做者：張勝利  轉載至微信公共號：方凳雅集

前言

OneCode是一個阿里內部的錯誤碼管理平臺，簡單來講就是維護錯誤碼和它對應的描述。它是一個極其簡單的一對一關係，對它的操做也是極其簡單的CRUD。在這個「極其簡單」的背後，我想分享一下個人幾點思考。

錯誤碼是有價值的

咱們在每一個系統、每一個應用中都有一套本身的錯誤碼，這自己就代表咱們承認錯誤碼的價值。正如HTTP的Code，一看到5XX，咱們就知道是服務端的問題，一看到4XX，就是客戶端的問題。錯誤碼給咱們提供了一種快速過濾問題的方法。同時，咱們也但願他人在看到錯誤碼時，知道發生問題了和這個問題的緣由，儘管不是每一個人都能作到這一點。好比用戶看到4XX錯誤，知道是己方的緣由，而不是服務提供者的緣由。

因此，錯誤碼給服務提供方提供了一種快速排查問題的手段，給服務消費方提供了一個分析問題的方法。

讓錯誤碼發揮價值

咱們一般採用文檔的形式，維護一份錯誤碼，但這份錯誤碼每每只有幾我的知道，而且也不能保證維護的持續性，在發生問題時，咱們第一反應也不是查找這份文檔，此時，這份錯誤碼並無發揮真正的價值。

什麼叫錯誤碼發揮了價值呢？若是服務消費方看到一個錯誤碼，知道Message或者有地方查詢到對應的Message，並能作出初步判斷；或者服務提供方拿到一個錯誤碼，知道Message，能初步斷定問題的緣由。這兩種狀況，錯誤碼都發揮了價值。

但現實狀況每每會遇到阻力。

1. 錯誤碼透傳問題：咱們指望錯誤碼能夠透傳，返回發生錯誤的錯誤碼，在遇到錯誤時，能夠直接定位到發生問題的地方，減輕運維成本，甚至客服同窗也可根據客戶的錯誤碼反饋，初步作出判斷，但現實是不多有系統作到這一點；
2. 查找錯誤碼描述信息問題：在系統接口調用層會有Message字段，但面向用戶的Message大可能是通過包裝的；在處理問題時，須要找到錯誤碼對應的真實描述信息，在哪裏能夠查找到呢？

因此，錯誤碼發揮價值的簡單斷定方法是：不管是誰，均可根據錯誤碼可初步斷定錯誤的緣由。

錯誤碼服務的人羣

在錯誤碼設計以前，咱們須要先考慮一下咱們的錯誤碼服務的人羣。

錯誤碼的兩端是「提供方」和「消費方」。我想向下深挖一下，誰是提供方，誰是消費方，由於這會影響到咱們如何設計錯誤碼。

對於服務端各系統之間的調用，不管是提供方，仍是消費方，大多都是技術人員。而對於用戶端，提供方是技術人員，而消費方不一而足，咱們簡單的把他們統一爲非技術人員，多是用戶，多是客服同窗，也多是產品或運營同窗等。

因此，錯誤碼服務兩類人羣：技術人員和非技術人員。

錯誤碼的設計原則

不論哪一種設計規則，咱們最終的目的都是：高效的解決問題。在實現這種目的的同時，咱們要考慮服務的對象及服務對象的使用方式，即站在對方的立場上考慮一下。

一般你們在設計錯誤碼規則時，會從「系統 -> 引用 -> 模塊 -> 區分碼」的多維度進行設計，這對於服務提供者來講很是有價值，知道是哪一個模塊出現了問題，但也要有輔助信息幫助瞭解到底哪裏除了問題，好比調用了哪一個方法、Message是什麼。對於服務提供者來講，知道了Message，也大致知道了錯誤是什麼。另外一方面，對服務消費者來講，「系統 -> 引用 -> 模塊 -> 區分碼」這一整套的設計是無感的，徒增理解和交流的複雜度。

OneCode中錯誤碼的惟一原則就是：簡單。更多信息，經過錯誤碼詳情連接的形式觸達。應用的設計主要是爲了權限的控制，固然也可無應用的概念。應用錯誤碼前綴，是對當前大部分已有應用的兼容，無他，更好，尤爲是對非技術人員。

因此，OneCode的錯誤碼設計規則的惟一原則就是：簡單。

OneCode：錯誤碼管理中心

其實，我以爲OneCode像是荒野中的一株綠芽。錯誤碼一直在野蠻中生長，每一個系統都有本身的錯誤碼規則，也有對應的參考文檔。設計錯誤碼之初咱們都有雄心大略，制定標準，持續維護，但結果並不理想。OneCode如今還在生根發芽，還有半片綠葉護身，但願能給你們帶來幫助。