多年前，又是周六客服打電話過來，平臺官網不能訪問，app全然無法打開，客戶在QQ群和微信群中各種反饋，說平臺是不是跑路了？客服的多條400熱線全然被打爆，電話已經接只是來…

前言

一直以來總是想以什麽方式去記錄下自己在互金行業的這段經歷，趁著自己還記得清晰。還能找到一些資料原型。一方面能夠分享出來供大家參考，可是更重要就是多年以後我能夠依據這些文章回顧起來自己的那段激情歲月。

想了非常久但一直沒有實施，後來認為應該從架構的角度來梳理一篇文章，就寫了從零到百億互聯網金融架構發展史這篇文章。最後認為僅僅有實戰出來的東西以及解決這個問題的過程，才是工作中最寶貴的經驗，應該把它分享出來，在梳理的過程中認為有三起事故比較有代表性就整理出了以下這三篇文章，本篇文章從總體來回顧一下一路走過來所經歷過的救火故事。

• 一次生產事故的優化經歷
• 一次dns緩存引發的慘案
• 一個腳本引發的血案

作為一個互聯網金融平臺，涉及到用戶資金。不論什麽的服務（資金）差錯用戶都是不可容忍的。用戶不懂什麽是數據庫，不知道什麽網絡不通，就是一會看不到錢在app裏面展示都會認為不安。在已經有非常多P2P公司跑路的前提下，用戶個個已經被鍛煉成為福爾摩斯偵探，每天打開app查看收益，監控著平臺一切，甚至半夜升級斷網十分鐘。也會被用戶察覺，直接就發到群裏面，更有甚者直接在QQ群或者微信群中你們的技術行不行!

我們常說的互聯網工作經驗。一方面是開發經驗，但事實上更重要的是處理問題的能力。

那麽處理問題的能力怎麽來呢。就是不斷的去解決這個問題，不斷的去總結經驗，當中處理生產環境中問題的經驗更甚,由於在處理生產環境中對個人的壓力和臨危應變的能力要求最高，你不但須要面臨千萬個用戶反饋，客服不時得催促並且旁邊可能就站了N個領導在看著你，一副你行不行的樣子要求立馬立即解決這個問題！這個時候你的操作就非常重要。稍有不慎便會引發二次生產事故。

說了這麽多，僅僅是想說明，生產事故對技術綜合能力要求頗高，更是鍛煉處理問題能力最佳時機！

以下給大家介紹我們從零開發到如今百億交易量所遇到的幾次關鍵事故，有大有小挑出一些比較有代表性的事件來分享。

並發滿標

公司系統剛上線的時候，事實上沒有經歷過什麽大量用戶並發的考驗，結果公司做了一個大的推廣，湧入了一批用戶來搶標，共1000萬的標的差點兒都在10秒之內搞定，大概會有上萬左右的用戶會同一時候去搶標，平均每秒大概有千人左右的並發，滿標控制這塊沒有經過大的並發測試，上來之後就被打垮了，導致得結果是什麽呢，1000萬的標的。有可能到一千零幾萬滿標，也有可能會九百多萬就滿標，也就說要不就是多了一些，要不就是少了一些，就滿標了。

這就會非常尷尬。由於借款用戶就借款一千萬整，那麽多出來的錢既不能給用戶退回了。由於用戶好不easy才搶上了，無端退了用戶也鬧；少了也是問題，用戶借款一千萬。少了幾十萬也不行，假設短得少了能夠想辦法找一些有錢的客戶直接給買了，多了就必須又一次放出來讓用戶投資，非常影響士氣，這個問題困擾了我們有一段時間。

購買標的流程圖，不知道大家能否依據此圖發現問題呢？

超募

為何會產生超募？在最早前的版本號中沒有使用樂觀鎖來控制。假設在最後購買的用戶一單出現並發，就會出現超募，比方最後剩余30000份的購買份額。由於並發量特別大。可能同一時候會有十幾個用戶拿到了剩余30000份剩余金額的可購買額度。有的買1000份、有的買上3000份、有的買上20000份都會驅動滿標。所以最後導致了超募。

針對這個問題。主要是引入了memcached樂觀鎖的概念（底層主要是cas、gets兩個命令）。在發標的時候存入標的總份額。當用戶購買的時候首先去鎖定用戶購買的份額。由於樂觀鎖的原因，假設同一時候有兩個用戶拿到份額的時候保證僅僅有一個最後能夠更新成功（鎖定份額），（鎖定份額）失敗直接返回，這樣就保證了在入口的時候就直接屏蔽了部分並發的請求。

少募
為何產生少募？少募是可能1000萬的標的突然到980萬就給滿標了，這是由於在超募情況下我們完好了代碼。用戶一進來首先就是鎖定購買份額。僅僅有鎖定購買份額才幹進行以下的流程，假設鎖定購買份額失敗直接返回，這樣盡管保證了在1000萬份額在購買初期必須每個用戶僅僅能鎖定一份。可是在高並發的情況下，由於購買流程中有十幾個分支，每個分支失敗就會退回鎖定的份額。這樣就會導致這樣的現象，就是可能是並發一上來。立即就滿標了。過了一會進度就回退回來了。

少募主要是由於分支失敗回退導致的，一方面我們分析了easy導致回退熱點，由於在用戶搶標的時候會給用戶實時的展示標的進度。在非常早的版本號中直接就是存入到一個標的進度表裏面，並且採用了樂觀鎖。假設並發一高就頻繁的更新失敗導致回退，因此優化了標的進度這塊。直接去掉了標的進度表，實時依據查詢來展示標的進度（能夠有延遲。有緩存）。另一方面在回退份額的時候在次推斷試下memcached的份額和標的的狀態，假設份額不為零並且標的狀態是滿標，立即自己主動更新狀態保證興許用戶能夠立即購買再次驅動滿標。

做了以上的兩種優化後，我們還遇到了其他的一些小問題。在不斷的優化過程中，最終穩定下來。在後期版本號中將考慮使用MQ隊列或者redis隊列來處理搶標更合理對用戶也更公平一些。

黑客攻擊

2015年應該是互聯網行業受黑客攻擊最多的一年吧，各互金公司都深受其害，當中我就記得網貸之家有一段時間被黑客攻擊的太厲害，連續幾天站點都無法打開。當然了我們也未能幸免，什麽DDOS攻擊、SQL註入、尋找系統漏洞等都差點兒都經歷過了，有的黑客還比較好，應該是出於善意或者展示自己，將漏洞放到烏雲上面或者漏洞盒子裏面讓廠商來修復。

但很多其他的是一些黑產全然就是威脅、敲詐想撈一筆錢，先看看以下這位吧：

這個家夥潛伏到我們公司的客戶群裏面。冒充我們的客戶代表將頭像和資料替換成一樣，然後給群裏全部的客服讓他們發送我們內部的後臺地址，想通過這樣的方式來尋找突破口，當然了這個算是裏面的小菜鳥吧。

DDOS攻擊

DDOS攻擊我們也是遇到了非常多次，確實也沒有比較好辦法。最後都是通過一些笨辦法來盡量的避免。先說說我們的經歷吧。有一次我正在寫程序。客服QQ又閃爍了起來。還沒來得及打開查看信息，客服的經理電話就直接打了過來，我立馬就有一種不祥的預感，說官網打不開了。後臺也登錄不了。

掛了電話。我在本機進行了測試果然不行，立馬準備登錄VPN查看server各項指標，結果登錄不上去，立即上樓找運維經理。他也登錄不上。剛準備給機房打電話的時候。機房來電話了，說我們的一個IP正經歷著1G多的流量訪問，問我們是否正在做什麽活動，剛話沒有說完就說流量已經到5G，不到一分鐘之後流量已經到達18G之多。由於我們的機房和集團公用了一個寬帶入口。結果陸續的集團上面反饋他們的站點、服務也都出現了問題，機房方面害怕引起更大的沖擊，直接把我們官網對外的IP封掉。集團的其他業務也才慢慢都恢復了過來。我們也緊急的更換了外網IP。又一次切換了域名解析才恢復。

事後我們依據apache分析了日誌，流量來自N多個不同的IP地址根本無法應對，也正式由於這次攻擊也才讓我們領導重視了起來。將我們公司的機房網絡層和公司集團徹底分離。這樣的話無論那方受到大流量攻擊都不會相互影響，我們也想了一些笨辦法。由於上次我們更換了外網IP之後攻擊也就停止了，那麽我們認為肯定是針對我們外網來攻擊的，全部我們就多準備了6個外網IP。當監控到對某一個外網進行攻擊的時候立即切換到另一個外網地址，就這樣跟他們玩，能夠起到非常有限的一點作用，假設黑客真的想跟我們玩。這個辦法就像是小孩子捉迷藏。

周年慶的DDOS攻擊

另一次我們正在做周年慶活動，突然有人在QQ群裏面給我們客服說了一句，叫你們的技術負責人來找我，然後我們的站點就掛了，我還保留了當時的一個截圖例如以下：

完了之後客服就來找我，然後依照往常的策略處理完之後，我依據客服給我的QQ號碼加上了那個人，開口就來嚇我，我依稀記當年的對話例如以下：

黑客：你是平臺的技術負責人嗎？
我：算是吧
黑客：你信不信我能夠讓你們官網在5秒之內掛掉?
我：…（沈默，還真害怕又把官網搞掛了）
黑客：你們的官網漏洞非常大
我：假設有好的建議請您賜教
黑客：你們的server是不是什麽防護軟件都沒有裝？
我：…（繼續沈默，這會在想不會是那個安全廠商來推廣產品的吧，當然我們基礎的防護肯定有）
黑客：我們有非常多的肉雞。想攻擊誰，幾秒之內肯定搞定
我：…
黑客：我們已經給非常多互聯網金融行業做了滲透測試。花點錢幫買你們平安，保證以後不會在出事情
我：…
黑客：免費的策略也有非常多，比方360、百度雲的安全產品能夠免費低檔10G左右的流量

……(中間省略)

黑客：我說了這多。你們也是不是給包煙錢。表示表示。

……

後來也和領導進行了商量，堅決不能給他們錢，不能助漲這樣的囂張氣焰。實在不行就報警。

曝光一下當年使用的假QQ號。剛查了下變了個頭像和描寫敘述。例如以下：

後來我一直在想為什麽DDOS攻擊總是喜歡依據外網IP來攻擊呢，慢慢好像是理解了假設針對域名來攻擊的話，那不就是攻擊到域名商的server了嗎,一般域名商比較強大，黑客不太搞的定，也確實沒有必要。當然記的前一段時間。某著名域名服務商被攻擊。導致國外twitter等著名的互聯網公司訪問不斷到達半天以上。還是非常嚴重的。

可是對於我們這些小公司，倒不至於搞這麽大的動作。

究竟怎樣正確的防止DDOS攻擊：

• 第一種方案，隱藏server外網地址，server前端加CDN中轉。免費的有百度雲加速、360站點衛士、加速樂、安全寶等，假設資金充裕的話，能夠購買高防的盾機。用於隱藏server真實IP。域名解析使用CDN的IP。全部解析的子域名都使用CDN的IP地址。此外。server上部署的其他域名也不能使用真實IP解析。全部都使用CDN來解析。

• 另外一種方案，買一些安全產品來進行流量清洗，主要是阿裏雲、騰訊雲這樣的大廠商提供的一種服務。

• 第三種方案，有非常多的防火墻產品聲稱能夠防止Ddos攻擊，可是我個人使用感覺效果非常有限。

SQL註入

我們的官網使用的是PHP開發，由於框架比較老舊的原因。存在著一些SQL註入的點，我們發現了一些進行了修補。沒想到還是被一些黑客找到了突破點，這塊還是比較感謝這些黑客的在漏洞盒子上面提交了bug(例如以下圖)，最後我們依據提示進行了緊急修復。後來我們也在WAF防火墻配置了一些攔截SQL註入的策略，起到雙保險的作用。

我一直在想為什麽PHP一般比較easy出現SQL註入呢，而Java較少的暴漏出來SQL漏洞的情況，我估摸著有雙方面的原因：第一，PHP通常會在前端使用的較多。受攻擊的機會很多其他一些。Java一般做為後端服務攻擊的可能性會比較少；第二，PHP框架較多並且非常多早期的框架並沒有特別考慮SQL註入的情況，Java大量普及了mybaits\hibernate這樣的orm框架，框架本身對常見的SQL註入有防止的功能，但不是說mybaits/hibernate框架就沒有被sql註入的可能。大部分場景下是OK的。另外參數化查詢能夠有效的避免SQL註入。

通過一段時間的學習，我發黑客一般先使用工具對站點做總體的掃描相似Acunetix，在依據掃描出來的漏洞做個大概的分析，可是比較深入的漏洞都須要依據站點的業務在進行調整，比方sql註入會依據頁面的查詢使用sqlmap等工具來進一步的滲透。當然我對這方面還是外行。描寫敘述的可能不夠清晰。

其他攻擊

其他方面的攻擊，主要是在業務方面，比方我們當初有一個非常小的失誤。有一個程序猿在H5的小網頁中將發送短信驗證碼返回了前端，最後被haker發現了，利用這個漏洞能夠給隨意的用戶重置登錄password；短信攻擊。如今的站點差點兒都有發送短信或者短信驗證碼的功能，假設前端不做校驗，haker會隨便寫一個for循環來發短信。一般系統的短信會進行全方位的防控。比方：1、前端加驗證（字符驗證碼。有的是拖拽的動畫）;2、後端依據用戶或者IP加限制，比方用戶一分鐘僅僅能夠發送一條短信，忘記password的短信一天僅僅能發送10條、一個IP地址限制每天僅僅能發送100條短信等。

BUG

反復派息

15年的某一天看到一個新聞說是陸金所的一個用戶發現自己銀行裏面突然多了非常多錢，沒過多久又被扣走了。然後收到陸金所那邊的解釋。說是給用戶還本派息的時候程序出現了問題導致還本派息兩次。當他們程序猿發現了此問題後緊急進行了處理，用戶當然鬧了呀。就上了新聞。當然陸金所通道能力確實比較強能夠直接從用戶卡裏面扣。當大家都興致勃勃的談論這個話題的時候。我卻有一股淡淡的憂傷，為什麽呢?由於這個錯誤我們也犯過，詳細說就是我搞的。大家可不知道當時的心裏壓力有多大。

事情是這樣子的，我們使用的第三方支付的扣款接口不是特別的穩定。於是我們前期就對接了兩種不通的扣款接口，平時前端投資的時候走一個接口，後端派息或者還本的時候走另外的一個接口，在初期的時候扣款接口不穩定，因此在給用戶跑批的時候常常會有個別用戶失敗。須要手動給失敗的用戶二次派息。

做為一個有誌向的程序猿當然認為這樣的方式是低效的，於是將程序改造了一下。在後端派息的時候當第一種扣款失敗的時候，自己主動再次調用另外一種扣款接口進行扣款。當時想著這樣的方式挺好的。各個環境測試也沒有問題，上線之後監控過一段時間也運行穩定。

當我感覺一切都非常美妙的時候。事故就來了，突然有一天客服反饋說有的用戶說自己收到的利息感覺不正確，好像是多了（真的是太感謝這個用戶了），我登錄後臺看了一下派息的流水復核了一遍，果然利息被反復派了。一股冷水從頭而下。把當天全部的用戶派息記錄和到期記錄都進行了檢查。影響了70多個用戶，導致多派息了6萬多元，幸虧僅僅是派息出了問題，假設是到期的話金額會翻N倍。當中70多個人裏面有幾個進行了體現、幾個進行了再次投資，絕大部分用戶在我們發現的時候還不知情，金額也沒有動。

怎麽處理呢。當然不能直接就動用戶的錢了，給每個反復派息的用戶打電話，說明原因贈送小禮物。請求諒解後我們把反復派過的利息在次調回來。大部分用戶進行了核對之後都還是比較配合的，可是肯定有一些用戶不幹了，當然也不能怪客戶，都是我的原因，有的客戶須要上門賠禮道歉，有的客戶須要公司出具證明材料，我們的老板親自給客戶打了N個電話被客戶罵了N遍。我心裏壓力可想而知，當中有一個客戶特別難纏，各種威脅說既然到了我的賬戶裏面肯定是我的，你們的失誤不應該讓他來承擔，折騰了非常久，還是不能怪客戶。可能會說有的互聯網公司常常出現這樣的問題後就送給客戶了。哎，我們是小公司呀！這個噱頭玩不起。

究竟是什麽原因呢。事後進行了復盤也給領導做了匯報，平時都是首先進行派息的定時任務，過一個小時之後進行到期的定時任務。當天的派息標的比較多，跑了一個半小時，就導致了派息和到期的兩個定時任務同一時候進行。轉賬有了並發，第三方支付的接口不穩定給我們返回的失敗。事實上有的是成功的。就導致了我們進行了二次的扣款嘗試引發了此問題。

這個事情給我帶來了非常大的教訓。對於金融扣款的這樣的事情一定須要慎重。哪怕付款引發報警之後在人工處理，也不能盲目重試可能引發雪崩效應。

雜七雜八

還有就是其他一些零碎的問題了，記的有一次對用戶的登錄過程進行優化，導致有一塊推斷少了一個括號結果用戶在那兩個小時內，僅僅要輸入賬戶，隨意password就能夠登錄了。幸好及時發現這個問題，正是這個問題才導致了我們正式確立了規範的上線流程，為以後的上線制度建定了基礎。

另一次我們在模擬用戶投資一種標的時候，留了一個入口通過http就能夠調用，測試也沒有問題。有一天正好給領導演示呢。就在次用http請求的方式在瀏覽器運行了一下，前端就會看到自己主動投標的過程。由於生產的數據有點多。投標的過程有點長，我們為了加快進度。找了好幾個人同一時候來運行這http請求，導致最後出現了問題。最後發現寫測試腳本的這個同事根本就沒有考慮並發的情況，才導致出現了問題。

也做了非常多的活動，記得做一個網貸之家的一個活動的時候。活動上線比較緊張，我們團隊以前連續工作超過30個小時（一天一夜再一天），當天晚上我2點左右寫完程序，測試從2兩點測試到早上9點，最終確認沒有不論什麽問題，才進行投產。半夜公司沒有暖氣，我們實在凍的不行了。就在辦公室跑步。從這頭跑到那頭，第二天上線之後，又害怕出現故障。監控了一天，確認沒有不論什麽問題。才到下午正常下班回家，那時候真是激情滿滿呀。

說到做活動肯定少了羊毛黨，說哪一家互金公司沒有遇到過羊毛黨那非常少見，並且如今的羊毛黨規模簡直逆天了，我們用戶裏面就有一個羊毛黨在兩三天之內邀請了六七千位用戶，假設說邀請一個用戶送1元。那這個用戶就能夠搞幾千塊一次，並且有非常多專業的站點、QQ群、微信公共賬號都是他們的聚集地，那天那個平臺有活動門清，他們寫的淘羊毛操作手冊有時候比我們官網的幫助文檔還清晰，所以做活動的時候要考慮特別周全，各種限制，有封定、有預案、講誠信。僅僅要是符合我們活動規則的堅決依照流程走。

另一個有趣的事情，app推送。一次我在公交車上就看到xx盒子app彈出hhhhh的推送，這個事情我們也搞過，由於在調試的時候生產和測試就差了一個參數。有時候開發者不註意就把生產參數部署到uat環境了，測試一發送就跑到生產了。這方面僅僅能嚴格流產管理來防止了。

事實上還非常多問題：mongodb集群和mysql的同步出現的一些狀況、後臺大量數據查詢下的sql優化、golang使用mapreduce碰到的問題… 限於篇幅這裏就不一一清晰的描寫敘述了。

事實上每次的出現故障都是對團隊一次非常好的鍛煉機會，通過發現問題，定位問題。解決這個問題。再次回過頭來反思這些問題；又一次梳理整個環節，
舉一反三避免下次再次出現相似的問題。

正是由於經歷這些種種的困難、考驗才讓團隊變的更強大更穩定，也更體現了流程的重要性。更是避免再次發生相似問題。

總結

古代對將軍的要求是，心有萬馬奔騰而過，而面平靜如湖水可照鏡，在互聯網行業對大牛的要求也同如此，特別是技術的負責人，在面對生產事故的時候。一定首先是安撫同事。靜下下心來找到問題本質在去解決，而不是不斷去施加壓力催促解決。重壓之下非常多心裏承受能力稍弱的隊友，更加慌亂而不利於解決這個問題或者引發二次事故。

在看淘寶雙十一視頻中，有一段特別受到感觸，在雙十一初期，盡管技術團隊做了非常多的準備，可是在零點過後流量瞬間湧入。服務被打垮。部分用戶投訴刷新不出網頁，緊接著隔壁同事也都反饋站點打不開，在大家都在慌亂中，xx一拍桌子大喊一聲，大家都別動，三分鐘之後再說。過了幾分鐘之後服務慢慢部分恢復了正常。

後來回顧說，當時盡管服務癱瘓。可是監控還是有部分得業務成功。說明系統並沒有被壓垮，而此時的不論什麽操作都有可能引發更大的問題，從此之後此人一戰成名。成為阿裏大將。

互聯網平臺發展大抵都會經歷三個階段：

• 1、上線初期，此階段問題最為繁多，生產事故不斷。系統高速叠代優化。有人說為什麽不測試到全然沒有問題在投產嗎？說實話在互聯網行業這個非常難，第一小公司非常難做到生產環境和測試環境一致，成本太高；時間緊迫。一般都是非常短的時間內要求上線。上線之後在高速叠代。

  另外互聯網本就是一個高速試錯的行業。錯過半年時間可能風口早過。

• 2、發展期，此階段主要業務模式已經得到驗證，系統出現故障的頻繁度較少，低級錯誤降低，但此時是用戶量和交易量不斷爆發的時候，對系統性能、高並發的要求又上來了，所以此時出現的問題大多都是性能的問題；

• 3、成熟期，發展期過後系統相對照較平穩，用戶量和交易量都已經慢慢穩定下來，生產問題越來越少，出現故障差點兒都是細小的bug，這個階段也是公司最忽略技術得階段，恰好我們公司就處於這個階段，在這個階段就須要靜下心裏。組織架構升級，補齊在初期和發展起所欠的技術債務，做好公司在升下一個量級的技術準備。

全部的這些問題差點兒都集中在14年底到15年初的這個階段，15年後半年開始到如今平臺慢慢穩定了下來，到如今差點兒沒有再出現過相似的問題。也由於差點兒都是兩年前的事情。有非常多記的不是特別清晰了，寫的比較粗糙望見諒。

作者：清純的微笑
出處：http://www.ityouknow.com/
版權歸作者全部。轉載請註明出處

百億互金平臺救火故事