游舒帆Gipi
Nov 11, 2018 · 6 min read

今天是雙11,不過台灣兩大電商平台PChome跟momo卻在今天疑似乘載不了突然湧入的壓力而掛點,我想平台與技術團隊應該壓力山大,但我覺得這是一件很好的事,所以要特別恭喜他們。

不是足夠大的公司,不具有這樣的規模量,你還沒機會遭遇此問題,就如我們過去說的,技術債是屬於那些活下來的公司,至於那些撐不下去的,技術債跟你一點關係也沒有。換句話說,就是你夠大,你才有機會碰到這樣的問題。

大多數一流的網路公司都曾發生過大規模的系統問題,差別只在於局部崩潰或是全面性的崩潰,但在它們長到這麼大之前,這種異常問題還會少見嗎?一點也不,AWS、Facebook、阿里雲、Netflix、LinkedIn這些公司其實都發生過大規模的異常事件,這些公司的工程師的高水平我想大家都略知一二。

一家公司的技術水平,往往都是在遭遇到營運面的困難時,才踏上加速突破的道路。

台灣網路圈這些年來因為市場規模的關係,網站的交易量(transaction)與併發用戶量(concurrent user)一直都不會太大,每秒上千個交易或10萬個併發用戶已經是一線網站,基本上很少有機會讓大家實戰演練一下如何搞定每秒十萬交易跟千萬級併發用戶。

這次雙十一的事件跟兩年前訂票系統的案例,都會推升台灣技術團隊的水平,我們應該更樂觀看待這樣的事件。

很多人,學了一輩子架構設計,但一直都沒有機會在工作中實踐,而各位有這樣的機會,我真心覺得運氣太好了,短期內面對的壓力肯定很大,公司內部甚至會有人建議要殺兩個工程師來祭旗...XD。

長期來說,因為痛過,你更能理解架構設計的重要性,而在這過程中,技術團隊也該把握機會好好陳述技術架構在商業上的重要性,可以將目前潛在的問題做好分析,並提出改善建議。

雖然此時你心裡一定不太爽,但請務必記得不要見獵心起,用「我早說了吧」、「你們就不重視技術,只重視銷售」,這樣容易挑起紛爭的發言,因為這不會讓你的建議獲得採納。請記得,此時只要站在公司的角度去討論這件事,提出目前技術架構上的問題,並提出資源的需求,一般來說大多能得到不錯的結果。

犯錯,重要的是汲取經驗,並且讓這次的傷口成為自己成長的印記。

來自我親身的經驗

三年前我接下公司的維運負責人,當時我們也面臨了許多系統端問題,以下是其中一個當時讓我燃燒了不少生命,但也學到非常多的案例。

CPU Usage 100%
隨著業務量成長,資料庫的存取量也大幅提升,每天到了尖峰時刻,系統就快要乘載不了,最慘的是我們的主資料庫,每天晚上的CPU Usage都是逼近100%,而且一旦上去,短時間內都不會降下來。這是什麼概念,等於同一時間在存取資料庫的所有user,全部都會卡住,動彈不得。

第一次發生,我們只能選擇重新啟動資料庫服務,釋放掉所有的連線,讓所有的user重新連上,當然了,當天晚上的客訴電話可是沒有斷過,公司內的微信群整個炸開,大家都想殺兩個RD來祭旗(笑),但大家都知道,當務之急是找到原因以及解法,當公司的用戶數量每年以倍數在增加時,這樣的問題勢必會成為往下成長的瓶頸。

當天晚上我們當然招集了各系統的負責人以及DBA,討論了很多可能的原因,從資料庫與系統的log中找蛛絲馬跡,一開始大家猜測的原因命中率其實很高:

  1. 資料庫肯定有許多lock
  2. 肯定有一些寫得特別爛的SQL,消耗了大量的DB運算資源,所以CPU衝高
  3. 太多很多inline SQL
  4. 太多排程服務對DB發出request
  5. 太少cache

至於到底是什麼原因,DBA很快地也找出來了,基本上上面這五條全部都中獎,接著又花了幾天把一些執行頻率高,且資源耗損較大的語法都找了出來,我印象中不少於200條,而我們挑選了其中的3條優先處理,因為能爭取到10%使用率的下降,對當時的我們來說就有很大的幫助了。

但改這種沉痾問題,不是一兩天就能搞定的,因此往後的幾天,我們先做了很多workaround,包含尖峰時段所有的RD都避開會存取主資料庫的系統,上線若涉及資料庫存取的,都要先提供給DBA review,確保問題不會持續加重,甚至是在進入尖峰時段前,先將部分服務重新啟動。

若不幸當天晚上的CPU使用率還是爆表,那就先做資料庫重新啟動,那段時間,每天晚上我們就是在監控螢幕前盯著螢幕,隨時準備應付突發狀況。

在還無法優雅面對前,只能選擇最笨的方法,這就是真實的維運生活。

後來在我們將那幾支改寫好的SQL重新上線後,CPU使用率開始平穩地維持在70-80%左右,發揮了一些成效,但我們很清楚,這樣的數字一點也不保險,因此在接下來的一個多月內陸續進行了爛SQL的修復,以及為SQL的寫法做好規範,後來CPU使用率便降到30-40%上下。

那段時間幾乎天天都被highlight,酸言酸語也在所難免,但藉著這種國安等級的重大事件,我們也趁機讓大家知道一些技術性專案的重要性,藉此預警三個月半年內可能會再發生的狀況,並打鐵趁熱,將一些技術性專案的優先順序往前挪,爭取到一部份時間把問題徹底解決

在問題解決前,每天就是面對著千萬營業額可能流失的壓力,現在想想還是覺得超級幸運...XD。

技術重在有實踐的場景
如我前面所說,大家都知道系統會有問題,發生時,也大多能點出問題所在,但這樣的問題卻還是在發生,這意味著,技術的學習與實踐中間,其實存在很大的落差。而我們何其幸運,可以在這樣的時間點,遭遇到一個這種規模的問題,唯一能做的,就是解決它。

資料庫,其實是整個系統中相對難scale的,過去幾年也有多次因為資料庫的問題而搞得我們蓬頭垢面,但我每次面對這樣的問題還是備感興奮,雖然當下的壓力或情緒不見得很好,但我告訴團隊處理過這樣的問題,自己的技術經驗會更加完善。

分庫分表、讀寫分流、異步同步、大規模開發的資料庫管理、高可用的DAO設計、多層資料快取(最多曾思考過6層)、資料庫解耦合、資料架構的重新規劃與設計,這些都是在那段時間內我們討論過的議題,而其中最少有八成,我們後來真的實踐了,如果沒有那樣的挑戰出現,根本沒機會累積這樣的經驗

也非常感謝當時DBA團隊的眾家高手們,不厭其煩的跟我們一塊找問題,並提供很專業的建議,讓我在處理問題的過程中,同時也學習了工程部門如何與DBA做良好的溝通協作。

上禮拜我在FB分享了一位LinkedIn的SRE工程師分享他有一次將LinkedIn搞掛的經驗,其實我非常期待有一天台灣也能有一線網站的工程師出來分享類似的經驗,我相信這對台灣技術水平的提升會大有幫助。

gipi的商業思維筆記

學習/閱讀/思考/傳道

游舒帆Gipi

Written by

商業思維教練暨傳教士,致力於將商業知識科普到所有職場工作者身上。歷任鼎新電腦總監、TutorABC RD head,TGONetworks創會成員暨學習委員。2017年離開職場後開始投入顧問、培訓與教練工作。現為多家網路、電商、傳產公司策略顧問與合作夥伴。

gipi的商業思維筆記

學習/閱讀/思考/傳道

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade