> 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/2021/w05-risk-exposure-of-the-payment-sdk.md).

# W05-支付SDK的風險敞口

在B2B支付快驢體驗優化的專項中，為了更好的衡量優化前後的變化，我們重新定義了一套用戶會話級別的指標，期望更客觀的描述B2B的用戶體驗與服務性能。其中一項工作是，按照新版的指標結構，對目前JS SDK版本的上報數據進行補充。

JS SDK對於收銀臺來講是至關重要的一部分，收銀臺絕大多數的流量都要通過該SDK來使用支付服務，預估日均調用量在50W左右。由於影響面過大，我自己一直對SDK改動的閾值比較高。加上其邏輯穩定性也很強，做B2B支付的一年來，沒有過任何迭代。

補充埋點數據的開發量和動作幅度本來都很小，但準備發佈上線時，我硬是拖了一週。不是拖延，是不敢。上線這個過程，一路的風險敞口，實在需要些時間做做心理建設。

SDK發佈的流程給人的感覺就是不可控。體現在可視化程度不高，關鍵節點缺少操作抓手。這個SDK是託管在Burst上的，看過Burst的dashboard和規劃後，會有一些年久失修的意思。提交代碼後，上線這個動作僅依賴一個Burst提供的命令行。這個命令行執行的過程是個黑盒，執行完成後，意味著Burst的回源機器已經更新了資源。接著需要手動刷新CDN，這個過程，就像是你吹了一支蒲公英，完全不知道它怎麼飄，最後落在何處。CDN各個節點的刷新進度，是否已經全量，由於端上的緩存，用戶什麼時候可以用上最新版本的SDK，這些全靠經驗猜測。整個過程無法灰度放量，沒有快速的回滾方案，更重要的是，這個過程完全靜默，沒有任何審批和相關人通知。

發佈後，我們只能監控到SDK的內部異常，對於調用量，服務穩定性等技術參數則依賴於Burst和CDN廠商的信息，但數據完備性和準確性存疑。

對於上述遇到的問題，請教了owl和lx，這塊大家都沒有一個完美的方案，但給我們後續的發佈治理提供了一些啟發。JS SDK與Native SDK之間一個很大的不同是，完全動態化後所帶來的對版本管理的挑戰。如果業務方引入SDK的url不能變，那麼就相當於對業務方隱藏版本的概念。

同時，SDK內部也有一些其他問題，比如對全局window對象的汙染。今年會把SDK的治理列入B2B的前端規劃。不然現在日均幾十萬單還是小問題，日後百萬單的時候就是個大隱患了。