今天上班看到备份机的负载高得惊人，达到了几百倍的负载，然后就开始排查问题，因为前几天大概看了下，我们锁所做的事情还是很有限的，就算动用重启大法也是收效甚微，忙忙碌碌一早上，好像进展也不大，不由得感叹，这种被动的处理问题的方式好像也没有多少技术含量，整体在忙啥。
回到这台可怜的备份机，这台服务器使用了NFS的挂载模式，虽然我对于NFS还是比较感冒，但是为了解决这个问题，还是得硬着头皮和同事看之前总结的各种问题解答攻略，因为负载高得惊人，但是系统层面的IO压力和CPU压力其实并不高。所以能够基本排除是业务服务异常引起的。
但是这个回答不足以让人信服，那就是为什么之前是好好的，突然之间变成了这样，通过这个问题，我有了重新的感悟。
那就是原来所谓的好其实不是真的好，不代表原来就是正确的。而现在的问题触发方式可能就是一个事件，因为某个因素的变化导致问题从量变转变为质变，所以顺着这个思路来重新看待这个问题，其实可以发现很多的改进之处。
我在系统层面查看日志，发现系统日志中开始出现Kernel相关的错误。
XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250)
在和系统部的同事经过了几次沟通之后，觉得还是专业的事情交给专业的人来做，我们就不在系统层面折腾，免得适得其反。
很快时间就过去了，转眼到了下午2点左右，系统那边的同事还没有明显的进展，而这个服务器的负载依旧是很诡异，所以我开始考虑plan B,在昨天我已经提前锁定了一台备份机器，所以也算是刚好赶上了这个节骨眼。
按照运维规范来说，周五是不应该做所谓的变更操作的，但是不变更就意味着完全忽视已有的问题，从潜在问题变为明显问题，到变为故障，这只是时间问题，所以必须要改，而且还需要尽快。
整个整改的计划从开始讨论到开始实施，也是做了分工和协作，基本能够让每个人都可以做到自己的角色和位置，很快任务就跑起来了。
也就意味着我们在问题变得严重之前已经开始撤离了原来的服务器，这样能够留出更多的时间和空闲资源供系统同事进行分析和确认，很快他们发现了逻辑卷层设置的问题，这块的改动比较大，需要重启启动服务器而且需要重新配置存储，因为我们很快切换了服务器，所以这个本来很严重的服务影响范围变得不那么紧要了。
很快我们发现这个问题不光影响备份，而且对于已有的监控也会产生潜在影响，比如NFS分区问题会导致df -h的命令被挂起，而监控中会潜在用到这个命令的输出结果，也就意味着监控服务会全部挂起，直到整个服务数据可以滚动。所以这一波修复着实让我们庆幸，避免产生更加奇怪的影响。
值得一提的是，其实还有一台备份服务器，和这台算是难兄难弟，他的负载也非常高，我目测按照这种情况，应该很难撑过今天，所以也是在下班前和同事进行了讨论，对服务做了降级处理。也就意味着，我不用太担心整个周末的质量了，不用大半夜被报警惊醒了。
当然，从解决问题的角度来说，问题的本质原因是类似的，而通过最近的一系列改进，算是对原来的一些旧疾的大改造。
在很多问题没有解决之前，对于我们来说，都是未知问题，问题发展的趋势如何，我们还是需要未雨绸缪，对于问题的评估也需要更加理性，从而解决方案也能够更加容易落地。
小结：当服务器真是不容易，不光要24小时连轴转，而且碰到负载高的时候，我都能想象如果备份机器是个人，应该是一个很憋屈的人吧。
