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的前端规划。不然现在日均几十万单还是小问题，日后百万单的时候就是个大隐患了。