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