某618大促項目的復盤總結

一、前言

618期間上線一個活動項目。但上線不順利,當天就出現了性能問題,接口超時,用戶無法打開網頁,最后不得的臨時下線。花了三天兩夜,重構了后臺核心代碼,才讓活動進行下去。

回頭看了一下自己的時間記錄,從5月31號那天晚上8點25分開始準備上線,發現異常,分析原因,重構代碼,離開公司時已經是6月2號的23點54,經歷51小時29分,中間的睡眠時間不到5個小時,這已經是爆發小宇宙了。

這一波剛過去了,一波未平另一波又起,由于活動的獎勵豐厚,大批羊毛黨聞風而至,某寶上公開賣腳本的都有了,嚴重影響了正常用戶薅羊毛。

某客戶反饋說:我們別說薅羊毛了,現在是整頭羊都被他們牽走了!

接下來的幾天,又得和薅羊毛的腳本們斗智斗勇,直到活動結束。

而本文就對此做一次深度的復盤,在以后的項目中讓自己快活一點。

二、一份看似完美的項目總結

當我們復盤項目過程時,能找到很多問題點,比如:

  1. 人力不足,需求過于復雜,開發和測試工作量大。

  2. 前后端開發、測試都是從其他團隊抽掉的,對當前項目的業務和技術不熟悉。

  3. 跨團隊組建的臨時團隊,職責定義不清晰,項目管控不嚴格。

  4. 開發對項目的用到的技術不熟悉,沒有經過原有項目成員的CodeReview。

  5. 測試通過太草率,壓測方案設計不合理。

....

列出問題后,很快就能一一寫出改進點。

  1. 從公司層面加強的整體項目安排,避免重復玩法的項目,資源投入到重點的幾個活動中。

  2. 加強團隊的能力培養,總結文檔,供新人學習。

  3. 對于核心代碼進行CodeReview,遇到問題時,項目經理協調資深開發協助解決。

  4. 將臨時組建團隊職責定義清晰,各負責人溝通清楚。

  5. 嚴格控制測試質量,測試有上線的否決權。

...

這些總結看起來一點問題沒有,列出了問題,也列出了改進點,甚至可以當成樣板去使用了,是不是咱們就這么結束了呢。

當然不是, 它本身的說法沒有錯,錯在把問題的前提當作問題的原因。

我們來看兩種表述。

  1. 下次我們要組建一個經驗豐富的項目團隊,避免質量問題發生。

  2. 當下次我們面臨一個臨時組建,經驗不足的項目團隊時,如何避免質量問題發生。

這兩種表述的差異在哪?

前一種表述是因為我們“團隊”的原因,導致了本次質量問題,所以我們要解決“團隊”的問題。

而后一種是我們的團隊就是臨時組建的,我們的開發、測試就是對新項目的業務和技術不熟悉,在這個前提下,才會出現質量問題,那么在這個前提下,怎么避免質量問題呢?

臨時組建,經驗不足不是問題的原因,它們是出現問題的前提,這是客觀存在的。

這就好比我們說解決一個問題時,最快的方式是,我們不解決問題,解決出問題的人就行了。

在這里不就變成了,我們不解決問題,解決出問題的團隊就行了。

正是因為這個誤區,我們很多時候一出現項目質量問題,就把鍋甩給我們團隊的協作有問題,或者我們的項目時間緊張,然后一句下次改進就結束了。

這樣的萬能回答,看似一點沒錯,但往往就沒法落地了。

明明項目時間緊,新團隊協作經驗不足本來就客觀的存在,沒有它就沒有問題,怎么可以當作問題本身給解決掉呢。

1、質量問題的關鍵原因

帶著這個前提,我們再回頭看前面的總結,其實就能過濾出真正有價值的點了。

我們也可以這么問,問題是不能避免的,但為什么在項目過程中我們的性能問題沒有暴露出來?

三個角度:

  1. 從項目角度,沒有嚴格按項目流程來,特別是最后測試任務緊張,bug較多時,趕工給出了測試報告。

  2. 從開發角度,沒有找熟悉業務和技術的同學做CodeReview。

  3. 從測試角度,壓測方案設計不合理,不符合真實場景。

逐一分析下。

前面提到事故是后臺的性能問題,從項目角度,就算流程嚴謹也沒法暴露出性能問題,特別是在項目過程中,已暴露的風險是前端人力不足,中間加了人手,從功能的角度,后端進度完全正常。

再看開發角度,這里我沒有提開發的經驗不足,不是在推脫責任,這同我們作為一個臨時團隊對業務的經驗不足一樣,它是一個客觀存在的前提。當你接觸新項目,使用新技術時,經驗不足是肯定存在的。

問題是在自身經驗不足時,如何去完成任務,那么和熟悉業務和技術的同學做CodeReview是主要的手段。

再從測試角度,功能測試是沒有問題的,但跟性能相關的壓測方案是有問題的,并且一開始就沒有引起正視。最開始的壓測方案是開發只出接口和參數文檔,直接丟給測試去壓,現在看來,這是錯誤的。

因此,這次質量問題的關鍵總結如下。

當下次我們面臨一個臨時組建,經驗不足的項目團隊時,面對大流量的業務需求,開發們需要注意:

  1. 讓熟悉業務和技術的同學幫忙做CodeReview。

  2. 設計出符合業務場景的壓測方案。

這兩點就可以落地了,這也不是說項目管理上沒有改進的,而是優先保證這兩點,能更有效的降低風險。

CodeReview的技巧這里就不多少說,來談談我們做的幾次壓測方案的改進。

2、三輪的壓測改進

  1. 單用戶,單接口,雙機壓測

  2. 隨機用戶,多接口,全量壓測

  3. 隨機用戶,功能分組接口,全量壓測

最開始壓測方案是用一個用戶,兩臺服務器,一個緩存分片做壓測,然后簡單的用服務器QPS的均值乘以線上部署機器數量當作壓測結果。

這個方案如果是下圖左側的場景,調用鏈路上的服務器可以同時彈性擴展自然是可以的。

但要是右側的場景,調用鏈路上存在瓶頸,比如數據庫是一個節點,并且無法擴展,那就問題了。

同樣的,這次項目的問題就是Redis成為了一個單節點的瓶頸。另外由于用戶id是固定的,所以緩存很可能被重復使用,這樣就難以測試到頻繁創建緩存的場景。

在系統重構后,改進了一種壓測方案,通過隨機用戶Id,批量輪詢接口,并且通過測試環境的彈性擴展,完全模擬線上的部署環境

還通過加降級開關,把入參合法性、風控、時效性校驗等臨時關閉,以便能讓壓測的請求貫穿整個主流程。

接著在這一方案的基礎上,通過對接口分組和偽造恰當的數據,編寫貼近真實的調用行為的腳本,再次做了壓測。

在執行人員上,也經歷了從開發提供數據,測試全權負責;到測試主導,開發參與;再到開發主導,測試協助的過程。

由此,壓測方案就越來越貼近真實場景,壓測結論自然就更加可信 。

3、高并發場景下的設計

前面談到了系統設計的不合理導致了本次性能問題,來分析下這里面的根本原因。

首先要理解的是,Redis集群是由多個分片構成的,一條數據被寫到哪個分片里,是由key的hash值來離散的。

比如說,我們要在Redis里面緩存一批用戶信息,并且能通過ID來存取。

如果用Redis自帶的Hash表結構寫法如下:

存:redis.hset("userMap",ID,userInfo)

讀:redis.hget("userMap",ID)

那么,因為key是固定的userMap,這意味著所有的用戶信息都會被寫到一個分片里。

而對于通常的分布式系統的設計,一個基本原則是:讓流量盡可能的被集群的機器平攤。

固定的key就無法利用分布式的優勢了,并且如果并發量高,這就會讓一個分片去抗所有的流量,再加上如果用戶量數十萬,還有一次性讀取所有數據的操作,這樣就變成一場災難了。

實際設計時,直接把整個Redis集群當作一個Hash表的方式更加高效。

存:redis.set("userMap"+ID,userInfo)

讀:redis.get("userMap"+ID)

這里的key="userMap"+ID,ID不同key就被離散了,請求會集群平攤,從而充分發揮分布式系統的性能。

三、黑產和羊毛黨的問題

在項目上線后另一個沒重視的問題出現了,那就是大量的黑產和羊毛黨出現,活動獎勵全被這些用腳本的人占據了。

對黑產的事前考慮太少了,僅做了簡單的風控校驗,根本檢測不足異常用戶,導致黑產可以通過腳本大量刷接口。

這里的經驗有兩點:

  1. 對包含現金、現金等價物或高價值獎勵的活動,要有面對黑產的心理預期。

  2. 在大公司,專業的事情找專業的人做,基于業務場景,提前跟風控團隊溝通好。

對于第一點,基本上只要值點錢的活動,黑產肯定跑不了,空手套白狼,搶到就是賺到,不妨想想如果你是黑產,結合下業務場景,你會怎么來刷自己的系統。

基于第一點,公司沒有風控團隊那就只能自己做了,而一般上點規模的公司都有自己的風控團隊,利用好現成資源。

風控主要考慮兩方面:

  1. 有風控團隊的,接入他們的通用風控模型。

  2. 針對項目的業務場景,定制化一些風控模型。

通用風控模型基本是通過新老賬號、異地登錄、人機識別等等用戶行為建立的用戶畫像,通過離線計算和實時校驗來處理。

定制化模型視情況而定,比如拉一個單獨的小黑戶,放進去的用戶不能參與這個活動等等。

被攔截的用戶一般是走驗證碼或直接拉黑,對于后者,別忘了和客服的妹子們打好招呼,準備下話術應對客訴。

四、結語

最后總結下項目的經驗。

首先是前提:

  1. 當你的面前的是一個臨時組建,對現在項目經驗不足的項目團隊時。

  2. 當你面臨一個大流量,包含現金或等價物的活動時。

請務必做好這三點:

  1. 找熟悉本項目的業務和技術的開發參與方案的設計和CodeReview。

  2. 請開發主動參與壓測任務,設計壓測方案,注意盡可能模擬真實場景。

  3. 做好應對黑產的心理準備,直到大促活動結束。

來自于,一個連續加班51小時29分,被用戶吐槽整只羊都被人家牽走了的開發。

posted on 2019-07-12 09:36  初開  閱讀(15665)  評論(18編輯  收藏

導航

最新chease0ldman老人|无码亚洲人妻下载|大香蕉在线看好吊妞视频这里有精品www|亚洲色情综合网