How to survive in the 1111 - 陳道陞 (Tao-Sheng)

tags: 2023

Key elements

• Estimation for the worst/best?
• Money talks but can't buy everything
• Alignment with Business(know the traffic behavior)
  • Auto-Scale 還是事後指標 仍會造成slow response

Estimation

• Planning for the target and estimation on the resources

活動內容（99% cash back）
流量來源（裝置是手機還是瀏覽器，信件連結？
Infra or SRE 把需求轉成所需的資源準備，是每次的挑戰

Load testing

Simulation in Production env
(仿真測試，因為在驗證環境可能無法真的反應出狀況，或是正式環境的資料也不可能搬移到驗證環境)

• Avoid resource leaking
• Gain confidence
• Pick right timing (4am)
  有些日常排程，重要性相對低，在負載高時，可以先捨棄不跑

Planning

• Plan ahead of the time
• D-Day plan
  • Worst case plan
  • On-duty schedule
• Technically readiness
• No silver bullet
  • public cloud is good…but
  • k8s is good…but(需要reserve node，這樣要長pod 也需要有Node，不然會卡在EC2的時間)
    雙11會需要開 spot instance 可能性很低，因為大家都要擴容
    所以得前兩天先將 spot instance 改成 reversed instance
    ㄎ

D-Day

• On-Duty
• Process
• Leadership

====== 聊天區 ======
本來想嘗試寫什麼
不過後來想想還是算了
-> 我光看標題還以為是1111的人來講，結果是shopback，剛剛還在想說怎麼找不到筆記XD

剛開始聲音太小了哈哈

看標題本來以為是在1111的工作經驗，結果原來是1111流量存活，好像可以期待

真的 同意
對！我也以為是

好像短延時強降雨的圖ㄎㄎ
XD
可是shopback有需要及時處理嗎？
優惠審核大概會超過一個月(之前的使用印象
-> 自信點，把大概去掉，我自己就有一拖拉庫，零零總總加起來差不多要等超過一年ㄌ
這什麼水文發言，我PTSD了
大氣版看太多ㄎㄎ

有需要吧 朋友在那邊 1111 都要先試跑

可是 Shopback 主要是 Chrome 擴充套件，拿來蒐集使用者資訊
應該可以用非同步，設計成 Queue 處理吧？
做為第三方服務，需要跟電商串接資料，所以還是需要即時處理吧？
後續資料處理應該就可以緩衝了
個人淺見，要做即時的部分應該是跟電商串接，後續的點數回饋可以用非同步
只需要確保該次消費有被驅動回饋事件應該就OK
對欸Shopback有App

聽起來需要進後端交涉

K8S 是事後成長，不是事前成長
所以我們要預判使用者的預判
這樣才可以應付大流量嗎？？？
事前成長應該本來就只能用預判的吧XD
就跟張惠妹演唱會，飯店先把房價漲起來一樣
還有BP啊！賣一堆假票
GAN 太賤惹

之前聽 KKTIX 賣票，也是搶票前先把機器開好
我朋友公司也是有搶購機制的，也都是預先開好

還好不是分享 ANA Bug 票
不然我會懷疑講者前幾天才做好投影片
!! 完全沒發摟到這個新聞

Load test為什麼不建立staging環境要在production測試呢？如果生產環境24小時都在使用，應該不能這樣搞吧XD
成本&資料？
上面共筆有稍微記錄到
-> 所以才要在離峰時間

正式…環境…壓測…