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

[文章作者：狂奔的鹿（陆松林）本文版本：v1.0  转载请注明原文链接：http://www.cnblogs.com/dynamiclu/] 

   作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://www.cnblogs.com/dynamiclu/]