救火队员的那些事

Posted 2020-08-07 CC

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

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

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

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

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

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

　　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年的国庆节我没有休息，全陪印度的同事在搞这个了。