員工寫了個大 BUG，網站痛失 300 元！

2024-03-14碼農

大家好，我是程式設計師魚皮。

前幾天，我們公司的員工寫了個大 BUG，導致網站痛失 300 元！

事故現場

事情是這樣的，我們公司做了很多自己的網站，每個網站都需要支付功能，所以我們就開發了一個支付中心。

各個業務系統可以很方便地接入支付中心，實作支付，不用再重復開發支付功能了，大大節約開發成本。

聽起來很不錯，但這樣一來會存在一個很嚴重的問題，一旦支付中心掛了，所有的業務都會受到影響。

而我們開發同學這次寫的 Bug，完美擊垮支付中心！

他是怎麽辦到的呢？

我們有一個小需求：使用者如果直接輸入網域名稱存取支付中心（而不是透過正常跳轉下單存取），這時其實支付中心的頁面內容是無意義的，我們希望將這些使用者跳轉到公司的官網。

結果，這位開發同學在上線其他需求的時候，沒有經過任何測試，就把支付中心頁面跳轉的程式碼上線了。而萬萬沒想到的是，短短 6 行程式碼，竟然寫了個 Bug，導致所有線上使用者在建立支付訂單時，強制跳轉到了公司官網，而不是支付頁面！

事故影響

就是這麽一個 Bug，持續了整整 4 個多小時。事後，根據我們後台粗略的統計，大概 8 位使用者付款失敗，造成收入損失 380 元！

這是直接影響，間接影響是導致使用者流失、降低使用者對公司產品的信任度等。

大家可能覺得這個金額和使用者損失並不大。的確，這點影響對於大公司來說，幾乎可以忽略不計；但對於我們創業公司來說，這已經是不小的收入了，而且我個人認為評估事故重要性的因素不止有收入影響，還要看事故的性質和產生原因。

我對這位開發同學說：如果你是在大公司寫出了這個 Bug，搞不好分分鐘幾千萬、幾億的流水沒了。。。

所以我們把這次的事故定為 P0 級 重大事故，不是為了放大責任，而是希望以此為鑒，詳細復盤，防止日後再出現類似的情況。

事故復盤

處理完線上 Bug 後，我們聚在一起討論這次事故背後的原因，思考怎麽能夠進行預防和改進。

寫這個 Bug 的同學態度很好，主動寫了一篇復盤文件，首先是他寫的事故原因分析：

事故原因

1）直接原因

寫完程式碼後沒有做測試，並且因為自大，導致了沒有測試就上線。

由於多個需求同時上線，導致上線後沒有進行完整充分的驗證。

2）間接原因

心態問題，對上線沒有那麽重視，忽略了支付業務這種核心業務的影響。

沒有嚴格遵守從編碼到上線的規範，這次事故是長期的壞習慣導致。

看了這段我是感同身受，其實最嚴重的事故往往就源於最簡單的程式碼，越是簡單的需求，我們就越容易過分自信，覺得肯定沒問題，然後就忽略了測試和驗證。

除了這些原因外，我還看出了一點，這位同學對業務邏輯不夠了解，才導致跳轉邏輯寫錯了。

當然，出了事大家一起扛，公司肯定也有責任，比起追究責任，我們更需要關註如何改進。透過對事故原因的分析，我們一起討論出了以下的改進方案。

改進方案

我們把改進方案分為 2 類：「對人」和「對系統」。

1、規範和把控上線標準

說來慚愧，我在剛開公司不久，就已經寫了【開發規範和上線註意事項】文件，比如：

上線前，必須完整測試本次改動涉及的所有功能，例如：許可權控制、邊界例外處理、頁面是否嚴格遵循設計稿等。

上線後，必須再次對功能進行測試驗證。

我也在新人入職手冊、開發群的公告裏讓大家看文件。但是有了規範，大家不遵守、不註意，也沒什麽辦法。

這讓我想到了之前張一鳴提到的：很多流程和規範是為了沒有意識和習慣的同學準備的，如果團隊成員都有好的開發上線習慣，也就沒必要定那麽多條條框框了。

像這次的事故，不也是由於開發同學缺少測試和線上驗證的意識，導致的麽？

所以其實除了有上線標準外，還要想辦法幫助大家養成遵循規範和標準的習慣。

如果一個人不能保證零 Bug，那就「找幫手」，比如同計畫組的同學共同驗證、相互提醒。

我們也因此新增了一條明確的制度：如果有核心業務相關的程式碼修改（例如支付業務），必須 至少兩人 同時測試驗證。

此外，之前也提到過，我們由於團隊規模不大，有的時候成員可能直接送出程式碼就上線了，沒有經過 100% 的稽核。經過這次的事情後，我們再次意識到了程式碼審查的重要性，哪怕是再小的計畫，只要有使用者使用，一定要由非本人之外的人再次閱讀程式碼，並且 透過稽核後才能上線 。還是要強化大家遵循流程和規範的意識。

大廠規範的開發流程就是這樣，沒辦法自己強行推播程式碼，而且是程式碼稽核後透過流水線打包自動釋出上線，最大程度上消除單人、人工失誤導致的 Bug。