> 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/2020-nian/w29-ye-wu-zhi-biao-jian-kong-quan-lian-lu-hui-du.md).

# W29-业务指标监控 & 全链路灰度

基于周三美支的线上case，发散出两点思考。

首先是一个简短的回顾与复盘。这个case我基本参与了全程的几个关键节点，从问题发现、响应、排查、到消除影响。虽然最终影响范围和造成的后果不算特别严重，但事后回看，一路风险敞口**，某种程度上暴露出了我们自身的系统性风险，绝对值得引以为鉴**。

* **问题发现与响应，被动迟缓。**问题发生所属通道为网银支付，用户跳转到网银后，上下游链路都在等统一支付的成功回调。恰恰用户支付流程的异常发生在网银侧，收银台前后端均不感知。所以本次问题发现的路径为，客户反馈到业务方，业务方反馈到收银台。导致到周三下午接到大量反馈后，我们并不清楚这个问题发生了多久，是哪个版本引入的。这就给排查阶段带来了更大的困扰。
* **问题排查，混乱无序。**如上所述，由于无法确定引入问题的版本，整个排查是从前端到最下游的全链路排查，所有的角色都参与了进来，现场混乱无序。处理问题的第一反应应该是止损，及时回滚，但在当时的处境中，大家都不知道是哪个节点，在哪个时间，上线的哪个版本导致的，所以问题定位就花费了比较长的时间。

以上，给我的启发有两点。

* **一是坚决推进业务指标监控。**对于支付来讲，最重要的业务指标就是**支付成功率**，最初我对这个指标的实时监控所带来的收益并不太理解，但这次case给了我推动业务指标实时监控的动力。对于依赖第三方的场景，比如跳转网银、微信、支付宝等等，我们并不感知依赖方的异常，只有通过支付成功率的实时监控才可以发现。目前B端支付成功率为D+1报表生成，并未实时，更无监控。**如果要推动实时监控，有两条实施路径。**一条是推动收银台后端和数据团队进行能力建设。之前有尝试过，但对方动力不足，不排除本次case后态度转变的可能性。一条是前端通过raptor自行建设。前端可以通过自定义复合指标，对支付成功率的环比趋势进行监控，虽然前端的数据绝对值并不准确，但足以满足及时发现问题的需求。**在Q3规划中，收银台前端的监控体系建设将会作为重点进行规划。**
* **二是推进B2B支付全链路灰度。**case发生后，美支侧拉了优化监控报警的专项群，借此机会可以对前后端全链路灰度进行推进。收银台前端目前可选灰度策略有二。一是按照tradeno订单尾号分流，但会出现一个用户多次下单，跳转至不同版本收银台的问题，严重影响体验。二是在前端上线灰度机器后，配置白名单用户，进行线上验证。验证通过后，发布至全量。以上都不是最优方案。**希望在Q3建立以用户唯一标识为线索的全链路灰度，保证后续版本迭代的安全平稳，以及为A/B Test铺垫基础能力。**