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

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

一、貝塔來信的緣起

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

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

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

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

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

二、10月9日故障復盤

第一篇就講系統(tǒng)穩(wěn)定性。

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

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

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

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

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

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

三、穩(wěn)定性治理的核心命題

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

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

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

四、有贊的穩(wěn)定性治理

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

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

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

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

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

崔玉松

有贊產(chǎn)品技術負責人

2019-10-23

關聯(lián)閱讀：

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