项目名称： 自作多情郎？狼？浪。。。。
客户名称：NAN
故障处理人：NAN
故障开始时间：2017/10/23
故障恢复时间：2017/12/2
CPU持续升高，机器负载从1增加到300，负荷量增加300%，未知的程序在占用CPU时间，程序性能没有任何提升，并发量未增加，流量未增加。
虽然未引起业务中断，运行状态异常持续时间3456000秒。
2.故障排除步骤
2017/。。/。。，采购硬件资源，厂商列出了性能参数，但是没有看到真正的参数列表。
2017/。。/。。，机器上架，试运行三天，调试过程中，没有进行压力测试，性能测试，功能测试，直接上生产环境运行。
2017/。。/。。，上生产程序，调试两周，直接进行业务的调配。
2017/。。/。。，开始正式运维。
2017/。。/。。，CPU持续升高，CPU负载达到100%。
2017/。。/。。，CPU持续升高，巡检发现，CPU负载达到300%。
2017/。。/。。，CPU采取降级方案，减少执行的任务流，但是CPU的负载并没有符合预期的下降。
2017/。。/。。，降级方案造成脑裂，CPU运行在伪状态，内存未释放，负载降低为200%。
2017/。。/。。，再次降级，核心CPU运行在不稳定状态，负载降低未130%，硬件资源调配不均匀。
1、 客户端请求服务端超时
客户端请求服务端的时候，通过远程调用服务调用远程API接口，在经过层层转发请求的时候，数据包偶尔丢失，从而造成服务端不能正确的接收数据，导致请求超时。
优化客户端的请求调用后，客户端再次向服务端请求调用，服务端响应之后，给出的响应数据包中，存在大量的垃圾数据，客户端无法进行筛选，造成客户端不能得到及时的响应。
2、 客户端与服务端不同步
在服务端存在双主模型，从而客户端在向服务端调用的时候，不能及时的探测到心跳信息，服务端以为客户端的态度有问题，拒绝响应，返回响应码404.
服务端虚拟化计算资源和存储资源，分配资源不均匀，服务端以为客户端流量不大，未给与足够的计算资源，计算能力不足。
3、 客户端资源争用
客户端使用的单进程多线程模型，在使用多线程的时候，由于使用的是共同的资源，从而造成资源的争用，偶尔还造成死锁，dead lock。。。
多线程开启过多，从而造成线程之间未进行安全隔离，从而造成内存泄漏，偶尔有OOM的情况产生。
4、 线程有bug，导致主进程假死
在线程执行任务的时候，主进程进行统一调配，而线程权限过大，导致主进程在回收资源的时候，无法回收，触发未知BUG，造成主进程假死。
5、 主进程连接数过多
在客户端发送请求的时候，主进程连接数过多，其中存在阻塞的任务，而主进程分配的time slice过少，从而到主进程一直阻塞。
6、 主备模式不能正确failover
当主进程重启的时候，slave进程不能及时探测到主进程的心跳信息，不能自动切换到master模式，备用进程未进行测试，硬件性能不足以处理大量并发连接。
1、 主动进行主备切换，将slave进程切换到master模式，进行压力测试，性能测试，功能测试，以便于随时进行主备模式切换。
2、 优化服务端，加入更多的计算资源和存储资源，以便于处理更多的并发请求。
3、 修改客户端的线程权重，进行安全隔离。
5、 故障总结
作为运维，拒绝一切变更，想变更？你求我呀。。。。哈哈
这首歌真的很不错哦。。。。
最美的不是下雨天，是曾与你躲过雨的屋檐