网传支付宝 14:40-14:45 所有的支付订单都按国补减免了 20%。
 

从网上铺天盖地的截图来看，非常多类型的交易都被“减免了 20%”。

说实话，歪师傅纵横互联网多年，什么千奇百怪的事情没见过？

比如这种还贷款有政府补贴的，我觉得还说得过去，毕竟有时候确实有政策扶持，你要强行往这个上面圆谎，遇到外行也是能糊弄过去的：

但是个人转账都能有政府补贴的，这个还真没见过：

还真是猪八戒吃人参果，第一遭。

又好比大姑娘坐花轿，头一回。

我第一反应甚至是：我靠，现在的诈骗的套路都玩得这么深吗？我甚至都一眼看不穿它。

针对支付宝这个“真百亿补贴”行为，很多网友纷纷猜测这波又是程序员干的。

有这种可能，但是我觉得还有另外一种可能，在这种可能性中，这个问题和程序员毫无关系。

我个人猜测这可能是一次运营配置事件。

我觉得是这样的。

根据官方信息，过两天，就是 1 月 20 日，国补就要正式开始了：

支付宝的程序员在这之前接到了一个国补相关的需求，需求可能是要求在创建支付订单的时候，根据订单对应的产品来判断该产品是否符合国补条件，从而决定是否进行对应的金额减免。

那么哪些产品符合国补条件，这个逻辑肯定不是写死在代码里面的。

应该是作为一个运营配置项，可做实时配置、灵活调整，而这个配置项又可能相对复杂。

比如同时可以配置支持 A 大类下的 B 小类产品、不支持 C 大类的 D 小类产品，类似这种条件组合吧。

具体的运营人员在做参数配置时，不知道出于什么原因，配置出了一个条件组合之后，这个组合的最终效果按照程序逻辑解析是所有订单都可以参与国补。

这种配置肯定是要一审二审，层层审批的。

但是巧了，审核人员就是没看出来这个配置是有问题的，给通过了。

然后就出现了这个“真百亿补贴”行为。

这种行为，换个场景就更好理解了。

就类似于营销发优惠券。

本来设计的营销活动是给指定客群的用户发一个满减的无门槛优惠券。

结果运营人员在选客群的时候操作失误，给所有的用户都发了优惠券。

你说这个场景，和程序员有什么关系？

本来就存在给所有的用户发优惠券的需求和场景，使用的人用错了，你怪我开发的时候为什么不想着拦截一下？

还有天理吗？

但是这个真实的场景又比优惠券惨烈的多，毕竟优惠券客户不一定真的去用，但是这次“补贴”是真金白银的给出去了呀。

而且还是直接给到了无数个 C 端用户，追都不好追。

哎，惨啊，真的惨。

我再强调一次啊，以上是我个人的猜测，没有任何依据。

我作为一个程序员，屁股当然得歪一下，当然是希望这个问题和程序员无关了。

只有苦一苦运营岗的兄弟了。（手动狗头

如果真的是因为程序员编码问题导致的，朋友，不管你看不看得到，挺住，我入行第一天就查过了，程序员因为非主观 BUG 导致公司重大损失的，不需要承担法律责任。没啥大不了的。当然，有责任心是好事，但是一份工作而已，想开点，尽人事听天命就完事了。

话又说回来了，这里面就没有程序员的事儿了吗？

肯定有呀！

分析数据范围，捞问题数据，做数据修复等等这些后续的事情，肯定还是程序员来做的。

另外，我昨天还看到了这个短信：

我猜这个短信是假的，因为短信内容太过随意了。

简单来说，“BUG”这个词，就不应该出现在短信里面，不可能是官方用语。

你能确保收到短信的每个人都知道“BUG”是什么意思吗？

注意信息茧房的存在，你认为的常识不一定是每个人的常识。

我就在现实生活中遇到过不知道“BUG”是什么意思的，我还要解释一番。

另外，都说到短信了，顺便给大家分享一个小技巧。

这个截图暴露了短信发送方的前 8 位数字。

这 8 位数字就是短信号段，这里面是大有文章。

简单来说，106 短信码号码是由工信部或通信管理局颁发，接入移动、联通、电信三大基础运营商并进行统一管理，共分为1062、1063、1065、1066、1068 和 1069，用于不同的服务目的。

其中，1066、1068/1069 号段的短信需要企业在工信部进行申请，1062、1063 号段则是向各省通信管理局进行申请。

国家也有一个号段查询网站，前八位一输就知道这个短信是哪一家公司发的了。

比如上面截图中的 10680503：

这个公司看起来和支付宝没有任何关系，这个也正常。你用真的支付宝发送的短信去查，查到的也不是支付宝，因为这只是对接的众多短信通道中的一个而已。

但是如果以后收到骚扰短信，可以按照这个去投诉，最终这个投诉会附带着一点点惩罚，到最初的发送方的。

一个小技巧，送给大家，祝大家春节前的倒数第二个周末愉快。

最后，不管和程序是否相关，保命箴言再背一次总是没错的：可监控、可灰度、可回滚。

---- 2025.01.17 01:22 更新 ----

上面的内容 16 号晚上就写好了，想着早上起来就发。

17 号凌晨被起来上厕所的时候看到官方声明了：

看起来确实是运营活动配置问题，看来歪师傅的猜测还是比较靠谱的。

看起来没有一个程序员在本次事件中受伤。

但是看起来又像是一个边界值的问题，可能存在程序校验不到位的情况。