7月投產問題及應對方案
投產過程常常受到重視。投產時間緊迫不應該也不允許產生錯誤。如果產生故障就會受到各方的巨大壓力。這種情況下必須重視因低級錯誤或疏忽導致的生產故障。
問題列表及分析
情況彙總
1，投產過程受到雲平臺不穩定、設置參數不明確等因素影響，而拖延了投產時間、甚至中斷，內存溢出並且保錯等。
2，由於負責數據處理的同事的疏忽，沒有進行生產主鍵的邏輯進行校驗，導致Es的ID沒有按原來的約定生成。在腳本跑了很久時發現，導致第一次修數失敗，所有數據被廢棄。
3，因負責標準化映射規則的同事沒有及時更新映射規則，導致批量同步的數據轉換出錯。由於標準化規則沒按T-1的規律下發，導致程序無法讀取到T-1文件夾。直接導致程序報錯。
4，因第三方網絡不通，導致外發報錯，批量外發報錯。這個原因耽擱了3天。
5，ES其中一個節點實例假死，導致ES查詢超時。
6，mysql因binlog而導致主從集羣失效
應對方案
1， 微服務基礎應用部署於虛擬機。因爲雲平臺不穩定，把微服務基礎部件遷出雲平臺和docker，在虛擬機上部署。基礎應用有API-Gateway，註冊中心、配置服務。
2， 開發、測試環境與生產環境儘可能保持一致。在開發環境上建設與生產環境一致的數據庫集羣以及數據下發機制。其中一個是mysql主從同步集羣，另一個是標準化表和有效期值的下發方式和週期。這次的投產就是因爲標準化表沒有同步進入redis和有效期表T-1的更新方式導致數據不對，而導致修數。
3， 進行完善檢查與測試。具體而言，首先針對各個依賴環境做檢查，例如標準化數據是否已經進入了redis，有效期值是否已經下發，是否按約定的T-1下發。例如與第三方接口的網聯鏈路是否已經接通。儘量做到無死角。
設計之初就應該全面思考測試場景。功能測試、邊界測試、壓力測試都編寫用例並執行。
4， 維護依賴檢查列表。對外部數據應用的整個鏈路抽象出一張依賴圖。針對各個依賴環節所需要的技術檢查點，逐一說明和記錄。用於生產過程逐一檢查。以往雖然做了技術檢查，但因爲沒有列表和架構圖，會有漏掉的情況。以後在開發過程中對架構的修正，如果存在依賴的地方，都維護到架構圖和技術檢查點列表中。
5， 維護問題解決方法列表。由於經常性、突發性地發生故障，開發者需要去生產環境差錯，導致開發者情緒不穩，同時也延誤開發的本職工作。如果能有專人專職，根據問題解決方法列表去查錯，會更大限度的提高協調效率。
6， 爲技術選型提供更高的自由度，爲非業務功能提供更多時間，不斷改進架構。例如，如果覺得ES在某些方面不合適，在已經合理科學的論證過，是否可以選擇其他的數據存儲。
檢查點列表
犯錯誤不可怕，但如果犯的是低級錯誤，難道不覺得惋惜嗎？
1，檢查徵信系統已經下發了有效期表。
2，檢查有效期的值是正確維護的。曾因有效期值錯誤而使存儲的數據有效期錯誤，變成髒數據。直接導致對ES修數。
3，檢查標準化映射是最新規則。曾因爲標準化規則變化但沒有維護，導致存儲的數據標準化操作錯誤。直接導致對ES修數。
4，檢查標準化規則是否同步到redis。曾因爲標準化映射沒有同步到redis，導致存儲的數據未進行標準化操作。直接導致對ES修數。
5，檢查行內網聯鏈路是否聯通。
6，檢查行外網聯鏈路是否聯通。因爲第三方鏈路不通，導致整個鏈路查詢異常，直接引起整個流程都報錯。
7，檢查雲平臺是否一直穩定運行。
8，檢查卡夫卡是否正常運作。
9，檢查mysql。曾因主從同步集羣刪除了一大批歷史數據，而導致binlog一直在讀寫，導致IO線程和sql線程滿負荷，從而主從失效。
10，檢查ES實例節點的健康度。曾因ES某一個實力假死，導致查詢一直報錯：ES查詢超時。