各位朋友們，大家好，我叫崔玉松，在有贊別人都叫我“崔”，是有贊的產品技術負責人，很榮幸能夠真正開啟這個欄目，見字如面。

今天這篇文章有點長，主要分為兩個內容：一個是為什么要做貝塔來信這個欄目，一個是關于系統穩定性和10月9日故障的復盤。

一、貝塔來信的緣起

大約在半年前，有個很好的朋友問我，你們總是說自己技術牛逼，到底牛逼在哪里；你們總是說自己很了解商家，到底為商家做了啥；你們更新了產品，別人也更新產品，憑什么你們就覺得自己牛逼…諸如此類，問了一堆問題。

我覺得也對，電商的產品已經數千項功能了，零售和美業的產品也有上千的功能點，商家數也從原來的幾千變成了上百萬，任何一個點的升級想要給商家帶來驚喜，越來越難；而更多的人會感到自己所需要的功能沒有被滿足，沒有被優先安排。雖然我們已經在建造一個強大的自定義和定制化能力系統“有贊云”，可以滿足幾乎任意需求，但依然只有一部分商家知道我們有這個能力。

貝塔來信這個專欄，接下來至少會保持每個月2?3篇的頻率更新，前面幾期都是我自己寫，后面會根據大家的需求和問題，邀請我們不同團隊的負責人來提供內容。例如，很多商家很好奇——我們的服務團隊是如何整合以及如何服務的，有贊的文化，甚至管理是怎么做的，產品是如何被生產出來的，發生故障了技術都在干啥，不發生故障技術到底在干啥。我會一步步帶大家了解一個有血有肉的有贊。

“貝塔來信”這個名字是有贊商家運營的冷面同學想出來的，我覺得這個名字很好，回想我們當初在“貝塔咖啡”這個咖啡館開始創業的時候，早期的商家，我們都有一個QQ群，有什么事情我們都在群里溝通，在討論需求的時候我們一起爭吵不休，反而那個時候商家沒有發現我們冒犯了他們，也沒有覺得有贊對外不透明，更多的是雖然不同意這樣，但是還是能理解。

今天有贊依然試圖去保持這種狀態，但是商家群體實在太大了，這種方式只能針對幾百幾千個商家，多了就沒法繼續了。過去幾年里，我們一直在通過優化內部組織架構、增加服務人數、提高服務水平，去改變和商家之間的連接，努力嘗試再保持原來的深度連接。各種傳播方式也很多，包括堅持了1000多天的有贊小報和用最新形式做面向商家的直播。但是始終我覺得缺了那么點東西，那個東西是啥，我覺得是有贊有思考的觀點，非常微觀的思考、大家能切身感受的思考。

二、10月9日故障復盤

第一篇就講系統穩定性。

最核心的原因是：我們深刻的知道穩定性是一個SaaS公司的基石，一個SaaS公司的一點點故障就會導致大規模的商家無法正常經營。說到這里，很多商家就開始打臉了，既然穩定性是第一位，為什么會有故障？為什么還出現10月9日那么大范圍的故障？

這次事故起因是：一個被視為無風險的測試，觸發了安全設備上的一個錯誤，這個錯誤導致了整個金融云機房的網絡中斷，繼而引發全站無法支付。

運維團隊介入處理處理時，因為供應商沒有駐場人員，趕到機房的時候已經一個小時過去了，再去排查和測試，發現需要更換設備，又臨時找新的設備更換。

當我們意識到機房網絡無法短時間恢復的時候，決定準備切換備用方案，馬上切換到備份機房。但是備用方案沒有經過充分演練，導致切換過程比較不順利，只有一半用戶恢復，一半用戶會看到排隊頁面。

最終，金融云機房網絡3個小時才恢復，真正解決了硬件故障。依憑備份機房的能力，我們的服務大約40分鐘后開始恢復，一個小時左右全部恢復。

這個相對機房的故障恢復速度已經很好，但是，還是存在很大的改進空間：如果我們之前的演練充分，這個故障可以在20分鐘內恢復。鑒于此，我們內部認真復盤了改進措施，相關措施大多數會在雙十一之前上線，有些動作會在11月30日前上線，主要是因為需要增加更多的機器做備份，整個采購到安裝的周期需要一個月的時間。

三、穩定性治理的核心命題

從技術角度看，只要是系統，出故障時早晚的事情。估計有商家說，這是屁話，為什么淘寶不出故障。有贊有大量的工程師同學都是阿里出來的，我本人也是，其實淘寶也出故障，只是因為精細化分解很足，每次出故障影響到的都是少部分商家（一般低于5％），我這么說不是為了推脫責任。特別想說的是，故障天然會發生，如何減少發生概率，發生了以后如何縮短故障恢復時間，如何減少故障影響面是工程技術角度要解決的最核心命題。

先得回顧一下：如果不做任何事情，故障概率到底有多大，通常一個程序員寫一段代碼，部署到線上能被用戶訪問到，用戶訪問一次，通常要經歷10個以上的設備或者系統，例如，數據庫系統、緩存系統、Web服務系統、交換機系統、安全系統，還有部署這些系統的各種設備，其中只有極少數能做到99.99％可靠，大部分都是99％左右的可靠性，我們就簡化一下，每個系統和硬件都有99％的可靠性，理論上不發生故障的概率最終只有90％（0.99的10次方），換句話說，一年停機36.5天。而工程師要做的事情就是將36.5天故障替換到5小時乃至50分鐘。

如大家看今年國慶70周年閱兵一樣，習總書記坐的那輛車牌號為2019的紅旗轎車，后面還跟著其中一模一樣的車牌號為1949的車，如果前車發生故障，立即換一輛車繼續閱兵。

四、有贊的穩定性治理

有贊從2013年就開始使用云計算作為基礎設施，幾乎所有的服務都是有備份的，但還是不能滿足把一年36天的故障降低到一年5小時以內的需求；我們在2017年開始制定跨云的解決方案，把騰訊云和Ucloud兩個云計算廠商通過幾條光纖直接打通了，希望能做到任何一個廠商有問題都不會影響我們太長時間。當然任何事情都是有代價的，雙機房的結果是，有贊每年都要多付出一倍多機房成本。

但是，這次出問題的恰恰是我們2019年初開始建設的金融云機房。這個機房我們也有備份機房，但是因為優先保障商家的雙十一項目，沒有充分演練，導致在切換的過程中大約花了40分鐘，所以部分商家在40分鐘后就開始開始恢復了服務，不過剛剛恢復又遇到了某些大商家做活動，加劇了消費者付款排隊的現象，不得不又臨時擴充服務器數量，所以排隊現象又經過了20分鐘才根治。

發生故障的時候，如何減少影響的商家數量，行業里通常的做法是給商家分區，區和區之間是相互隔離的，一個區停機只影響自己。有贊在未來的12個月里會做到根據商家去隔離，每個區之間相對不影響。目前實際上也有隔離，只是隔離的比較少，每次影響的商家數還不算少。

穩定性治理是一個非常復雜的命題，業界各種治理方法有贊技術團隊都有過嘗試或者正在嘗試，包括藍綠發布、灰度發布、混沌工程等等治理方式。

再次向所有被故障影響到的商家鄭重道歉。系統故障放在任何技術團隊都是一種恥辱，我們一定會知恥而后勇，銘記這次教訓，認真檢查每個可能發生大規模故障的細節，同時面向未來實施故障預防措施。

崔玉松

有贊產品技術負責人

2019-10-23

關聯閱讀：

《關于10月9日晚買家付款報錯、排隊故障的復盤/致歉公告》