三天小假稍作调整，停下来思考下曾经的一次优化经历，结果上是好的，过程也是曲折的，在稍微大点的公司，一切都是需要靠证据说话的，下面直落正题——
一、背景：
由于项目的票量上涨，客户来电量的增加，尤其是天气不好的时候，航变外呼的急剧膨胀，目前的后台处理系统在经历了3年的风风雨雨之后越来越重，服务中心的MM们隔三岔五的反馈后台系统在业务高峰期出现频繁的卡顿和不可用。
二、后台系统卡，博主经过沟通和分析，觉得主要是这么几个方面：
问题来了
1.代码问题，该异步的没有异步，同步调用导致页面整体加载时间长
2.由于功能太多，页面有没有一千也有八百，代码内部出现没有侦测到的死循环导致服务器CPU飙高，内存爆炸
3.网络问题，服务中心由于人数众多，没有在公司的总部大楼而是放在房租较便宜的地方，而服务中心的目前投入不是很大，网络带宽上存在一定问题
三、拿到问题的思考：
针对第一个问题，从程序员的角度看，还是比较大的嫌疑的，但是后台大部分功能都是报表类的处理页面，实际上异步没什么太大必要，对页面加载本身没有实际的提升，有一点嫌疑。
针对第二个问题，博主跟进多次之后，发现实际上在服务中心卡的时候，实际上同期的CPU和内存并没有发生什么异常，这个铁证如山可以排除。
针对第三个问题，博主去服务中心实地体验过，确实在发生卡顿和不可用时总部这边并没有什么异常，因为运营商务的也需要使用这个后台系统，他们实际并没有受到影响。嫌疑很大。
四、问题的处理方法：
从嫌疑最大的入手，联系了运维大爷表示了一下想要他们实地去看下我们服务中心的网络是否存在问题。然而运维大爷口头答应，实际上并没有一个实际行动，当时博主有点不开心了，但是没办法，我又管不到他们，用这种请求的方式去要求他们协助，实际上就是拖拖拖。
在人员架构十分冗长的公司，需要推动一件事，那就需要证据和意义，然后叫上需要配合的对方领导，让他们来决定需不需要去完成这件事。
那第一步，我需要的是证据。
着手搭建一个监控系统，这个监控系统需要帮我完成这么几件事，
1.能够追踪到每一次请求的请求时间耗时和请求的来源
2.需要在总部和服务中心之间的网络有一个对比
3.请求的耗时需要是发起请求到接收到响应流的这段耗时
4.需要将每次请求的客户端响应耗时和服务器端的响应耗时进行匹配形成对比
五、开工干活：
1.这个监控系统的数据埋点如何收集：
答：设计了一个windows服务小程序，安装在需要收集数据的相关机器上，这个服务每次开机自动开起，每隔100秒模拟一次页面请求（请求的页面从客服反馈出来的常用页面中甄选出来五个），从发起请求的时候开始计时到接收到整体的响应流之后结束，将耗时记录下来。
由于需要每一次客户端和服务器端的响应需要匹配起来而且需要区分请求来源于服务中心还是总部的机器，因此发起请求的时候会将请求的时间和一个唯一标识以及区分服务中心和总部的标识通过get方式带到服务器端。
请求结束之后，服务器端会将唯一标识，加载时间和区分标识保存到redis服务器上，最终落地到数据库中。windows服务在请求完成之后会将客户端收集到的数据通过接口记录到redis中，最终落地到数据库中。
2.数据拿到之后如何实时进行监控到：
答：收集到数据之后的数据展示，博主这边采用了比较能够清晰呈现的Highcharts JS图表库。
Highcharts个人使用下来的感觉就是很方便，数据绑定的多样化和报表呈现的多种格式，博主只能用实用这两个字来形容。
最重要的是各种数据源之间的对比用起来非常的直观，四个字，高下立判。
六、后记：
监控系统搭建完毕之后，一切都变得如此清晰，下面的优化方案就很清晰了，在业务高峰期的服务中心报表所呈现出来的加载耗时只能用惨来形容，客户端请求基本都在4s左右得到反馈，而服务器端的耗时基本稳定在1s内，同期对比，总部这边的客户端加载时长在2秒左右，服务器端的耗时在1秒内。
邮件向领导们汇报下当前的现状和优化的方案，得到认同之后，运维大哥很快的实施了起来，很快负载加上了，网络也进行了调整。
七、感悟：
1.看似难以推动的问题，找到痛点，就能一击致命。
2.控制变量法，永远都是面对问题最稳健最让人信服的方法。
3.幻想无数不如动次真格，事情只要去做了，实际上会没那么难