2018-08-27 KK日記，組件服務下架注意事項

一、案例

某天，突然收到監考報警，內容“XXXXX短信發送失敗”，原因是我們關閉了ESB服務器1和2，短息系統是直連着兩臺服務器的，結果短信發送失敗，後來恢復這兩臺服務器的服務就恢復正常了。

二、問題

如何避免組件服務在下架時造成應用異常或故障？

三、數據收集和分析

• 缺少正確的流程指引。
• 缺少技術指引。
• 缺少培訓宣導。

四、優化行動

4.1 制定組件服務下架制度

• 確定下架範圍，列出下架的服務器組件，IP
• 確定受影響服務，可通過4.2獲取外部IP來判斷受影響業務。
• 制定受影響服務的善後處理方案，如：遷移，關閉。
• 確認下架組件已經沒有外部連接，方法看4.2
• 關閉組件。
• 7-30天沒有反饋後，清理數據。
  • 如系統關閉的DB數據清理方案，需要用戶簽字確認。
  • 如系統遷移的DB數據清理，則無需用戶簽字確認。

我認爲一個良好的數據清理方案應該包括：1. 數據清理的原因。（生命週期結束、數據冗餘大於2等等）2. 數據清理的方法，參考4.3，（先邏輯刪除，觀察7-35天后，物理刪除或轉移到低成本存儲上） 3. 數據校驗，（確認數據已被清除）。

• 釋放資源。

4.2 確認組件的外部連接

• db類
  • Oracle：查詢 gv$session,gv$active_session_history
  • mysql: 查詢processlist
• 非DB類
  • netstat -an | awk '{if(NR>3) print $5}' | grep -E '^[1-9]'
  • python 代碼

#! /bin/env python 
import os
output=os.popen('''netstat -an | awk '{if(NR>3) print $5}' | grep -E '^[1-9]' ''')
result=output.read()
ip_group=result.split()
ip_new=[]
for ip in ip_group:
    ip=ip.split(':')
    ip_new.append(ip[0])
for i in  list(set(ip_new)):
    print i

4.3 數據清理技術

• oracle

  • 表空間離線：alter tablespace tbs1 offline;
  • 表空間刪除：

  select distinct tablespace_name from dba_segments where owner='user1'# 確認你要刪除標的用戶數據存放點。
  select distinct owner from dba_segments where tablepsace_name='TBS1' # 確認該表空間下存的都是標的數據。
  select * from gv$session where schemaname='username'
  drop user username cascade;
  drop tablespace tbs1 including contents and datafiles;
  

  • 數據庫刪除： dbca --> drop database

• mysql

  • 數據檢查：select * from information_schema.tables where TABLE_SCHEMA='dbname';
  • 數據使用檢查：select * from information_schema.PROCESSLIST where db='dbname';
  • 數據庫刪除： drop database db1; # 常用於實例不關閉，只是關閉其中一個數據庫情況下。
  • 數據庫刪除： 關閉實例後，rm -rf ./數據文件目錄 # 常用於實例關閉，所有數據庫清理。

• 其他組件

  • 刪除敏感數據，如代碼、用戶數據：

    find -name XXX.YY 
    ls -l XXX.YY   
    rm -rf XXX.YY
    

五、結論

• 在下架組件時一定要確認當前組件是否還有系統或組件調用，如有則不能下架。
• 確認組件的外部連接的方法只對長連接有效，短連接是無效的（像C/S架構的可能會檢查不出來，那我們只能通過crontab反覆調用收集一段時間（建議3-7天）的歷史數據進行分析）。