支付寶事故這事兒,憑什么又是程序員背鍋?有沒有可能是這樣的...
你好呀,我是歪歪。
昨天支付寶那事兒你聽說了吧?
網傳支付寶 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:https://nac.miit.gov.cn/#/notice/gxb
圖片
這個公司看起來和支付寶沒有任何關系,這個也正常。你用真的支付寶發送的短信去查,查到的也不是支付寶,因為這只是對接的眾多短信通道中的一個而已。
但是如果以后收到騷擾短信,可以按照這個去投訴,最終這個投訴會附帶著一點點懲罰,到最初的發送方的。
一個小技巧,送給大家,祝大家春節前的倒數第二個周末愉快。
最后,不管和程序是否相關,保命箴言再背一次總是沒錯的:可監控、可灰度、可回滾。
---- 2025.01.17 01:22 更新 ----
上面的內容 16 號晚上就寫好了,想著早上起來就發。
17 號凌晨被起來上廁所的時候看到官方聲明了:
圖片
看起來確實是運營活動配置問題,看來歪師傅的猜測還是比較靠譜的。
看起來沒有一個程序員在本次事件中受傷。
但是看起來又像是一個邊界值的問題,可能存在程序校驗不到位的情況。
然而這些都不重要了,重要的是我怎么開始起夜了???