在這個大促的日子聊一聊我的大促經歷
4個618，3個雙十一的經歷寫出來分享。
之前在某東待了3年半，經歷了4個618，3個雙十一。之前所在的團隊是京東PC端三級列表頁，關於我們專案的架構介紹，可以參考這篇文章。每年兩次大促，每年也需要為這兩次大促進行長達一個月的準備。
壓測
壓測不光是要大促的時候壓，平時每個月都會壓。每個月壓單機，壓的連結是線上抓取的真實訪問連結，我們線下找一臺機器。壓測單機會根據不同的併發進行壓，一般從5併發開始，逐漸增加，直到TP99下降到不可接受為止。每次壓測都會和之前的進行對比，如果發現效能下降，需要定位原因和優化。
大促壓測每年集中在5月和10月，會在夜裡進行。整個專案組的所有機器（或者一個機房的所有機器）進行壓測，從入口開始壓。大促前的壓測標準是之前大促峰值的流量，能夠能扛得住之前峰值的倍數，能達標就行，不能的話需要優化或者加機器（主要還是加機器）。
全鏈路加測。這個是最近開始搞的，全公司的同一個夜裡一起加班壓。這個會模擬當時的實時流量，並不會像單獨壓測的時候那麼狠。
效能
對於效能最重要的指標還是TP99，公司對效能其實有不成文的規定，TP99要小於200ms。如果大於這個值，使用者會明顯覺得卡頓。
禁止讀庫、禁止跨機房呼叫
線上只讀服務，比如我們列表服務，禁止直連資料庫。使用者的任何操作都不能發生資料庫操作。平時我們經常會寫這種介面：取快取讀資料，沒有的話去讀庫，然後把資料設定到快取裡。這種方案只適用於小流量的情況，一旦資料庫來個慢查詢或者資料量變大，所有介面都會掛，所有哦。這也算是雪崩的一種吧。
跨機房呼叫一個是慢，一個是這樣的話就失去了雙活的意義了。不過我們的降級方案裡有跨機房方案，不過常規方案裡要禁止。
監控
監控非常重要。程式介面和關鍵模組都需要加監控，包括效能和流量監控，報警閾值也需要調整成一個合理的值。傳送異常問題需要能立刻報警。
除了介面監控，還需要有例項監控，防止機器或者服務掛了自己沒有感知影響到了使用者。一般我會選擇監聽埠獲取發起一個HTTP請求來檢測存活。之前就遇到一個問題，重啟nginx失敗了，沒有設定報警，導致重新整理頁面會偶爾跳錯誤頁，害得我會滾程式碼第二天才重新上。
還有一種監控是針對頁面的，定時呼叫指定頁面，並渲染頁面，渲染完成後通過抓取頁面上的HTML資訊檢測業務是否正確。迴歸測試中非常有用。
服務降級
依賴的模組有時候會發生異常，比如Redis，每過幾個月就會來一次，一般原因是某個分片過大，分片過大效能會下降。還有一些情況，比如硬體維修，這個時候需要摘機器等。
方案有很多，比如雙機房，雙叢集，多組Redis等。當時我們設計了十幾套降級方案，儘量把所有的降級操作都壓縮到最小。
兜底
上面說了，nginx出錯會跳錯誤頁，而不是nginx的預設錯誤頁。而我們的要求是三級列表頁能根據每個類目跳兜底頁面。也就是說，兜底的時候使用者有可能並不會發現我們兜底了。這樣可以保證在後端服務發生任何異常的時候都能給使用者一個友好的頁面。
對於一個電商而且是上市技術公司來說，兜底是非常重要的，它會影響到公司的股價。如果發生時間很長的故障，而且又引發一些輿論效應的話，損失的就不是那些訂單了，而是市值。分享一個真實的事情：有一次我的接口出了問題，沒有返回正常的資料，前端介面沒有相容，在使用者端看到了nginx的404頁面，當時要求第一個要修復的是兜底方案。
事故
寫到這裡，線上緊急問題的處理方法已經有了，自動的有兜底，手動的是報警+降級操作。可以這麼說，這幾個部分是影響績效的最重要因素。線上問題不管多麼嚴重，衡量級別的最重要因素是影響時間，處理得快，比如十五分鐘內，問題不算大；如果超過半個小時，事故級別就會往上走了。
處理事故最重要的，還是要快。自己操作時需要權衡，如何快速恢復。處理問題最差的方案是改程式碼。如果實在找不到問題，可以考慮強制更改資料庫或者快取來解決。緊急問題處理的快慢主要還是看平時專案預留了多少除錯的方案和快速定位問題的輔助工具。真發生緊急問題一般會比較著急，沒辦法集中注意力，所以前面提到的除錯工具或者降級方案就顯得很重要了。
值班
進入6月份和11月份就要封版了，那個時候也沒啥需求了，主要就是值班。一般1號是秒殺日，那天凌晨需要值班。移動端的流量很大，移動是未來啊。有時候每個夜裡都得留人值班，不是每次都這樣，這個主要是領導決定。17和10號夜裡一定得留在公司值班，夜裡也不能回家，2點流量下來後需要到公司附近的酒店休息，早上8點前回來，因為早上8點有秒殺。
連夜值班我還是比較喜歡的，可以換調休，第二天還可以休息一天。一個組的會經常大促一起開房，大家的基情是其它公司比不了的。
每次值班領導都會給買吃的，各種吃的，還有飲料，我最喜歡的還是那個豚骨湯泡麵，在每個值班的夜裡，泡一碗，周圍都是這個味，最後大家都開始吃這個了。
一般17號或10的時候就需要進值班室了，值班室挺擠的，大家在那裡呆一宿，全是味。在那邊有基礎服務的人，出了問題方便解決。0點的量真的很大，那個時候大家都很緊張。
講一個真實的值班情況：那天我像往常一樣在值班，那是我第一次負責我們組所有的大促服務穩定和降級策略，所有準備工作都像往常一樣過完了，能想到的意外情況也都做了準備，但還是發生了意外。10號晚上23:20，流量突然可以激增，是平時流量的幾倍，觸發了報警。看到流量還在上漲，就得找上漲的源頭。我們的服務除了給自己的列表用，其它部門也會呼叫，我們把請求量大的都做了單獨的監控，但是這次的流量上漲卻沒找到源頭。這個平時量太小，被我忽略了。沒辦法，只能上nginx去看access log，找出流量來源。發生這種情況，都很意外，不過我們服務效能很好（曾經有一度可以單臺抗所有量），我定位起來也就沒有很緊張了。後來找到了呼叫方，他們在大促前更新了快取服務，這個服務並不是那麼可靠，導致10號晚上快取被擊穿，流量回源，全到我了這裡。平時QPS應該是個零點幾的樣子，那天晚上那麼短的時間QPS有幾十萬，還好我們服務扛得住，否則的話只能把這個來源降級了。
很多情況下問題就是這麼來的，你覺得可以沒什麼，優化了一把，跑得也正常，大促極端情況下就會被擊穿了，下游服務都扛住了，如果下游依賴的很多服務因為流量突然上漲沒有扛住，問題就很嚴重了。
最後
今年雙11是第一次沒有親自參與的大促，我自己也沒買什麼，感覺大促氣氛不像以前那麼濃烈了，大家是什麼感覺呢？