背景
今日公司進行面膜新品發布，新品分享有獎裂變活動，活動效果很好，例外火爆，可是系統很不爭氣掛了20分鐘，作為系統支持的負責人覺得很慚愧，夜不能眠，在進行深深的自省，
程序回顧
作為系統支持負責人我是有一套系統穩定支持的理論：
- 活動方式/內容的理解
- 活動風險的評估
- 活動所需資源的評估
- 活動產品基礎資料在系統核對
- redis扣庫存
- 生產驗證
- 活動核心鏈路壓測
- 服務臺的故障時的指引與術語
- 限流的制定
- 慢URL的梳理
- 應急措施的制定
- 集思廣益的風險梳理
- 活動前24小時變更凍結
- 現場支持人力鎖定
為什么還是掛掉？
為什么還是掛掉呢？是我的套路不行，還是我空有一身“內功”沒有好的“武功”和“寶劍”發揮出來？
武功和寶劍
千里眼和順風耳
- apm工具，可以助我實時掌握系統的流量、吞吐量和回應時間、系統錯誤的定位，
- aiops/grafana系統及應用組件資源使用實時監控
屠龍刀和倚天劍
- aiops的自動擴容助我快速完成節點的縱向和橫向擴容
- 流控系統，助我完成全站和個別URL的流量塑形，
戰隊
我有一幫好兄弟，通力合作：
- 活動產品負責人盡心完成基礎資料的錄入，核對，生產測驗，
- 有開發測驗好兄弟完成功能開發，功能測驗，壓力測驗打磨系統的處理能力，
- 有基礎架構的伙伴們提供計算、網路、安全資源
- 有運維開發的小伙伴打造監控，自動化利器，
- 有穩定支持的伙伴們全程關注，隨時準備系統救援，
- 還有服務臺的小伙伴全程的前端體驗和客戶故障引導，
戰況
- 開局：13：30 分，全部小伙伴就位，13：45觀察到流量攀升，發出預警，13：50穩定性支持的伙伴發現后臺出現大量報錯，向開發測驗發出預警評估是否影響活動，并得到及時回應，直到13：59，系統回應正常，
- 沖擊：14：00，活動開啟，結果14：01，apm利器顯示系統回應變慢（訪問量是歷史峰值6xxx，是過往的2倍），活動前端使用體驗官（服務臺）警告前端白屏，請求超時，穩定支持的團隊立刻檢查各組件使用情況，資源飆升厲害，但未到臨界線，**此時不確定問題所在 **，于是我立刻執行全站限流，確認后備方案APP端是可以使用，然后指引服務臺的兄弟及時與市場溝通；緊接著奔赴開發測驗身邊確認問題是否與之前的報錯是否有關，
- 變陣：14：15 確認問題所在，對問題URL（歷史峰值每秒處理350rps，實質上平均回應時間8秒，估計次數請求處理占用大量應用執行緒）實施限流，流速240rps，全站限流打開以最大量滿足用戶需要；執行擴容，
- 初見成效：14：20 系統使用體驗陸續恢復
- 收尾：受到到開閘沖擊，部分組件出現假死狀態，系統依然不太穩定，偶發出現超時，穩定支持團隊有序重啟組件重整資源，系統使用恢復，
復盤
- 有利器，有好伙伴，為什么開局失利呢？本次活動主要瓶頸于小程式調度微信公共介面code2session，在并發量超過150rps，回傳時間在1s以上，當并發量達到350時，回傳時間是8秒，此時我小程式自身timeout時間是3秒，自身選擇退出，由于改介面強依賴，這個介面失敗后，代碼運行不下去，前端白屏，
- 為什么在慢URL沒有檢查出來，在apm工具中顯示在介面在非活動時間并發量底，回應時間短，我們檢查規則，按調度次數和95線回應時間，最大回應時間綜合緯度評估是發現不了它的存在，
- 如何更有效安撫客戶/業務代表，加強和服務臺的緊密合作和資訊共享，由服務臺及時有序通告“戰況”，
以后要怎么做
- 外部/跨平臺呼叫一律不信任，采用限流方式控制住最佳吞吐和回應時間比，
- 完整梳理一次外部/跨平臺調度介面，
- 介面最大能力的獲知，全站URL/API按實質能力配置限流，
- 制定落實戰況溝通機制，組建作戰室，指揮中心，
- 完善故障根因智能分析工具/平臺，
感概
其實我并不想講每次活動的流量都是過往的幾倍來解釋/開脫故障，我更想說我們的系統平時就像一個懶人那樣，不常做運動，很多指標看著正常，其實都是亞健康，我更希望多做活動，讓系統天天跑步鍛煉，而不是突然間讓他跑馬拉松或200米沖刺跑，如果活動變成日常化，常態化，系統天天得以鍛煉，我們的武功不要生疏，寶劍利器不要生銹，我相信即使跑馬拉松和打大戰役，也是沒有問題的
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/276970.html
標籤：其他
上一篇：使用IDEA連接阿里云Redis
下一篇：2021-04-16 小紅書面經