筆者近期負責提升支付渠道的可用性，做完后有些想法，寫出來和大家分享下。

需求的源頭

用戶在進行支付時，有時候會出現銀行系統不成用、超時情況，導致用戶不知道明確的支付結果，那么用戶80%會進行投訴，客服處理完后，這個用戶就基本上和支付/電商平臺說再見了。

要滿足上面的需求，我們就需要關注以下幾個問題：

銀行系統出現異常是否能及時進行故障隔離？如果要隔離，是否能第一時間發現銀行系統出現異常？如何判斷銀行系統出現了異常，異常的原因是什么？

其實這三個問題對應的解決方案很明確：

Q1——我們需要一個路由系統Q2——我們需要一個監控系統Q3——我們需要一個錯誤碼表

在產品設計過程中，我們根據Q3 → Q2 → Q1這種自下而上的方法去進行。

產品設計我們需要一個錯誤碼表

一家支付公司或電商平臺接入的銀行渠道都很多，而每家銀行都有本身的錯誤返回規范。那么，這時候我們就需要將N家銀行返回的錯誤碼進行抽象，建立一套錯誤碼表。

渠道錯誤碼分類

錯誤碼的拆分維度有很多種，我是根據渠道可用——>用戶信息校驗——>交易來分類的；渠道不成用、用戶信息校驗、交易這3個只是大類，還需要針對每個大類進行二次拆分，細分出小類，小類分的越細，遇到問題定位的也就越快，同時對接下來的兩步也就更有幫手。

我們需要一個監控系統

對于監控系統，存在著一些基本要求：

監控的對象要具體，最好能細分；監控的指標要足夠明確，每一個獨立指標的計算方式要簡單；監控指標要有時效性。

那么，針對支付渠道的監控系統，監控的對象應該要具體到所有接入的銀行渠道；監控指標要對每個銀行進行個性化定制，因為每家銀行的系統性能都紛歧樣；

監控指標設定的維度也很多，因為渠道在整個支付鏈路的底層，對系統層面要求比較高，所以監控的指標如下：

每個渠道調用的平均耗時每個渠道調用的系統成功率每個渠道調用的耗時峰值每個渠道調用的異常訂單數

監控指標的時間跨度建議按照業務量來設置，一般采用秒級或者分級；監控指標定義好后，我們就要為每個渠道設置告警規則，這些規則的閥值需要按照日常的交易情況和每個渠道自身的屬性進行獨立設置；而規則的觸發就要依靠渠道錯誤碼表了。

這樣，監控系統就可以在某個渠道出現問題時，按照錯誤碼表來分析當前的異常屬于哪一類，，是否影響到用戶的正常支付，如果影響了，就會發出告警。

我們需要一個路由系統

一個支付產品最終于能讓用戶順利的&愉快的完成支付；而讓用戶順利的完成支付依賴于出現異常的通道。

能否被及時的隔離掉，同時能否將用戶帶到可以正常支付的通道上，路由功能做的就是這件事情。

為此，我們也需要在路由系統中對每一個渠道設立一個路由規則；這個規則將告訴路由系統當渠道出現問題時，該如何隔離。

路由規則的設定有一種比較簡單的方法：渠道A在｛num｝分鐘內觸發了｛num｝次告警，那么就執行渠道隔離（關閉或者切換）的動作。

這樣在通道出現問題時就可以及時隔離掉，保證用戶正常的支付了。

結語

我們可以把支付渠道可用性看作一個大的系統，這個大系統是由3個獨立的小系統組成的；它是一個自下而上的，閉環的體系；引用《失控》中的思想，一個復雜的系統是由若干個獨立的小系統協同合作組成的，每個小系統越簡單，它們組合在一起后，就能展現出更強大的組織性和發展性。

目前只是建立了一個最原始的生態，還存在著部分的人工干預，那么后期我們就要考慮，現在人做的事情，機器能不能做；我們能不能在用戶提交支付之前就幫Ta選擇好最適合的支付渠道。

標簽：鹽城 林芝 烏魯木齊 九江 東營