1.由於整體開發在上線前2天才完成，測試了解這個專案需求是在開發的第二週，並沒有充足的時間進行完善的功能，ui機型適配，系統壓力測試。
此種網路配置方式也導致了之後遇到的部分使用者頁面無法載入時，排除問題難度加大，不能在自己的機房解決。
3.線上應用機器在最後一天才準備好，tomcat及資料庫部署環境的檢查並沒有完全完成，留下了隱患。如mariadb的binlog功能在設定了my.cnf後仍然沒有生成，部分核心表的索引沒有建完全。
並且活動只有七天，經過估算，認為搖獎壓力大部分應該在應用端，資料庫無壓力，所以配置了10幾台tomcat及redis快取，沒有為mariadb配置主從結構做備份，成為了乙個單點。
4.機器準備好後由於此時運維也在做監控及log檢視基礎設施的整體遷移工作，並且人力緊張，在半天時間內只能做一件事情，所以優先做了伺服器監控，這裡另乙個隱患是告警系統。公司內部的伺服器告警系統由支撐部門統一做，認為應該有，所以上線時沒有測試告警功能，埋下了另一顆地雷。
10：30am 還有半小時開始，曾想測試一下將對方**過來的請求重定向，但由於此前官微推送過訊息，在活動開始前,一些零散使用者已經開始訪問活動頁面，但被擋在活動未開始頁面，臨時改程式影響比較大，再加上前一天為了測試介面壓力測試也搞到1點，腦子比較混沌，稍微改了測試下沒有成功，暫時放棄。
11：00am 系統正式開放，使用者已經可以進入轉盤**頁。系統監控正常，系統負載，網路均沒有異常。
4：10pm 公司vpn斷開，由於無法連線就沒法工作，幾個開發轉到茶水間去喝水放鬆。過了一會突然被通知活動頁白屏無法訪問，運維的同事通知說伺服器機房的移動入口線路中斷，趕緊通知支撐部門排查原因；同時緊急切換該網域名稱的位址解析到機房電信ip上，等網域名稱生效理論上需要10分鐘。
4：50pm 斷開的機房入口通道恢復，為了保險還是等了一會才將網域名稱解析ip重新切回到移動線路。
5：00pm 又一波官微訂閱號開始推**引導使用者進入。
7：30pm 幾個人總算有空去找飯吃，悲劇的發現食堂和全家的飯都沒了，只能吃泡麵麵包了。。。
7：50pm 左右運維反饋將所有war包推送完成。
8：00pm 開始排查錯誤發生原因。檢視線上機器tomcat並沒有什麼異常，此時登陸資料庫機器發現在命令列下系統響應速度不正常，命令輸入後2，3秒以上才有反應。
再看top負載，cpu負載很不正常，已經超載，系統load也是一樣。
8：30pm 發現資料庫異常後，決定重啟資料庫。
8：45pm systemctl stop db。 然後就悲劇了，系統負載下來了，但重新start不起來了， mysql error-log中查啟動問題：
innodb: error: log file ./ib_logfile0 is of different size 0 >5256780 bytes查了下資料，正常shutdown後將logfile0刪除後再啟動能成功，為保險將此檔案mv到另外的目錄，再嘗試啟動，仍然起不來，完全暈菜innodb: than specified in the .cnf file 0 1077645824 bytes!
[error] plugin 『innodb』 init function returned error.
[error] plugin 『innodb』 registration as a storage engine failed.
[error] unknown/unsupported storage engine: innodb
[error] aborting
150703 23:44:27 innodb: could not open or create data files.部門沒有dba,處理資料庫不能啟動的問題找不到直接可以諮詢的人，上級給了個其他部門的dba**諮詢，遠水解不了近渴，**裡大致聊了下也說不清楚，沒有時間耗在恢復這個資料庫上了。150703 23:44:27 innodb: if you tried to add new data files, and >it failed here,
150703 23:44:27 innodb: you should now edit >innodb_data_file_path in my.cnf back
150703 23:44:27 innodb: to what it was, and remove the new >ibdata files innodb created
150703 23:44:27 innodb: in this failed attempt. innodb only >wrote those files full of
150703 23:44:27 innodb: zeros, but did not yet use them in any >way. but be careful: do not
150703 23:44:27 innodb: remove old data files which contain your >precious data!
150703 23:44:27 [error] plugin 『innodb』 init function returned >error.
150703 23:44:27 [error] plugin 『innodb』 registration as a >storage engine failed.
150703 23:44:27 [note] plugin 『feedback』 is disabled.
150703 23:44:27 [error] unknown/unsupported storage engine: >innodb
150703 23:44:27 [error] aborting
此時經過商量決定重新初始化乙個資料庫虛機，急忙dump了乙個原測試線上環境時的老資料庫到新的資料庫上，重新發布應用切換到新資料庫上，讓使用者先能進行遊戲再說。
9：55pm 資料庫虛機初始化完成，應用重新上線，幾個開發稍微松了口氣。
10:00pm-1:20am 此時大腦已經比較遲鈍了，嘗試恢復老資料庫一次失敗後放棄。跟同事reivew這次問題，通過監控資料發現晚7點資料庫突然連線數暴漲，同時cpu負載飆公升，但應用伺服器並沒有流量暴漲的異常問題，如果應用邏輯沒問題，就暫時只能懷疑是連線池問題（用的是druid）。當時的負載監控如下圖：
週末休息後，周一過來稍微搗鼓了下老資料庫就啟動了，看來還是不能疲勞作戰。啟動後將需要同步的表資料匯入線上庫，至此事情基本告一段落。
此次遇到突發情況比較多，各種小問題累積在一起壓斷了最後一根稻草。按照scrum的review規則記錄一下經驗，總結教訓。
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
記一次線上快取問題
今天上線專案時，檢視乙個軟體列表，我的介面裡是findall,可是軟體列表裡沒有type欄位沒有出現，後來檢查發現 是線下softmodel裡type欄位沒更新過來，清完線下表快取，並用gii重新生成了下softmodel，然後再次上線。再次檢視線上該軟體列表，還是沒有type欄位，估計第一次檢視的...
記一次線上OOM問題
首先是 jmap dump format b,file file.hprof 匯入mat工具 定位的問題是 standardmanager和standardsession檢視原始碼發現concurrenthashmap node就是standardmanager的session屬性 protecte...