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

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

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

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

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

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

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

  第一针止血,他们的要求很简单,就是不要每天半夜起来人工重启。这个要求简单,用perl写了一个watchdog的脚本,这个脚本原理很简单,但是发挥了很重要的作用。因为它不仅能够发现服务挂