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天）的历史数据进行分析）。