互聯網運營多多少少都會遇到一些事故，事故有大有小，影響不一，有些微乎其微，但是有一些卻舉足輕重。系統發生重大災難難道只能“刪庫跑路”？本文作者列舉了互聯網公司一些比較重大的事故，並總結了自己的幾點建議，與大家分享。

一、什麼是重大事故？

刪庫跑路？還是系統奔潰？重大事故讓人沮喪、肝兒顫、似乎又無可奈何？

近來所在的部門和產品發生幾次大事故，用戶大量湧入，在峯值時刻導致系統癱瘓，造成不可估量的經濟損失：原有線上活動不能正常進行，除此之外，無論是對產品本身還是品牌形象的損害更是無法估量，所謂創業難、守業更難。

當然重大事故在任何產品和任何公司都有發生的可能，比如——

1. 拼多多優惠券BUG事件

2019年1月20日凌晨，拼多多遭遇了成立以來的最大BUG事件：當日凌晨，有用戶發現可以領取100元無門檻券，切換微信、QQ等賬號可以多次領取，且兌換券可直接用於充值話費、Q幣、購買商品時抵扣。

該BUG於凌晨被發現，隨之被擴散開來，凌晨五點傳遍全網，吸引了大批羊毛党進入，至早上九點拼多多才反應過來，下架了相關優惠券，10點左右BUG被修復。由於有羊毛党進入，衆所周知其作戰能力彪悍，開啓了嘻唰唰模式。傳言該BUG使拼多多一夜損失200億。

2. 攜程癱瘓門事件

2015年做互聯網行業的人應該都耳聞過攜程“癱瘓門”事件，那天是5月28日，突然之間攜程官網和APP雙雙崩潰，訪問不了。一時間謠言四起，兩個小時後，攜程發佈聲明說服務器受到不明攻擊，正在努力恢復中。

但是據坊間流傳，說攜程的數據被懷恨在心的一個工程師物理刪除，數據全部丟失。互聯網公司最核心的就是數據了，若用戶數據丟失，公司會成爲一個空殼，變的一文不值。次日攜程發佈官方聲明，說是由於員工操作失誤，誤刪除了生產服務器上的代碼所致，就此事件結束，受此事件影響，攜程盤前股價暴跌11.67%。

3. 王者榮耀test郵件事件

如果你不知道玩什麼，就玩王者榮耀吧。如果你不知道朋友去哪了，就去王者榮耀找吧。

2018年12月3日王者榮耀不少安卓QQ區的用戶收到了標題爲“test”的郵件，打開后里面是英雄沈夢溪、棒球奇才、英雄李信和灼熱之刃四個永久道具。價值有多大呢，這次郵件內容被用戶戲稱爲“天美史上最強福利”。

郵件發出後，全網沸騰，微信羣、QQ羣關於郵件內容的截圖滿天飛，然而不到1小時，進入遊戲提示：停服維護。官方動手了，對已經使用了道具的賬號，強制進行了回收。未打開郵件的賬號，郵件被刪除。按照遊戲出 BUG 必補償的原則，事後官方對全服玩家發放了每人10個英雄碎片和2000個銘文碎片補償。

二、一分爲二看待“重大事故”這件事情

1. 第一個“一分爲二”：主動還是被動

通過上邊的案例我們可以看到，重大事故的發生分爲人爲的、故意的，和非人力可以控制的、意外的，前者如程序員刪庫跑路，後者如活動大量流量訪問時系統的暫時性奔潰（此處應該有一個淚奔的表情）。

2. 一分爲二看待“重大事故”這件事情的生命週期，挑戰還是機遇

首先我們應該慶幸，我們能夠遇到和處理、解決這些“重大事故”，因爲一定程度上說明了我們做的產品到了一個比較大的用戶量階段，對系統的高併發有了比較高的要求，這無論是對產品還是對技術來講，都是一次在壓力中成長的機會。

就像一個孩子的成長一樣，一路上的跌跌撞撞、磕磕碰碰之後，才能成長爲一個身體和心理都較爲強壯的人，而系統也因此變得越來越健壯。

三、重大事故是事實和性質雙重嚴重的問題，怎麼辦？

這總歸不算事一件特別好的事情，至少不值得炫耀。

這是項目或者產品冒着拼盡洪荒之力的重壓給參與者的一次成長的機會，風險永遠不可消除和避免，但是我們還是有章可循儘量能預防，從而降低風險和損失。

（1）對於人爲原因的事故，我們只能從人的角度多關注，關注每一個參與者的幸苦付出，讓大家感受到參與的熱情和價值，做好團隊的心理建設

（2）對於非人爲的原因造成的事故，大概有以下一些處理方案，主要是一些在用的方案，坊間通用的以後用到再談。

  1. 首先，產品的功能和壓力測試要做、並且要做好。很多次事故的發生，除了不可以預估的問題之外，很多都是所謂的“小問題”導致的，比如一行代碼寫錯、代碼編寫的不規範、需求邏輯的漏洞等等；
  2. 第二點，針對大型活動的緊急預案怎麼做也很關鍵，比如服務器的動態擴容，如果沒有動態，那麼讓運維的同學現場支援行不行，我們要想盡一切辦法和可以動用的資源去保障活動過程中儘量將損失降到最低；
  3. 第三點，持續的性能優化。我們在產品從0到1點階段往往會一定程度上降低對產品性能的要求，加上不同的人由於經驗和能力的不同，往往會不能夠兼顧到“以後”，我們很多時候總是滿足“當下的需求”而忘記了看遠方的路。因此，我們要找機會，對做過的東西不斷的優化，一種是純技術層面的，比如代碼邏輯和編譯上的優化；更好的方式當然是要在戰場去驗證，產品做出來一定要在不停的實戰使用中、在一次次的峯值跳躍間，找到問題，優化問題。
  4. 活動過程中的實時監控。在業務線上使用的過程中，我們也不斷增加了一些實時監控工具，可以實現在活動作業過程中對服務器壓力、CPU性能、數據庫壓力等的實時看板監控，做到秒級的實時監控。
  5. 一比一模擬線上活動，功能自動化腳本測試和性能腳本壓測。永遠沒有萬全之策，但是我們可以離安全再近一點。每次活動之前我們按照業務預估的訪問量進行模擬環境的功能測試和性能測試，當然這一切都要形成腳本，進而可以變成自動化，這樣一方面可以節省時間，另一方面也可以不斷豐富監控庫。
  6. 活動策劃的時間把控和活動報備，同時段多個活動同時在線時怎樣錯峯處理。其實很多時候系統奔潰的問題會出現在活動運營的整體時間把控不足，對活動效果估計不足或者樂觀估計等問題上。比如，我們預估活動只會有20萬人參與，但是實際訪問量卻是100萬；我們認爲一切萬無一失，但總是馬失前蹄。還有，同時段如果有多個活動同時進行，這種多線程的壓力就會被放大多倍。
  7. 多系統聯動而導致的關係複雜度提高問題。除了我們自己單獨的系統會遇到瓶頸而導致系統問題之外，如果我們跟多個系統進行多次聯動，那麼發生問題概率會大大提升。比如，一個業務規則在我們自己的系統是OK的，但是保不齊上下游關聯繫統會發生什麼“意外”，這個時候出了問題大家就只能一起背鍋（請叫我背鍋俠）。
  8. 很有很多，這次先寫這麼多……

四、性能優化與用戶體驗的永恆博弈

剛剛講了很多實際處理重大事故的方案和預案，但是當我們透過現象看本質我們會發現，在基本的功能問題處理完畢後，後續我們將面臨的是系統性能和用戶體驗的艱難博弈。

簡單來講：比如我們減少一個炫酷交互的操作，可以提高頁面打開效率的1%；爲了方便用戶篩選，我們將篩選做的層級分明，極爲細緻，但是這樣的設計系統接口間的詢問次數就會變得多了起來。

在處理這部分問題和工作的時候，小胖發現一個很有意思的點：技術同學往往想讓產品降低一些操作和搜索類邏輯的使用，從而可以提高一部分系統的性能，但是產品同學往往對用戶體驗細節要求極高，所以很多方案都是大家儘量溝通達到所謂的“中和”點，但是這樣的中和是否就是完全對的呢？

五、怎麼進行事故的解釋和彙報

1. 下下策：報喜不報憂

許多人喜歡報喜不報憂，哪怕是出了很大的事故，這種做法其實是不太明智的，畢竟老闆也不是傻子，可能開始的一兩次忽悠還可以矇混過關，但是路遙知馬力日久見人心，諸君共勉。

2. 中策：報憂不報喜

有些人又比較慫，只是會承認錯誤，災難都發生了，承認錯誤是應該的，但是光承認錯誤是沒有用的。並且，如果只講不好的部分，本來相關人員就不順心，無疑是雪上加霜。

3. 上策：往往絕境就是機會

小胖比較人可以的方式是既要主動認識到問題的嚴重性和快速定位到爲題，解決問題；也要找到問題的轉折點，化悲痛爲力量。比如可以抓住機會提出針對產品的優化資源需求，要錢要資源；當然更好的方式是，能否讓一個災難變成一次好的公關。

比如曾經某個漢堡品牌被爆出使用的肉有問題，媒體一時間得理不饒人，但是後來公司想了一個讓社會繼續幫這個品牌尋找用餐過程中的重大問題的活動，經過一段時間後，不但更多的人知道了這個品牌，更知道了這個品牌是一個敢於當擔的品牌。人也一樣，擔當很重要。

以上，從事故中總結而來，也希望如果有一天你用的到，可以給你一些有用的思路和借鑑。

愛你們的小胖子。2020年夏。

參考資料：

http://www.woshipm.com/operate/2903465.html/comment-page-1

#專欄作家#

FatBoy，微信公衆號：夜來妖，人人都是產品經理專欄作家，做了幾年產品。

本文原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議

相關文章