支付寶 16 號(hào)下午出了一個(gè) P0 級(jí)別的線上事故，5 分鐘內(nèi)的支付訂單全部打 8 折，也包括轉(zhuǎn)賬在內(nèi)。

也就是說(shuō)，你給朋友轉(zhuǎn) 10000 元，實(shí)際上只需要支付 8000 元，但你朋友還是能收到 10000 元。

顯然，這很離譜。

所謂 P0 級(jí)事故，是互聯(lián)網(wǎng)產(chǎn)品中定性最嚴(yán)重的問(wèn)題，需要立刻馬上修復(fù)。

事后根據(jù)支付寶官方的說(shuō)明，事故原因是在后臺(tái)配置運(yùn)營(yíng)活動(dòng)時(shí)寫錯(cuò)了類型和金額。

至于損失，支付寶說(shuō)不會(huì)追回。

很多網(wǎng)友說(shuō)，新年第一個(gè)紅包是支付寶發(fā)的。也有網(wǎng)友說(shuō)，感覺錯(cuò)過(guò)了幾個(gè)億。

對(duì)于這件事，背后倒是有兩個(gè)問(wèn)題值得討論。

第一，支付寶在這次 P0 級(jí)事故中到底損失了多少錢？

第二，導(dǎo)致這次嚴(yán)重事故的根本原因到底是什么？

先說(shuō)第一個(gè)問(wèn)題。

我看到網(wǎng)上有很多分析，有說(shuō)損失幾千萬(wàn)的，有說(shuō)損失上億的，還有說(shuō)損失 10 到 20 億的。

其中，有人通過(guò) AI 分析的方式得出了一個(gè)邏輯。

比如，2023 年第三季度支付寶的交易量是 118.19 萬(wàn)億，平均到 Q3 的 92 天時(shí)間里，每分鐘交易量是 9 億元。

事故持續(xù) 5 分鐘，按照每筆訂單 20% 的折扣損失來(lái)計(jì)算，累計(jì)損失金額是 9 到 10 億區(qū)間。如果算到今年的業(yè)務(wù)增量，估計(jì)在 20 億區(qū)間。

那么，這種算法靠譜么？

我覺得是不靠譜的，因?yàn)檫@里面忽略了一個(gè)上限條件，就是補(bǔ)貼的額度設(shè)置。

在正常的產(chǎn)品設(shè)計(jì)邏輯中，涉及到這種折扣優(yōu)惠時(shí)都會(huì)添加一個(gè)設(shè)置，那就是金額上限。

比如，優(yōu)惠券數(shù)量和金額設(shè)置，對(duì)應(yīng)就有一個(gè)數(shù)值上限。如果消耗額度達(dá)到這個(gè)值，就會(huì)自動(dòng)停止。

如果支付寶的產(chǎn)品經(jīng)理真的蠢到這個(gè)都沒設(shè)置，那活該虧死，但我覺得可能性不大。

此外，國(guó)補(bǔ)本身也是有限額的，更何況支付寶只是所有支付渠道的其中一個(gè)，它不會(huì)把額度拉滿。

真實(shí)的損失額度，我覺得在 8 位數(shù)的數(shù)量級(jí)是比較可能的。當(dāng)然，這也是猜測(cè)。

再說(shuō)第二個(gè)問(wèn)題，事故原因是什么？

如果復(fù)盤這個(gè)事故流程，其中包含了產(chǎn)品、技術(shù)、測(cè)試、運(yùn)營(yíng)、審核等至少五個(gè)環(huán)節(jié)。

產(chǎn)品基于業(yè)務(wù)需求設(shè)計(jì)邏輯，技術(shù)根據(jù)需求完成開發(fā)，測(cè)試根據(jù)需求進(jìn)行檢測(cè)，運(yùn)營(yíng)上線后使用，對(duì)應(yīng)負(fù)責(zé)人層層審批。

根據(jù)現(xiàn)象說(shuō)問(wèn)題，光是轉(zhuǎn)賬可使用補(bǔ)貼這一點(diǎn)，就說(shuō)明系統(tǒng)本身的邏輯設(shè)計(jì)是有問(wèn)題的。

然后是運(yùn)營(yíng)配置出錯(cuò)，既然能成功設(shè)置上線，說(shuō)明系統(tǒng)本身就是支持的，這是個(gè)漏洞，也沒有觸發(fā)任何風(fēng)控警告。

從實(shí)際場(chǎng)景來(lái)說(shuō)，優(yōu)惠的使用是有限制條件的，這既需要在產(chǎn)品需求里定義清楚，也需要在開發(fā)過(guò)程中做好判斷，同時(shí)在測(cè)試環(huán)節(jié)也需要用例覆蓋。

國(guó)補(bǔ)優(yōu)惠在沒有任何限制的情況下在轉(zhuǎn)賬、還款、商家支付場(chǎng)景下使用，這是個(gè)漏洞。

再就是上線前的覆蓋測(cè)試，這種涉及金額的需求沒經(jīng)過(guò)全量測(cè)試就上線，本身也不符合規(guī)范。

我是做技術(shù)出身的，我知道很多分支邏輯在主流程開發(fā)中可能會(huì)被忽略，甚至上線后才能發(fā)現(xiàn)問(wèn)題。

即便是做到開發(fā)前的需求澄清和上線前的測(cè)試覆蓋，要做到全場(chǎng)景無(wú)死角問(wèn)題避免也是很難的。

所以，這就是系統(tǒng)開發(fā)過(guò)程中的不確定性。

另外就是審核，審核是一個(gè)人工流程，但凡是人參與的環(huán)節(jié)就會(huì)出錯(cuò)，這也是無(wú)法完全避免的。

支付寶的這個(gè)事故原因顯然是兩方面的，系統(tǒng)漏洞加人工失職。

類似的問(wèn)題在很多互聯(lián)網(wǎng)產(chǎn)品上都出現(xiàn)過(guò)，哪怕是一些超級(jí)大廠的產(chǎn)品，每隔一段時(shí)間我們都能看到類似新聞。

因此，人治情況下的產(chǎn)品就有這個(gè)弊端，如果未來(lái) AI 能在這方面做好提前干預(yù)和及時(shí)止損，情況或許會(huì)變好。

對(duì)于互聯(lián)網(wǎng)產(chǎn)品來(lái)說(shuō)，機(jī)制要好于流程。

最后，支付寶在事后的公關(guān)表現(xiàn)上還是比較聰明的。

因?yàn)椋脩粜枰氖?strong>安全感。

················· 唐韌出品 ·················

安可時(shí)刻

微信在 AI 配圖上又做了一次優(yōu)化，將圖片下方角落里原本的「AI生成」文案改成了「AI圖片」，這樣就減少了一個(gè)誤會(huì)，以為文章是 AI 生成的。