前幾天生產環境上線，程序不算順利，總結下原因大概有這么幾點：
- 前期準備作業不足，依賴的中間件軟體安裝后未經過充分驗證，例如mongodb；
- 臨時改配置，sit和預生產的中間件單機，生產使用集群，集群環境的使用未得到充分驗證；
- 不可抗因素，踩到了springboot版本的bug，
以下是部分可記錄供后續參考的問題和解決方案：
mysql-sqlmode問題
這個問題實際不是生產的問題，是之前預生產出現的，之前沒有記錄，這里一并記了，
部署預生產后，資料庫分頁操作報錯，這個問題遇到很多次了，只是運維同事搭建資料庫時沒有提前處理，
錯誤如下：
ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'information_schema.PROFILING.SEQ' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
解決方式不算復雜，修改sql_mode即可，可參考如下博客：
https://www.cnblogs.com/kenshinobiy/p/9580701.html
redis value must not be null問題
生產環境部署時，使用redis的服務一直在重啟，而日志卻沒有任何例外，
開始懷疑是健康檢查有問題，使用http://ip:port/actuator/health發現確實結果是down，而不是up，但是由于日志沒有例外，難以查看更多資訊，
為了進一步查找問題，springboot增加如下配置，使得健康檢查回傳資訊更多一些：
management:
endpoint:
health:
show-details: always
有了上述配置之后，果然找到了問題，訪問健康檢查url后，發現是redis連接的健康經檢查失敗了，
詭異是，程式啟動時成功的，對redis的操作都正常，只是啟動成功過不了多久就持續重啟，
再考慮到dev、sit、preprod環境都是正常的，問題點倒是縮小了，這三個環境都是單機的redis，而生產用了redis集群，
但是專案是支持集群模式的，代碼和配置本身應該也沒問題，否則也不可能正常操作redis，
最終，發現是springboot2.3.1版本有bug，這里邊對redis集群的健康檢查有問題，會導致redis集群模式下的健康檢查失敗，
https://github.com/spring-projects/spring-boot/issues/21514
找到了原因，解決方案就相對簡單，而且不止一種選擇，可以直接關閉健康檢查，顯然這不符合生產環境的要求，
也可以只關閉redis的健康檢查，看起來好一點，但是如果redis真出了問題卻也會導致健康檢查檢查不出來，
于是我們選擇了第三種，即升級springboot的版本到解決了上述bug的版本，目前升級到了2.3.4，
第三種應該是目前較優方案，只看后續的全面回歸測驗是否有影響，
gitlab的坑
這是一個說嚴重很嚴重，說不嚴重好像也不嚴重的問題，gitlab的web界面進行合并操作時，默認會勾選洗掉源分支選項，
在生產代碼發布時，突然發現合并后原來的分支不見了，于是仔細檢查了下之前的操作，便發現了上邊的坑，
雖然重新push一下就沒事了，但是洗掉本身就是個很敏感的操作，再次提醒做事需仔細，上線當小心，
CSDN認證博客專家
web安全
系統安全
安全架構
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/191291.html
標籤：其他
上一篇：網路安全第六講 入侵檢測系統