一次apt-get update引起的风波

   最近领导让研究nagios，作为一名小白，以前从来没有接触过nagios，也是云里雾里的就开搞，终于，三天研究下来，基本监控项可以配置，等着部署客户端监控其他服务器了，但是服务器也有好几十台，一个个部署，有点太愚昧，所以，利用ansible批量执行本地脚本，自己在本地写完编译脚本，开始推送公钥，一切准备就绪，执行命令ansible all -m script 'shell.sh',结果。。。。悲剧了，邮箱开始炸了。
   接二连三的apache服务down掉了，mysql服务down掉了，立刻终止批量执行命令，查看报警服务器，发现mysql已经由原来的5.5.34更新为5.5.54，不过还好，没有造成什么损失，产品没有报障，但是，有一台服务器，mysql没有起来，登上去手动启动，提示start job failed，这是为什么，查看error.log，里面并没有任何的日志信息，空文件，百度说是因为socket文件丢失，但别忘了，mysql不启动，socket文件肯定没有，接着查看各个文件权限，运行用户都是mysql，权限正常。
   查找了大概半个小时，还是没有确定原因，决定替换一下配置文件试试，找了一台启动正常的mysql服务器，down下来他的配置文件，使用rz上传配置文件到有问题这台，但没有装这个命令，然后执行apt-get install lrzsz安装,执行过程中，奇迹发生了，显示mysql有一部分并没有更新完成，在装rz的过程中自动修复了未完成的一部分，查看mysql状态，启动正常了，误打误撞解决了无法启动问题。（出问题的这台服务器上面的数据库没有业务使用，调用的redis，所以并没有影响业务）
    所以，这也是低级错误，也是自身技术欠缺，分享出来，希望大家在生产环境中，慎用apt-get update ，apt-get upgrade，yum update这些命令，同时批量执行脚本时，先在本地测试一下，然后找台线上的测试一下，确定没有问题，再批量执行，否则，一旦出问题，真的很难快速解决。
   最后，希望各位大神看完别喷，因为我毕竟是小白一名，只是希望后面跟我一样的小白别犯这样的错误。