一、案例

某天，突然收到監考報警，內容“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天）的歷史資料進行分析）。