救火队员的那些事(1)

　　“预防胜于救火”，道理都懂，可是当面临成本、时间等压力时，最易被放弃的就是质量，在HW作过不少次这样的事情，虽然每次压力山大，可是收获颇多。

　　分享的第一个案例是咱们的产品在08年因为中标了印度某运营商， 中标之后，这个项目就由印度的同事交付以及维护，这个项目每月可以给运营商带来几百万美刀的收入，加上项目是合营的，利润仍是不错的。因为印度同事对产品的理解不够深刻，以及产品自己代码质量并不高，因此在08年年末交付之后，网上问题一直不断，可是由于利润还不错，因为印度人本身和本身人打交道，因此质量问题一直没有成为Top 1的问题。

　　可是09年的时候这个项目的甲方的高层领层换了人，换个领导之后就会把这个事情摆上台面，甚至提出这些质量问题若是不解决的话，后续的合同不续签。

　　印度的同事由于对产品接触的时间才一年多，我虽然接触也才2年，可是由于我在国内接触的资料会比他们多一些，加上我在当时的团队里技能稍微好一些，因而领导就把这个“伪专家”给抛出去了。万事开头难，和印度的同事除了语言他们那很是重的口语我常常听不懂之外，还有他们作了近2年的定制开发，不少功能已经和最先的产品已经不同了，怎样在短时间内快速的解决明显的问题，我内心真是没有底，不知道本身能不能完成这个任务。

　　接到任务之后，和他们邮件、电话作了充分沟通之后，了解到他们最突出的问题：网上运行不稳定，以致于他们天天晚上安排一个兄弟把集群里每一个机器挨个重启一遍，这样大部分状况下可以确保能跑一天，可是天天这么重启也不是办法。在和他们商量之后，计划分2步走:

　　一、止血: 先确保不用天天手工的重启

　　二、在实验室环境搭建一样的环境，将主要流程在实验室进行压测，重现问题。

　　第一针止血，他们的要求很简单，就是不要天天半夜起来人工重启。这个要求简单，用perl写了一个watchdog的脚本，这个脚本原理很简单，可是发挥了很重要的做用。由于它不只可以发现服务挂掉，它还能收集大量的信息快照并打包，这样天天把重启的记录进行分析，可以更加准确快速的分析问题。watchdog判断重启有2个条件，一个是cpu的使用率若是持续100%,在判断cpu的使用率的时候，并不能直接用vmstat或者top,而是读取/proc/stat,由于这里能读取到每个cpu的使用率，有时即便一个cpu一直是100%也是有问题的，另外还有一个条件就是判断心跳的页面了。重启前会收集gc、内存、日志、磁盘io等全部可能的信息。这个perl脚本总共应该不超过80行代码，可是后来我在不少地方都用到了。其实咱们的系统也有watchdog的，可是发现这个watchdog有时本身也会被hang住，因此用这个脚本单独的进程更加稳定一些，后面咱们的产品也的按个人这个想法从新设计了watchdog.

　　有了watchdog之后，发现致使重启的不少时候缘由是由于数据库链接不够了，而致使链接不够了，要么是慢sql,要么是一些查询语句太过频繁，性能比较差，一点点的优化，发现watchdog重启的频率愈来愈低了。

　　第二就是在实验室中作性能测试了，咱们收集了典型的场景作了压测，主要发现的问题是一些流程性能比较低，好比像页面展现的动态广告，每次实时查询数据库，而每一个页面不论是否展现广告都会进行一些复杂的逻辑计算以及数据库的查询。通常的方式都是可以异步的操做，异步操做。好比广告的点击量数据，其实没那么高实时性，咱们改为天天晚上后台统计算一次，展现的时候直接查询，而不是每次渲染页面实时的进行查询。

　　有了第一针的止血，加上第二招的实验室测试，前先后后大概一个月左右的时间，逐渐的稳定下来，本身在这过程当中学习了如何看awr报告，如何用linux命令定位性能问题，如何用LoadRunner性能测试。稳定之后，写了一篇总结给印度的同事，这个事情基本算告一段落了，对了，09年的国庆节我没有休息，全陪印度的同事在搞这个了。