> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2020/w29-business-metrics-monitoring-and-end-to-end-canary-releases.md).

# W29-業務指標監控 & 全鏈路灰度

基於週三美支的線上case，發散出兩點思考。

首先是一個簡短的回顧與復盤。這個case我基本參與了全程的幾個關鍵節點，從問題發現、響應、排查、到消除影響。雖然最終影響範圍和造成的後果不算特別嚴重，但事後回看，一路風險敞口**，某種程度上暴露出了我們自身的系統性風險，絕對值得引以為鑑**。

* **問題發現與響應，被動遲緩。**問題發生所屬通道為網銀支付，用戶跳轉到網銀後，上下游鏈路都在等統一支付的成功回調。恰恰用戶支付流程的異常發生在網銀側，收銀臺前後端均不感知。所以本次問題發現的路徑為，客戶反饋到業務方，業務方反饋到收銀臺。導致到週三下午接到大量反饋後，我們並不清楚這個問題發生了多久，是哪個版本引入的。這就給排查階段帶來了更大的困擾。
* **問題排查，混亂無序。**如上所述，由於無法確定引入問題的版本，整個排查是從前端到最下游的全鏈路排查，所有的角色都參與了進來，現場混亂無序。處理問題的第一反應應該是止損，及時回滾，但在當時的處境中，大家都不知道是哪個節點，在哪個時間，上線的哪個版本導致的，所以問題定位就花費了比較長的時間。

以上，給我的啟發有兩點。

* **一是堅決推進業務指標監控。**對於支付來講，最重要的業務指標就是**支付成功率**，最初我對這個指標的實時監控所帶來的收益並不太理解，但這次case給了我推動業務指標實時監控的動力。對於依賴第三方的場景，比如跳轉網銀、微信、支付寶等等，我們並不感知依賴方的異常，只有通過支付成功率的實時監控才可以發現。目前B端支付成功率為D+1報表生成，並未實時，更無監控。**如果要推動實時監控，有兩條實施路徑。**一條是推動收銀臺後端和數據團隊進行能力建設。之前有嘗試過，但對方動力不足，不排除本次case後態度轉變的可能性。一條是前端通過raptor自行建設。前端可以通過自定義複合指標，對支付成功率的環比趨勢進行監控，雖然前端的數據絕對值並不準確，但足以滿足及時發現問題的需求。**在Q3規劃中，收銀臺前端的監控體系建設將會作為重點進行規劃。**
* **二是推進B2B支付全鏈路灰度。**case發生後，美支側拉了優化監控報警的專項群，藉此機會可以對前後端全鏈路灰度進行推進。收銀臺前端目前可選灰度策略有二。一是按照tradeno訂單尾號分流，但會出現一個用戶多次下單，跳轉至不同版本收銀臺的問題，嚴重影響體驗。二是在前端上線灰度機器後，配置白名單用戶，進行線上驗證。驗證通過後，發佈至全量。以上都不是最優方案。**希望在Q3建立以用戶唯一標識為線索的全鏈路灰度，保證後續版本迭代的安全平穩，以及為A/B Test鋪墊基礎能力。**