九台nosql同时宕机故障

一、故障现象

3月16号22:20分左右，手机收到现网主机的宕机拨测短信告警。收到宕机短信本属正常，现网业务有二千多台 server 难保其中哪台不出问题。可是还未能赶着打开电脑，紧接着同一时间又是8台主机的宕机短信。未查看工程文档核对主机之前，猜测怀疑是某一刀框出了问题，导致同一机框内的所有刀片不能服务。不过等查看过第一台以后，发现是pc server ，另外8台和第一台是同一业务下的另外几个节点。

二、处理过程

1、先是登录其他主机，ping 该主机的业务网口，发现是通的。松了一口气，以为是误告警。不过ssh 进行跳转时，报没有权限。连试三台都这样。

2、通过ILO4 远程管理口查看，并使用用户名密码登录，发现如下报错：User not known to the underlying authentication module

网上查询了下，该报错一般是由于/etc/passwd和/etc/shadow 内容不同步导致，需要通过pwconv进行同步。不过对网上的这个结果感到怀疑，不可能同时9台都出这问题啊。由于当晚业务侧有升级操作，这时候也由同事协调问业务侧是不是做了什么操作。同时问下负责自动化相关人员是否有什么操作。（此时已经怀疑人为的可能性比较大，后来得的结果是没有人进行操作。）

3、和相关人员沟通完想法后，先将其中一同进入到单用户下进行pwconv 文件同步。重启主机时，又报别一个错：libselinux.so.1: cannot open shared object file: Permission denied

4、由于SUSE下没有selinux，对这个摄氏感觉很奇怪，不过还是重新进入单用户，find到了libselinux.so.1文件，并和正常系统下的该文件进行权限比对。发现并无不同，同时又查看了各主用户的家目录下的环境变量文件、/etc/profile、bashrc文件、家目录的权限等。都未发现异常。同时又尝试新建了一个test并启，再次重启，发现还是停留在步骤3中的界面。通过其他主机ssh test用户，报错内容同步骤1的报错。

5、以上操作已经过去了1个多小时（此九台主机相当核心），此时手机一边电话会议，另一个手机已经被各路领导打爆。其中一些指令执行时已经没时间查看结果，只能不停的向各路领导汇报同样的结果。－－－ 该时间段有人提到过查看history 记录，执行未细看就又开始接电话。未细看的原因也因为对此未报希望，平时有相关厂家会进行使用工具定期扫描、加固、抓取数据等操作，认为很可能history记录已被覆盖。

6、拉上了SUSE原厂人员，并简单报了下情况。另一同事到达机房现场同业务侧相关人员在对另外一台主机操作是，有了新进展，在执行chmod 777 / 后，主机启动成功－－－－ ，好暴力的感觉 。将该情况也反馈给了SUSE 二线人员 。此时二线人员进入单用户后，进入根目录，立即发现了一个问题，lib、lib64、etc等目录都变成了600权限－－－－－好犀利，之前怎么就没想到先看看根目录呢？

问题主机的根目录：

正常主机的根目录：

7、修改完成后，重启主机，进入系统正常。

三、根因定位

1、histroy记录

查看在故障发生时间点之前有进行过大量chmod 600 操作，这点和单用户查看到很多目录是600权限对应。以下为部分截图：

2、last记录

经查看ts_user用户（从10.211.94.198登录）的用户从21:11登录到主机发生crash时一直登录在主机上

3、message日志

message日志里在故障发生前，也发现有ts_user用户在22:14:16有su切到root的操作（而且使用的也是/dev/pts/6）

通过查看9台主机的操作记录，都存在相同的histroy记录、ts_user用户登录和su操作（故障发生时间点之前几分钟内）。

4、在9台主机上也通过echo $变量名 ，发现history记录中的部分变量是不存在的。导致前面一部分被解析成空，例如如下：

1[root@361way ~]# ls $ABC/
2bin  boot  data  data1  dev  download  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  sbin  selinux  srv  sys  tmp  usr  var

在我的测试机中不存在变量$ABC ，所以$ABC被解析为空，这里执行ls $ABC/ 的结果相当于执行成了 ls / ，同样，上面的chmod操作中，不存在的变量执行后的结果可想而知。

四、经验教训

1、通过相关日志定位和IP地址定位到了业务侧误操作的人员。所以第一教训是：诚实，做了误操作要勇于承认，如果当初把情况描述清楚，问题会提早很多完成修复。带来的损失也是最小的。

2、遇到问题要学会寻找帮助。目前的环境所能寻求的资源相当多，由于之前在”小作坊” 似的企业做惯了思维定式的运维，未能及时想到寻求帮助。这里也很感谢公司领导最后给提供的资源。

3、戒骄戒躁，注意最普通的地方。同时N个领导来问情况，大的压力下可能会打乱正常的思维方式，这里有两次可以发现问题的机会，一次没抓住，一次没想到。如果最早细看histroy记录，肯定能发现问题，和权限和环境相关的地方都考虑到了，根目录忽略了。

4、暴力方法有时可取，chmod 777 /解决了一部分问题，后面启动后部分文件无权限时，被现场的兄弟来了个更暴力的操作－－－直接加-R递归了所有文件的权限。虽然看起来不专业，不过临时可以将业务恢复。后面无非麻烦的就是要重装过。但相对损失也是小的。无非平常不做这一部是存在安全隐患，不过重装后，隐患也就不存在了。