老许是那种什么事都先干再说的人。去年年底他接了一个做生鲜电商的商户，每天订单量不大不小，一两千笔，但时间特别集中，全挤在早上九点到十一点之间。
商户说通道偶尔掉链子，他想做个评估
商户那边描述得很模糊——有时候用户付不了款，刷新一下又好了。老许翻了翻后台，没看出什么明显问题，心想是不是用户那边网络不行。
但商户坚持说不是个例，一周能碰上十几次。老许觉得得正儿八经评估一下通道的稳定性了。他的思路很直接：连续监控一周，看接口的可用率数据。毕竟大家嘴上说评估，其实最后看的还不就是个能不能调通。
连续监控一周数据之后还是翻车了
他在服务器上跑了一个cron任务，每十分钟打一笔一分钱的测试订单到各条通道，记录返回码和响应时间。跑了一周，数据挺漂亮的——主通道可用率接近百分之百，只有两次超时，但都自动重试成功了。
老许把报告发给商户，说通道没问题。商户没回。
过了三天，他接到一个电话，商户那边声音都变了，说早上高峰期系统崩了将近二十分钟，几百个用户付不了款，微信群全炸了。老许赶紧查监控，奇怪的是他的测试探针那二十分钟内全部正常，返回码200，响应时间也没太大波动。
他对着日志坐了整整一下午才想明白。
他的测试探针走的是固定金额一分钱。一分钱订单在这个通道里被当作小额免密交易，走的是通道的内部快速链路，跟普通订单根本不是同一条线。普通订单要经过风控校验、短信验证、实名核验这一整套流程，而他的探针全部绕过去了。他监控的是通道的VIP通道，而用户走的是普通通道。这就像你在高速公路上测了一下应急车道的车速，然后说全路畅通。
他突然想到一个细节——去年央行新规刚落地那阵子，很多同行都在排查自己的通道合规性，自己当时没当回事。那段时间「央行新规落地三个月，我亲眼看着同行一个个倒下」这篇文章在圈子里传得很凶，老许觉得跟自己关系不大就没细看。现在回头想，那波合规调整之后，很多通道把小额和大额的链路做了更严格的隔离，他的探针就是在那之后丧失了参考价值。
换了一种思路重新搭监控
他把测试订单的金额从一分钱改成了随机金额，范围在十几块到两三百块之间，尽量模拟真实交易。光是这个改动就花了他小半天时间，因为随机金额的退款处理要单独写脚本，不然每天的测试成本扛不住。
改完之后跑了两天，数据立刻不一样了。他发现主通道在工作日上午十点前后有一个明显的响应瓶颈，P95延迟飙到了五秒以上，而他的探针之前完全没捕捉到这个波动。还有一条备用通道更夸张，每隔一个半小时左右会出现一次十五秒的完全不可用窗口，但十次里大概只有三次会被他的旧探针撞上。之前觉得它稳如老狗，纯粹是踩点没踩对。
排查到这一步，老许才开始意识到通道稳定性评估这件事根本不是一个简单的可用率指标能搞定的。你得同时看好几样东西：响应延迟分布、错误类型分类、不同金额区间的表现差异，甚至还得关注通道对手续费敏感不敏感——有些通道大额订单走得好好的，一超过某个金额阈值就开始内部排队。
他又加了一层监控，直接用生产流量的影子流量来压测——从线上日志里抽样出真实订单参数，每五分钟重放一批到各条通道的沙箱环境，完全模拟真实交易链路。这套东西搭起来用了将近三周，中间被各种签名算法和证书问题卡了好几次。
最后稳了，但不是因为监控更好
最终的结果其实没那么戏剧化。商户那边没有再投诉，通道切换策略也改成了一套更保守的方案：高峰期主通道和备用通道按比例分流，任何一条通道的P95延迟超过阈值就自动降权，不等到完全不可用再切。
订单成功率提了大概两个百分点。听起来不多，但放在一个日均几千单的商户身上，一个月能少丢一百多笔订单。生鲜品类复购率高，丢一单可能就丢一个长期用户，这个账算下来比省通道费划算太多了。
老许后来说了句话我觉得挺对的：评估通道这件事，你不在高峰期用真实金额的订单去探，得到的结论全是自我安慰。
技术层面其实还可以做得更细。比如对每条通道的回调地址做周期性校验，确认回调链路畅通。我之前处理过一个反向案例，通道交易正常但回调地址突然失效导致商户那边收不到通知，具体的排查过程写在「易支付回调地址设置后不生效？一个案例复盘」里了，跟这次的问题本质上是同一个根因——你光看一端通畅没用，支付链路上的每一环都得单独验。
剩下的下次再写，今天眼睛盯着日志看太久了，先睡。
讨论区