通过双11暴露出的我们的哪些问题-阶段性总结

今年的双11我们过的不可谓不丰富，有前奏，有高潮，大家应该都有切身感受，趁着双11的热度^_^，思考了几个下面的问题，大家一起看看。

暴露出的问题：

1、  在代码review的过程中，我们对如何写一段好的的代码，找不到感觉，比如，对方法的控制上，如何做到小方法解决一个功能，粒度控制的不好。

想对某一个单一的功能增加ump监控，往往却包含了A、B、C功能。

2、  外部资源JSF等，这些资源的ump监控，还是有遗漏的，仍然需要进一步排查，做到外部调用必有监控。

3、  日志异常打印信息不丰富，只输出了异常栈，当然比没有强的多了，但还是不够，我们需要把入参打印出来，让前后文信息丰富起来，才能更快的定位问题。

4、  Jvm的报警我们么有添加全面，比如gc次数报警。

5、  Ump的报警我们没有添加全面，比如方法调用次数监控。

6、  对可降级的点，我们梳理的，只能说，仍然不够到位。我们要的场景是这样，既然是应对措施，那么将来发生的问题，在我们的应对措施里面如果碰到，我们直接点击出去，降级就好了。达到一种这样的效果。

7、  大家对问题的敏感度，求知欲不强，比如10月22日这天，京麦有史以来的一次大面积故障。我们当天及凌晨解决以后，除了缪宇，文欣他们参与其中的知道解决的方法及思路，事后只有振发一个来主动问，是怎么解决，让我叫他使用那些工具。

其实，想想，我们也对那些工具做了一次培训，培训后又有谁主动去亲自拿工具试一试了呢。

8、  我们在架构升级和需求之间徘徊不定，像咱们的部署结构，及拆解方案，我们也都在事发之前，甚至之前的之前有碰过，但需求永远是做不完的，每个人站在自己的立场考虑问题，也是正常的。但是咱们技术人员肯定要知道

自己的真实情况，其实真有了必要改造系统的感觉的时候，可以每次改造，比如10%这样的进度往前走。

9、  对线上问题处理的思路和方法，还是要持续锻炼，像ump它不仅仅是简单的一个让你看看tp99就好了，里面的对比查看，按机器维度查看，高级搜索条件使用，如何结合cap系统等，这些光靠培训只是让你知道而已，甚至培训的过程中

知道的还不是那么贴切，还是需要大家积极的参与到值班，实际解决问题中，进行实际的操作锻炼。

10、             我们对单元测试不足，发布测试之前，有两个环节最重要，自己单元测试，一起review代码。单元测试是第一步，这个过程，能发现基本的功能上的问题，如果需要压力测试，甚至还可以发现性能方面的问题。

11、             京麦和无线两边技术上需要同步

12、             勇于学习别的组的先进解决方案

以上问题不到位的地方希望大家跟我一起去解决。谢谢！

 

 

初步的解决方法：

代码review基本标准

一、一个方法只干一件事

二、方法添加ump监控（检查ump系统中是否添加，ump的报警参数设置检查）

三、外部依赖必须有ump监控，检查同二

四、异常里面必须要有异常打印，打印时需要把入参，输出

五、Slq语句，要有超时时间设置

六、Jsf要有超时时间设置

 

 

单元测试

推荐使用spring-test框架，详见附件。（后面我再弄一个web单元测试的方法，通过spring-test框架），如果你认为单元测试部重要，代码里面居然一个单元测试都没有，那么好好思考下。