时间日期项目背景
某日下午六点多，业务中断，服务器无法连接，联系服务器托管方重启机器，但半个多小时后被告知系统故障，重启失败。然后就一直在催他们处理，确保数据不丢失的前提下尽快恢复机器。但是效率极低，沟通也非常困难，对接的市场和售后工程师刚开始都不给现在工程师的联系方式，导致目标不一致，浪费了很多时间。
宕机3个多小时，10点左右他们才给出方案，用新硬盘装新系统，将老硬盘作为数据盘挂载上去。结果装机又花了2个多小时，恢复链接时已经12点了，整整宕机接近6个小时。由于我们业务已经正式上线，导致损失巨量流量，造成了极大损失。
恢复业务
服务器恢复后，接下来恢复业务，主要要重新安装业务环境，从挂载的老硬盘中，将mysql数据库恢复。
遇到和解决的问题
- linux安装多个硬盘后，如何挂载，如何将B硬盘数据拷贝进A硬盘
Linux查看与挂载新磁盘 - mysql 启动问题，启动报mysql.pluge的错误
Linux下MySQL报错:Can't open the mysql.plugin table - mysql 数据恢复
进入旧磁盘mysql的数据存放路径，yum默认安装的话在/xxx/var/lib/mysql/,将要恢复的表的文件夹拷贝到当前系统下/var/lib/mysql，确保mysql有读写权限，重启mysql服务 - php-fpm遇到的奇怪权限问题，以service php-fpm start 启动后无论如何都没读写权限(apache用户的权限已分配)，并且无法连接到数据库，直接以php-fpm启动就可以，ps -ef查看进程所属用户，两种都是Apache。在其他机器中，service和直接启动就都没问题。主要不以service启动的话，要重启或杀死php-fpm就比较麻烦，一共有120多个进程，批量杀死可以用此命令:
ps -ef | grep php-fpm | grep -v grep | cut -c 9-15 | xargs kill -s 9 ;
总结
恢复系统后，查看了老系统盘里的系统日志/var/log/messages,发现了cpu过热的告警，当时cpu消耗大致在60%左右，那台机器的cpu过热温度是84，机房是风冷散热，所以确实可能是这个原因导致的宕机，系统崩溃无法重启的问题，就不好确定了，服务器商的工程师上去定位后也怀疑是自己的机器有硬件问题。
至于cpu消耗如此大，温度过高的原因，除了我们业务本身就需要处理大量请求，nginx负载严重外，后面通过分析接入日志，发现也存在大量不合法的高频攻击性请求，导致负荷超过实际。我们当前是8核16g，估计后面得升cpu数了。另外还发现，那台机器的nginx负荷非常不均匀，8个nginx进程，有的60%的负荷，有的只有20%，这个跟系统
之后紧急开发了读取接入日志，分析高频非法请求，利用iptable+ipset批量拉黑ip的程序，每30s处理一次，才降低了一些nginx负荷，目前每天能拉黑3w个左右的疑似有问题ip。用sensor监控系统温度，目前的周末晚高峰峰值在75度以内，还算健康。
