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

###### tags: `2023`
{%hackmd @sre-conf/H1pCafrG3 %}

### 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
成本&資料？
上面共筆有稍微記錄到
-> 所以才要在離峰時間

正式...環境...壓測...