码迷,mamicode.com
首页 > 移动开发 > 详细

我只想做好一件白衬衫 -- 小米推送服务监控手记

时间:2015-02-11 10:54:47      阅读:177      评论:0      收藏:0      [点我收藏+]

标签:小米   测试工程师   互联网   测试   xmpp   

最近读陈年先生的文章"凑热闹的公司都会烟消云散",读了十几遍,意犹未尽,感慨颇深。
我来小米三年了,三年前我会滔滔不绝的跟别人讲,如何带领几十个人,建立一套多么完善的质量保证体系,如何用制度让所有人都遵守软件开发的流程和秩序,等等云云;还要告诉大家,某某大公司都是这样干的,某某外企比这个干的还大,借以佐证我的思想是何等的正确和伟大。
现在想想,那时的我,SB!

2014年,我很平静的度过了,做了一年多的推送服务,写年终总结的时候,恰逢读到陈年先生的那篇文章,于是我想我一年做了这么多事情,有哪件事情可以拿出来炫耀,就像那件白衬衣呢?
于是我把所有做过的事情都列出来,然后一个一个划掉,这个事情做得太糙,这个事情做的太乱,这个,嗯,很一般;当你划掉几十件事情的时候,你的心就凉了,拔凉拔凉的;陈年先生在半层楼里放了所有的产品,却没有一个可以拿出手给雷总看的时候,也许就是这种感觉吧。
想了几天之后,我终于想到一件小事情,也许这件事情太平凡了,以至于成为了不过大脑的生活习惯;直到昨天跟某两个互联网大公司的服务器工程师吹牛的时候,我才发现,当我把这个牛吹完的时候,他们看我的眼神中似乎有了一丝异样的光芒。

我们花了一年多的时间只做了一套服务的监控,大的改版超过了10次,N多次的代码重构,推倒重写,各种尝试,各种跳坑,解决各种瓶颈,看各种密密麻麻的log,分析各种情况,处理各种异常,等等云云
其实监控原理很简单,在测试机上跑一组case,调一下线上服务的api,判断一下服务返回的结果对不对,对了就pass,错了就报警,就这么简单,没什么难的。但是我们前前后后做了一年多。。。直到今天,改动还在继续。

1.最初的方案是这样的,E2E的测试,用一个手机接到测试机器上,然后用脚本定时驱动安卓程序,向手机里安装一个推送客户端sdk demo,然后跑android的case,给客户端发消息,看客户端是否能收到,如果收到就从手机里读出来判断正确与否。这个代码很快就写好了,测试通过,嗯不错,开始跑吧。跑了一个晚上就傻眼了,由于手机通过wifi连接网络,各种网络不稳定所导致的误报,直接让报警不断,失去了报警的意义。怎么办?换一套环境
2.既然wifi环境不好,那就直接在网络接口接一个路由器,这个路由器只提供这一台手机的网络连接,这个总该稳定了吧。跑了两个晚上,嗯,误报是少点,但是总误报数量占的比例还是很大,报警搞得大家都很紧张,怎么办?再换一套方案。
3.使用android虚拟机,这个东西直接跑到测试机器上,完全不需要wifi,这总可以了吧?实践了几天,哭了,一个是虚拟机内存占用之恐怖,连续跑几天你试一试,另外性能也有问题,读取服务器的返回值是很慢的,需要长时间的sleep,最后就是不稳定,各种不稳定。
4.取交集,手机跑case网络是瓶颈,模拟器跑case稳定是瓶颈,能不能两个一起跑,如果同一条case都fail,才报警,只有一个fail,不报警。这个方案不错吧,取了一个交集;真到写代码的时候就完蛋了,两个监控一个跑的快,一个跑的慢,你还得写一个控制程序去定期分析两边的log,乱的一塌糊涂。
抛弃android吧,我们监控的是服务,干嘛要带上客户端,尽管E2E的监控更让人感觉靠谱吧,但是这不是最根本的东西
5.直接连服务器,客户端的原理是通过push demo调用push client sdk,client sdk最终是需要调用smack包来完成xmpp消息传输的;服务端工程师做E2E测试的时候,会通过一个中间层直接调用smack连接服务器;ok有方案了,把服务端工程师用到的中间层改改,然后套用客户端smack,再模拟客户端发出的请求,最上层接上test case,就应该能工作了;不久,这个移花接木的东西开始跑了,效果还不错,明显误报少了很多,很好,把前面那些不靠谱的监控全都干掉,把这货换上,然后张灯结彩,准备喝庆功酒,但是跑了几周,问题来了,长连接不像短连接,不成功就retry,长连接一旦断了,重新bind是有问题的,并且如何检测连接是否断掉呢?
6.最初的怀疑是smack不稳定,因为看到了smack的call stack,问题应该出在smack上,smack是第三方类库,用于xmpp的连接,但是我们使用的xmpp不是标准的xmpp协议,是经过我们改造过的xmpp,smack于是也被改造过了;查了一下maven库,上面有好几个smack的版本,换个别的用用,问问消息组的同事,各种尝试之后的结论是,这不是版本问题,别的版本不支持push服务,怎么办?改造smack吧
7.先找到smack的源代码,然后各种看,各种debug,然后整理了一下smack的行为规律:a.如果网络断了,smack发消息前,自己会检测到网络断了,然后发一个<present>强制断开网络连接;b.如果客户端等待收服务的消息,那就会超时,smack感知不到网络断开了。中间层是没法对重新bind做处理的;那就只能改smack,在收发消息的时候,先检查网络情况,如果断了就重新bind,代码改完了,找android的大牛军哥去看,没出5分钟就被拍回来了,这种改动会影响到连接的状态,这个太底层,最好别动。。。这次尝试又失败了,默默的在中间层加了一些重新bind的处理逻辑,效果也不是很好
8.重新回到原点,重新一个一个log去分析,慢慢的会发现,网络不稳定是一回事;中间层的不稳定,开始慢慢的浮出水面,中间层有大约20多个package,代码里有各种继承各种重写,很多静态的变量你如果不debug,根本都不知道哪里改变的,有时候改变一点点东西,上层的case就跑不起来。怎么办?凉拌,重写吧,按照自己的需求。这个花掉了几周时间,在某一个后半夜,所有case都可以在重写的中间层上跑起来了,那一刻根本没有什么兴奋,只想回家睡觉。重写后的只有2个package,大约7-8个文件,是的,上层的case其实用到的就这点。试着跑了几周,这个世界清净了,监控明显稳定多了,但是新的瓶颈又出现了。
9.中间层稳定了,就发现上层的case写的好挫,各种不靠谱,重写吧。。。又是几周,靠谱点了。
10.又遇到问题了,一次我们看监控很正常,但是某一个开发者说他们的app收不到push了。这次事故调查的结论是服务端对这个app的配置有问题。这次事故导致的是我们不再用单一的测试账号跑case,改用各个app的账号跑case,建立新的appinfo的列表,然后一个app一个app的跑。
11.又遇到问题了,当时我们有100左右的xmq,我们遇到了这样一个问题,由于当时的升级技术问题,导致了某次升级之后,有两个xmq的服务有问题,但是监控是随机落到各个xmq上,当时在很长的时间里并没有报警;这是一次事故,怎么让以后不出现这个问题呢?我们做了paritition监控,让每次的case都只落到一个xmq上,轮询所有的xmq;上线,跑了几个月,确实也发现了一些问题。
12.随着xmq的数量越来越多,轮询的时间越来越长,新的问题就产生了,如何快速知道某个xmq有问题了呢?我们考虑了多线程处理,两个方案,一个是自己写多线程的代码,另一个是使用多线程run case的工具;两个方案都做了几周,遇到了很多问题,最主要的是这是长连接,sleep会对所有线程有影响,如果某一条等消息时间过长,也会导致其它线程的case挂掉,这是跟短连接所不一样的;另一个是log如何处理,多线程的工具会把所有log打到一起,包括call stack,出了问题分析起来非常困难;最后就是稳定性,多线程受到网络的影响更重;最终我们没有采取多线程的方案。
13.case的区分度,多线程不行了,那就让case跑的更快,那么就可以更快的遍历所有的xmq;于是新的方案就产生了,首先分为p0,p1,p2的级别,p0白天跑,是用户最常用的功能,先保证这些功能不挂,p1晚上跑,这些是用户不是太常用的功能,晚点发现问题影响度相对小些,p2是剩下所有case,由于全跑下来时间太长,就几个小时跑一遍。另外一个维度是partition的监控按照xmq的顺序遍历,app的case随机落到xmq上,用以区分。
14.再次出现问题,用户看推送的统计报表的时候反应,我们昨天没有发topic消息,为什么报表显示有topic呢?查了一下,那是监控账号发的信息。啊,这次从监控上搞不定了。求助了服务器的开发,他们给监控提供了Extra字段,如果设置成test字段,统计报表就会过滤掉测试的消息数据,避免了用户的抱怨。
15.以前的xmq是用erlang语言写的,后来想换成了java语言,由于影响很重,大家都很谨慎;我们尝试了把xmq下发包中每一个字段都检查一遍,这时监控的问题就看出来了,以前只检查了一些关键的字段,没有全都检查;所以case都pass了,但是xmq下发的包,用户使用的时候,还是有问题的,因为你搞不清用户到底会用哪个字段,于是在灰度升级中就发现了测试的漏洞,前前后后折腾了好久,xmq下发的包一层包一层,拆了好几天。最后java xmq都上完线了,case中的各种检查也都加上了,xmq发出来的包结构也搞清楚了。
16.log的处理,报警邮件发出来,需要快速的定位,log的结构是否清晰,关键内容都显示,不重要的内容都删去,说起来容易,做起来不简单。三个人定义了log的格式标准,然后分分case,改吧,这个又改了一阵子
17.sd的机房满了,没有地方增加新的机器,服务端又没有多机房的方案,这时候消息会有各种延迟,监控一直在报警;开发很着急,硬件没有了,就只能改软件代码,让服务性能更好,于是引入一些bug,监控又报警;那段日子相当痛苦,我们唯一能做的就是增加sleep时间,关闭一些验证,只对重要字段验证,有些api没有返回包,都不在check。后来多机房方案出来了,迁移服务到lg,监控再连lg的服务,再报警,再处理,这个反复折腾了几周才搞定。
18.迁移到了lg,网络发生了变化,新的问题又产生了,大量网络问题导致的fail又卷土重来,这次我们放弃了五彩城机房的监控机器,在zc申请了新的监控机器,运维的兄弟在底层网络做了处理,让zc连lg接近于在lg直连,跑了一阵子,效果不错
19.随着case越来越多,监控种类越来越多,如何定时启动这些监控是个问题,最初是crontab,这个方法简单易行,但是服务挂掉你也不知道;后来使用了jenkins,这个东西麻烦的地方在于部署和自己没有办法发出报警邮件,也不能对历史的数据进行分析,而这些是我们需要的;权衡再三,我们的监控系统需要一个控制服务,这个服务应该定时run不同的监控,收集log,存数据库,发报警邮件和米聊,定期做数据分析,监控运行的过程中出了异常,应该有报警。立元断断续续的花了近2个月,在工作的间隙和业余时间写了这个控制服务,现在每天早晨会有头一天的几份数据分析报告发出来,根据这些统计数据,还是能看出服务的一些问题的。
20.经历了上面种种改造,现在监控已经逐步稳定下来了,服务的功能问题会很快的报出来,现在最大的问题还是网络问题,最近的一次定位有2点,a.可能是zc到lg的网络问题,b.FE-GW的前端可能有些问题。于是我们又增加了bind监控,遍历连接所有的xmq。对监控的改造还在继续。。。

上面只是举一些例子,事实上,遇到的问题要比这些多的多。
监控的敏感性和误报率是一组天生的矛盾,敏感性越高,误报率也越高;敏感性越低,误报率也越低;我们需要找到其中的平衡点,这才是最难的地方。
如果你问我现在的推送监控怎么样了,我不敢说它做的有多好,只是我晚上能安心的睡觉了。

最后我想说一下做监控这件事情的感受,
1.监控不是一个人的事情,这个工程关联很多团队,可能需要客户端开发,服务器开发,运维工程师和测试工程师,甚至其它团队共同协作才能找到问题的根源,才能解决很多问题。就像每一个团队就是一组齿轮,大家都把自己的那部分打磨好了,放到一起才能协同转动,最终拼接成一个精确的瑞士钟表。
2.科学界的一个不成文的定论是,基础研究聪明人是做不来的,只有天性笨拙一点的人,坚持每天做下去,做了20年30年,最终才能证明某些东西。监控是很基础的东西,不可能一蹴而就,今天晚上打冲锋,明天早晨就能实现共产主义;真的需要一些人踏下心来,认认真真的做上一年两年,也许才能做出点什么。
3.做监控是件小事情,做好监控是件大事情;大小取决于你看事物的颗粒度,看得越细致,事情就越多,做的事情就越大;看的越粗糙,事情就越小,做的事情就越小。这世界上没有什么高大上的东西,只是别人踩过的坑比你多了几个数量级,于是人家就形成了技术壁垒,这是你抄不来的,只有自己走一遍,一次次的从坑里爬出来,才会感受深刻。
4.面试中,我们经常看到面试人说自己在很短时间内,做了多少多少事情;却很少见到有人说,这些年我只做了一件事情。我想起了小野二郎,米其林三星大厨,今年90岁了,据说捏了近60年的寿司,被世人称之为寿司之神,米其林指南对他捏的寿司评价是:值得花一辈子排队等待的美味。人家花一生做一件事情,我们花一年做一件事情好不好?然后给面试官讲讲这件事情的细节,看看他的反应,嗯,应该很有意思。

今年是2015年了,我也在想今年做点什么小事?如果你想做一件很小的事情,我们可以聊一聊;如果你想做天大的事情,哥,我智商低,比我脑袋大的天,我想不明白。我只想做好一件白衬衫。?

我只想做好一件白衬衫 -- 小米推送服务监控手记

标签:小米   测试工程师   互联网   测试   xmpp   

原文地址:http://blog.csdn.net/missalucard/article/details/43731045

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!