web产品线上问题分析和处理方法

   [文章作者:狂奔的鹿(陆松林) 本文版本:v1.0  转载请注明原文链接:http://dynamiclu.iteye.com/]

   

 作WEB产品的技术人员,无论是开发、运维,还是DBA,都会有需要紧急救火的时候,重压之下,会手忙脚乱,也属正常。

(一). 对硬件损坏、网络不正常、电源类物理问题

   此类问题的保障还在平时的工作。 如消除单点,作好完全备分。  特殊情况无法彻底消除单点的, 如果主库(用来写的)只有一台机器, 这时一定要做好替换操作步骤文档,备机跟应用最好一模一样。 准备步骤很关键,虽然有很多命令我们平时敲了很多遍,可是在紧急关头,可能也会是一头雾水。按操作步骤操作能节省很多时间。 团队里就有这个一个例子,一个百万级PV、千万级库表的系统,主库因硬盘问题宕机,在没有mysql的DBA的情况下,开发人员自已动手,当时幸好之前准备了步骤,才能在断时间内恢复系统。    另外一个case,团队里新来一开发人员,对系统部置了解不深,问到这样一个问题,假如linux系统重启了,他不知道重启那些服务。 一般的方法都会是去查询文档,从文档里了解。但互联网产品迭代较快,部署设整快,有些文档太多、加上时间长,参考价值不是最佳。 当时我反问那个开发人员,说:“如何没有人能教你了,你会怎么办?”, 他没有回答。  后来我回答道:“为什么不能在系统正常的情况下,ps一把所有的进程,并保存下来”, 这个操作可能10秒就完成了,且得到的是最准确的服务器服务信息。  综上两个case,这类相关问题的处理,还是在平时的工作,平时把所有的可能都想到,并作好相应的准备,问题出现了,处理时也会得心应手。

(二). 对程序BUG、性能瓶颈、遭攻击等软件类

   1. 你的程序、你的系统完全监控起来了吗?

       大部分系统用nagios作监控时,都只会监控到cpu、内存、磁盘、端口、是否宕机; 如java的线程数、jvm内存使用、apache进程数、80端口的TCP连接数、连接池操作数据库的情况、请求的超时监控、重要功能是否完整等监控都会漏了。  传说facebook在上线功能时,一定会有个考查,这个功能或模块是否可监控,如果不能监控,就不能上线。  只有完全监控来起,加上适当的报警,才更有利于我们分析问题的真正原因。

   2. 问题分析思路

       A. 理清问题的现象

           这一步很关键,越是紧急的问题,越不能着急。 要思考,还可以用文笔把其现象记录下来。如,是个别现象,还是普遍现象? 问题发生的时间?  问题发生的场景(是linux,还是window,那种浏览器,版本是什么)? 问题出现的规律?

       B. 查询监控系统记录下来的数据

           查看数据,主要是核对问题的存在, 当然,如果通过现象,再根据个人的经验就可以99%地判断问题点在哪,就不需操作这步。   如,有人说我们的网站出现了502,当我们到现场的时候,可能自动恢复了, 这样可以通过时间去查apache或nginx的日志,来确认问题的存在。

       C. 重现问题的现象

           对于A步和B步都还没找到原因时,就得想办法重现问题。 问题要重现,就一定要跟问题的发现者多沟通,且完全沟通, 沟通清楚后对分析问题有事半功倍的作用,远远比登陆到服务器查看各种错误日志强。   问题重现了, 排查就有了方向。

   3.case经验

  •   如果监控报警做得完善的话,收到报警后,一般就会知道是那个环节出了问题。
  •   系统出现BUG或性能问题后,往往一般都考虑考虑最近是否上线了什么功能或调整。

      case: 团队里负责的一个产品,一段时间java的线程数间接性的、偶尔性地报警。线程高时,系统会变慢,一会又会自已缓过来。由于没有规率,现象不明显,找了好几天,没找到根本原因在那里,很苦恼,监控下来的数据也不能说明问题具体是在那个位置。  怀疑半个月前上线的VIP吧功能,询问具体开发这个功能的同事,功能正常,也经过测试,找不到疑点。 最后,无奈之下,还是只能怀疑半个月前上线的VIP功能, 指派另外一个工程师读其代码,DBA协助,截取了近三个小时的查询语句, 统计分析了一下,一半左右的数据查询是判断这个吧是否为VIP吧,语句本身查询很快,只是占用了大量的连接资源。 问题的根本原因找到了,VIP功能,memcache的过期时间太短,只设了20分钟,正常逻辑去判断的话,memcache过期设20分钟,可能不是什么太问题,关键是这个功能是访问量最大的帖子读取页,抓取等不规律的访问。优化系统,将memcached换成持久的ttserver。 问题得到了解决,系统再也不报警了。

       这个case查询时间较长,表现上看不出问题。只能通过统计数据,看到异常才得到结论。  经验教训:如果线上产品出现了一时很难分析的问题,就回顾一下作了那些改动,最近上线了什么功能,从这个入口去查问题。

  •      查询并统计apache或nginx的访问日志,看一下系统究竟在做什么 

  

   [文章作者:狂奔的鹿(陆松林) 本文版本:v1.0  转载请注明原文链接:http://dynamiclu.iteye.com/]

猜你喜欢

转载自dynamiclu.iteye.com/blog/1530744
今日推荐