運營活動系統(tǒng)防撲街指南
運營同學(xué)搞活動,最不希望看到的,恐怕就是系統(tǒng)撲街了。這種事情似乎沒什么辦法,公司程序員水平太次,總拖后腿,我能怎么辦?我也很為難啊。其實,這事未必都是程序員的鍋,作為運營同學(xué),要想避免系統(tǒng)撲街也是有方法可以遵循的。
那么常見的活動撲街都有哪些表現(xiàn)呢?
通常,按照技術(shù)的專業(yè)術(shù)語來講,有 40x 及 50x 系列。我們在網(wǎng)站上經(jīng)常能見到的,就是類似 “404 頁面找不到了“,這種提示??赡苓€配有卡通和賣萌的文案,但是實質(zhì)都一樣,就是系統(tǒng)找不到你要訪問的頁面。
還有就是 50x 系列,會提示類似“啊哦,系統(tǒng)崩潰了~”,或者“系統(tǒng)繁忙,請稍后再試”。意思就是系統(tǒng)真的撲街了,崩潰了。
更輕量一點的,可能是頁面長時間加載中,部分或者全部內(nèi)容不可見。這說明系統(tǒng)的響應(yīng)超時了,忙不過來了。當(dāng)然這里要排除客戶端的網(wǎng)絡(luò)因素,也可能是網(wǎng)絡(luò)太慢導(dǎo)致。
對于比較復(fù)雜的網(wǎng)頁來說,由于各個模塊可能是分開加載的內(nèi)容,所以也有可能部分內(nèi)容不可見,即單個數(shù)據(jù)接口掛掉,或者忙不過來了,比如頁面的一個排行榜長時間加載不出來。
那么,作為運營同學(xué),對于這些常見的錯誤,我們能做些什么呢?下面,按照錯誤的嚴(yán)重級別,我們分別進行講解。
No.1:50x 應(yīng)對方案
首先,最嚴(yán)重的莫過于 50x 系列了,就是系統(tǒng)真的掛了。這種情況有可能是運維的鍋,也可能是程序員的鍋,導(dǎo)致系統(tǒng)架構(gòu)不合理,代碼不合理,或者機器性能不足,帶寬不夠等等。排除程序錯誤的硬傷,這些都可以概括為“系統(tǒng)能力與所承接的流量不匹配”。也就是說,你的系統(tǒng)承接不了這么大的流量。
我們都知道系統(tǒng)扛不住可以加機器,但是加機器也有局限性,比如臨時擴充的速度,多臺機器數(shù)據(jù)同步等問題,流量到了某個量級,就不是加機器能解決的問題了。
那我們能做什么呢?
那就是,預(yù)估活動流量,提前周知開發(fā)和運維以及其他相關(guān)人員。如果不好預(yù)估,那么可以讓相關(guān)技術(shù)同學(xué)根據(jù)以往活動的經(jīng)驗,在預(yù)算允許的情況下,盡量為系統(tǒng)多預(yù)留一些能力,比如加機器,提升帶寬等。很多時候不是機器不行,而是出口帶寬受限,比如調(diào)用微信的 api 慢,往往是自身機器出口帶寬不夠,而不是微信的服務(wù)器慢。提前多留點余地總比系統(tǒng)掛掉強。接不住的流量沒有任何意義,反而會影響品牌口碑。
No.2:40x 應(yīng)對方案
對于這類錯誤,往往是查找文檔出了問題,常見的原因可能是服務(wù)器權(quán)限問題導(dǎo)致 403,路徑配置錯誤或者文件沒有發(fā)布成功導(dǎo)致 404。那么運營同學(xué)尤其要注意的是,在一些可配置的地方粘貼的 URL 是否符合規(guī)范,比如是否包含特殊字符,參數(shù)的?和 & 是否使用正確等等。有些時候僅僅是因為鏈接配置錯誤,才導(dǎo)致的 404,這完全是可以避免的。
還有種可能是開發(fā)哥發(fā)布失敗,那么對于重要的活動,周知上線后,不管有多忙,一定要自己親自體驗一遍,不要因為別人的錯誤,影響了自己的工作。
No.3:響應(yīng)慢的應(yīng)對方案
系統(tǒng)響應(yīng)慢往往是 50x 的前兆,如果長時間無響應(yīng),這個接口的后端進程就可能被殺死,那么這次客戶端的網(wǎng)絡(luò)請求,就無法響應(yīng)了。歸根結(jié)底,還是系統(tǒng)能力與承接流量不匹配。那么,除了前面講到的提前加機器,加帶寬,還有沒有什么可以做的呢?當(dāng)然有。
如果這種問題經(jīng)常出現(xiàn),那么一定要提需求讓開發(fā)和運維哥優(yōu)化系統(tǒng)架構(gòu),優(yōu)化程序代碼,增加多級緩存等等操作,提升系統(tǒng)的抗壓能力。
對于活動的節(jié)奏,往往也是有彈性空間的,比如公眾號推送,可以選擇分組推送,用戶對于自己比別人收到消息早點晚點,是沒什么感知的。稍微分分組,就可以有效緩解系統(tǒng)壓力。還有就是推送的圖文消息中,鏈接到自己系統(tǒng)的入口放在哪個位置也很關(guān)鍵,比如放在頁面底部,那在用戶瀏覽頁面的時候,就已經(jīng)在時間上拉開了差距,分散了系統(tǒng)的壓力。
有些系統(tǒng)壓力,是定時任務(wù)造成的,比如業(yè)務(wù)需求中經(jīng)常有些“自動任務(wù)”,在每天的特定時間執(zhí)行。而對于每日的定時任務(wù),許多開發(fā)哥會默認(rèn)使用 00:00 這個時間設(shè)置,從而導(dǎo)致每天的 00:00 系統(tǒng)負(fù)載都處于高峰。而運營活動也喜歡在這個時間,比如雙十一的搶購,付尾款等等。這就導(dǎo)致壓力都集中在了一起,自己都把自己拖垮了。
對于這部分,我們能做的就是考慮下這些定時任務(wù)的需求,能否不在 00:00 整,比如凌晨 02:00 執(zhí)行是否可行?這樣至少能把我們內(nèi)部的壓力分散開來,然后才有資源去承接外部的流量壓力。
通過修改活動規(guī)則也是可以分散壓力的。你可以不要求大家都在很小的時間窗口來搶購,而是稍微拉長一點活動節(jié)奏。比如連續(xù)簽到打卡之類。
No.4:躲不開的流量
前面的方案都是分散系統(tǒng)的整體流量,那么對于已經(jīng)來了的流量,有沒有什么辦法呢?前面說過,一定程度內(nèi)可以加機器硬抗,但是最好提前有準(zhǔn)備,不然可能擴容搞定了,瞬間的流量高峰已經(jīng)過去了。
那么對于已經(jīng)進入我們頁面的用戶來說,我們還可以通過修改交互的方式,使消耗系統(tǒng)資源多的操作滯后。比如頁面如果一進來就直接操作數(shù)據(jù)庫查詢一個大的排行榜,就很耗資源。當(dāng)然,這種情況可以用緩存來解決,但是有些情況是很難緩存,比如:查銀行余額、積分余額等。這些資產(chǎn)相關(guān)往往要求高度的實時性,那么我們能做的,就只有設(shè)計一個可以拉開流量的交互。
典型的例子是,活動邏輯很重,為了拉低流量高峰,在活動頁前面加前導(dǎo)頁,做氛圍圖和活動說明,然后增加按鈕“立即參與”,然后才去邏輯更重的活動頁。這樣雖然稍微有損用戶體驗,但是也比高峰時候頁面卡在那里強。由于每個人瀏覽和點擊的時間不一樣,這種方法可以有效削峰。
同理,對于實時性要求不高的業(yè)務(wù)邏輯,可以異步化,稍微晚一點更新也沒關(guān)系。這樣就可以用定時任務(wù)去處理,哪怕時間間隔短一點,也是按照隊列井然有序在處理,不會一下子吃掉系統(tǒng)的資源。對于搶購等業(yè)務(wù),更是要強制設(shè)計成排隊機制,不管來多少人,都不做太重的業(yè)務(wù)邏輯,先丟到隊列里去等待,我們只選部分人繼續(xù)后面的業(yè)務(wù)邏輯。這些內(nèi)容又很大程度上依賴系統(tǒng)架構(gòu)師的工作,這里就不討論了。
最后,臨時出了問題,還是趕緊去找開發(fā)哥,運維哥,千萬別猶豫。即事中的應(yīng)急方案,如果沒有提前制定,只能靠技術(shù)人員的應(yīng)變能力了。然后事后再通過活動復(fù)盤,總結(jié)各方經(jīng)驗與教訓(xùn),避免下次悲劇的發(fā)生。
總結(jié)一下,核心就是以下 6 點:
- 整體活動節(jié)奏周知,事前預(yù)防;
- 檢查配置信息,是否人為錯誤;
- 修改活動規(guī)則,拉長活動時間,分組推送;
- 修改交互,邏輯后置;
- 提前計劃事中應(yīng)急方案;
- 事后復(fù)盤,總結(jié)教訓(xùn)。
怎么樣,各位同學(xué)學(xué)會了嗎?
#專欄作家#
姬小光,微信公眾號:姬小光(ID:hi-laser),人人都是產(chǎn)品經(jīng)理專欄作家?,F(xiàn)任美的集團電子商務(wù)有限公司商城前端組負(fù)責(zé)人,曾就職于淘寶/騰訊/京東,擁有 10 年電商研發(fā)經(jīng)驗,對產(chǎn)品、設(shè)計、研發(fā)、運營都有一定見解。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議
- 目前還沒評論,等你發(fā)揮!