大促準備（八）大促當天執行

通過了前面的各類準備，大促終於到了，在大促當天要關注的事情也是至關多的，須要有條不紊的循序漸進的執行。

1.值班安排

大促期間執行、驗證、觀察的事項仍是比較多的，最好是有兩我的進行主備，每一件事情最好可以double check，而且作好事項的分工。

2.應用服務器磁盤空間清理|重啓

系統在運行過程當中一般會打印多種的日誌，日誌打印的速度要比系統的執行速度慢上很多，若是在打印日誌的過程當中發現磁盤空間不夠用，還須要進行磁盤清理，將老的日誌文件給清除掉。這種操做是很佔用cpu和io資源，嚴重的話會把系統夯住，致使請求大量超時。於是在大促高峯前須要對應用服務器的磁盤進行清理，只保留最少許的文件，下降高峯前由於打印日誌引起的系統的不可用風險。

對於採用java語言的系統，服務器重啓主要是爲了釋放內存，避免在高峯期發生old區gc或者full gc，使得系統暫時不可用，影響上游系統的調用

3.限流推送和驗證

在平常狀況下，限流的模式多是監控模式，在大促高峯期須要設置爲攔截模式，避免系統雪崩。
主要是根據線上確切的服務器數量和大促預期峯值，肯定單機限流值，然後推送到全集羣。推送以後就是驗證了，這個驗證一方面是單機抽查，另外一方面靠系統的監控。

4.預案推送和驗證

在臨近高峯期前，會推送預案，一般會設置定時預案執行集，這樣不用一個一個預案的推送，減小工做量也能統一管理，於是要確保本身系統的預案配置在了預案集中了。
雖然預案的驗證工做量相對會多些，可是按照以前肯定好的驗證list循序漸進的驗證就能夠了，能夠作到忙而不亂。

5.監控準備

大促高峯期主要須要監控的事項比較多：error、rt、cpu、load、gc、db、tair、message、限流、下游主要系統等、上游主要系統等，須要根據以前的分工來監控不一樣的事項。在高峯來臨前將對應的監控打開準備好觀察，同時web形式的監控由於會涉及到日誌的打印、傳輸、計算、展示等操做，會有必定的延時，於是最好可以打開相應的終端，登陸上對應的服務器，使用腳本或者命令實時查看服務器的狀態。

6.高峯期觀察&應急

雖然前面經歷了大量的準備工做和各類各樣的預案，咱們也指望大促能按照咱們的指望來進行的。但天有不測風雲，仍然有可能發生預料以外的事情，這個時候更多的依賴系統owner的平時的積累了，綜合評估狀況在很短的時間內採起應對措施。
經常使用的手段就是限流、降級、熔斷，還有一種就是靜觀其變，等待高峯期本身過去，具體採起哪一種措施要依問題嚴重程度、是否會持續等來綜合評估，別人都是旁觀者、建議者，真正能作決定的就是系統owner，要爲決策負責的也是系統owner，也真是這種決策的壓力促使owner成長。

若是沒有預料外的事情發生，就靜靜的觀察監控，分析思考高峯期的種種現象。

7.大促數據記錄

此次的大促是對前一段工做的檢驗，也是下一個大促的起點，此次大促高峯期的各項數據將會對下一次的大促的準備提供很是好的基礎，於是要對大促期間的數據作好記錄並備案，供之後進行分享參考，記錄的數據主要有兩類：
1）高峯數據，瞭解各類峯值
2）全天數據，瞭解全天的變化

8.預案、限流回滾

當大促高峯或者活動結束後，一般會把以前推送的預案和限流進行回滾。回滾一般也是配置在預案集中的，進行集中的回滾。回滾的時候一樣要注意觀察，特別是上游降級預案的回滾，極可能是會致使本身系統的調用量猛增，至關於又來了一次高峯，千萬不要由於大促過去了就掉以輕心，在最後的關頭出故障。