一次运维经历

背景简述

 那是2020年的第一个月。疫情还没有开始。
 那时候我们公司正要上线新的ERP（SAP），作为SAP外围系统的WMS（仓储管理系统）也要上线（同时上线的有8个系统！）。对于WMS应用的连续性要求非常高，因此领导对于此次上线也非常重视。然而WMS项目组只有三个月的时间从前期调研到蓝图设计到实施到测试等等。三个月时间不是一般的紧张。上一个WMS做的时候，我也在，整个项目做了半年。一下子把时间打对折确实让人手足无措，倍感压力，同时在时间上也非常紧迫。

起因

 正值全线测试的阶段，13号下午三点。有人反映服务器登不上了。
 项目经理急忙给我打电话，让我去处理问题，同时微信群里像炸了一样，全部是at我的消息。就不截图了。大家肯定都感受过。IT部领导也疯狂打电话（据他说打了好几次都忙线），包括SAP项目组，OA项目组，电子签章项目组，金税，关务，MDM等等，大家全都晾着，等WMS恢复，当然，同时各个项目组的领导也在疯狂给我打电话。
 这马上都要上线了，这么重要的测试阶段，出现了这种问题，我瞬间感觉压力山大，但又不失为表现自己的一个机会。

经过

 当时我们IT还没有做虚拟化集群，所以就赶紧赶往两公里外的机房（我们公司生产制造中心和研发职能中心不在一块）。
 在路上我已经在整理思路了（虽然在不停地接电话），先检查数据库，再检查应用，两个都没问题先“重启大法”保命。当时我能想到的就这么多了。
 可是到了现场，远远没有我想象得那么简单。
 因为当时测试系统，所以安装了GNOME桌面环境。在机房连接了外设之后，鼠标动不了，键盘也操作不了，卡在登录界面什么都没办法操作。完了，思路全被打乱了。
 直接关机的话，Oracle可能会起不来（原因不赘述），恢复Oracle又是一大问题。不直接重启的话，现在也没有别的招，远程shell也链接不上。
 索性食指一伸，关掉了服务器。
 完犊子。谁他妈能想到服务器起不来呀？！
 当时情况如图…

 完了，准备简历吧！
 开玩笑的。

解决

 当时就一个思路看日志。赶紧救援进入，看下系统日志，这明显是系统有问题。但是…系统日志里什么都没有，有的日志都是类似“command not found”这种报错。
 command not found?
 按照图片上的报错是没有找到bin/sh。
 结合command not found，隐约感觉是某个系统目录出了问题。cd到根一看，果然，/lib64目录不见了。
 赶紧scp从内网的其他同样的机器上拷过来一份。然后重启。
  Finished！Successfully！

结语

  做完这么多，其实已经到晚上七点了。虽然解决起来简单，进入救援模式然后SCP，但是你会发现很多时候耽误你的不是你的解决方法，而是解决问题的思路。思路清晰了，就少了很多不必要的步骤，不会在事故中抓瞎。走一步看一步这样的情况很可能会导致更多的问题。
  第一点说的是解决问题要有思路。第二点，不要慌。做运维最重要的就是心理承受能力要强。在这次运维过程中（基本所有的运维都是一样的），除了理出解决思路耗时较长，另外一个比它耗时还长的就是跟各个部门领导通话。我看了当时的通话记录，大概有一个多小时都是在跟各个领导打电话，不仅是出问题的当时，在处理问题过程中，各部门领导不停地催促不停地问进展，在群里发了进展也没用，就是要打电话才放心。
  最后，著作这篇文章的时候，思路很清晰，当时多重环境压力下，我觉得4个小时解决已经是非常不错的了。
  当然，最后的最后，问题出在了一个实施人员，当时用命令行误删了/lib64，后来由于项目紧也没多问，就此作罢。