力破困局千万重-技术咨询手记 1
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。
http://blog.devep.net/virushuo/2009/01/12/yinxing-tech-counseling-1.html
一 从何开始？
2006年10月，我和tiny创立银杏咨询，开始提供技术咨询服务。到现在，已经2年多了。时间过的真快！
这2年中，我们逐渐开始了站内搜索SAAS服务 ，但是咨询的服务也仍然在做。积累了2年，见过了太多正常的，古怪的，常见的，重复的，白痴的问题，现在，我打算开始慢慢的写出来，给别人参考。
当然，惯例声明。本文所述一切情况，并不来源于某个特定的团体或公司，是我们2年工作经历的组合，也就不用猜测到底是谁了。万一有雷同绝对巧合:D
记得我跟Fenng聊到过，写技术，尤其是优化和架构相关的文章，总显的很无聊。因为懂的人不说也懂，不懂的说了还不懂。新手的php程序员们不分场合的迷恋模版和MVC，而全然不知其所以然。所以后来我那个《让你的网站快100倍》，就没有继续写下去了。还是跟着实际的案例来看，会比较有趣一点，你说呢？
可以说，我们处在一个非常幸运的行业中，因为这个行业发展的太快了，人才缺口实在太大，大到历史上任何行业都没有过的程度。很多公司甚至糟糕到了没办法判断一个人是否能够胜任的地步了。某个公司的创始人跟我说，我们最大的问题是，根本没办法鉴别招聘来的这个程序员是高手还是忽悠。
这就是我们面临的情况。无数的新手，无数的忽悠，就这么草草上阵，开始为无数伟大的构想和商业模型搭建基础。如果不伟大的项目还好，早早就死掉了，也没有后面的问题了。伟大的项目，就会突然碰到瓶颈，这时候，大家都傻了。
我们的客户往往就是这类，他们是伟大的项目，所以他们碰上麻烦了。
“好了，咱们从何开始呢？”，会议桌对面的客户满脸的痛苦，想了半天，说出来这么句话。
我和tiny互相对视了一下，说：“就从你最头疼，影响最大的地方开始吧”。
这是一个媒体网站。按道理来说，媒体网站不大应该碰上性能问题，媒体网站更新量往往并不大，访问量也不大，但是人群比较集中，价值也比较高。这是网站里面活的最潇洒的一类公司，他们用数量小，价值高的pv获得可观的广告收入。对于硬件投入也比较舍得。但是现实总是这么荒唐，这种从来不愁钱的网站，碰上的问题最多。
他们最头疼的问题，就是网站会突然挂掉。但是找不到原因。
好吧，就从这里开始。
背景资料：本网站用java+jsp开发的。基于某古怪的架构(架构的古怪之处随后慢慢说)，每天更新量只有几十篇文章。访问量在百万以下的级别。没什么交互。
看起来很简单？清点一下系统拓扑图可不得了，竟然有10多台机器趴在机房里!而且还使用了CDN。饶是如此，仍然摆脱不了3天一小死，5天一大死的噩梦。
我们开始的方法很简单。查log。我们希望通过分析访问log，来获得系统各部分的负载状况，从而进行分析，找出薄弱环节。
log呢？竟然所有的服务器都没有记录log。
很多人认为，记录log会消耗更多的资源。其实并非如此，如果log非常大，比如几个G，确实会让写入的时候变得有一些慢。但是大部分情况下，如果定时清理，或是做了切分，不应该对系统性能造成什么影响。
平时不记录log是可以的，但是很多情况就错过了，将来需要回溯寻找问题的时候，就没有了依据。这很糟糕。google analytics很好，但是它是用来分析统计情况的，不是用来寻找系统问题的。你完全可以用google analytics来代替awstat之类的分析软件，但绝对不能替代原始的log。
针对这个客户的情况，我们记录了几种log。
1 java application server (tomcat/...) 的access log 和error log
2 apache 的access log和error log
3 mysql slow query
4 sar 记录系统活动
5 vmstat 状态 ，没什么现成的工具，我写了个脚本，供参考。
采集这些数据就可以进行初步分析了，修改好了所有配置，部署好了所需要的脚本，剩下的就是等待了。
等待出问题。
我心里偷偷的想，如果客户知道我们从这一天开始盼望着出问题，会不会恨我们.....
Comments
需要 sar 吗？我觉得过于牛刀了，呵呵
Posted by: qyb | January 13, 2009 11:06 AM
sar还是非常有用的。
以后你会看到这个系统有多乱腾。。。只怕拿到的信息不够。因为完全就是一团乱麻。
Posted by: virushuo | January 13, 2009 11:07 AM
我可以理解我自己为什么感到施展不上了为什么感觉这么累了
因为：
某个公司的创始人跟我说，我们最大的问题是，根本没办法鉴别招聘来的这个程序员是高手还是忽悠。
。。。。
Posted by: 一米六二 | January 13, 2009 1:23 PM
太短了……多写点啊
Posted by: 韩磊 | January 13, 2009 6:20 PM
"见过了太多正常的，古怪的，常见的，重复的，白痴的问题"
呵呵，最后这个形容词可不好啊。每个系统的形成都有其前因果。客户自然是有问题才来找你的。
尊重，更会提升你的价值。
Posted by: clickstone | January 13, 2009 9:29 PM
没事 白痴的是问题 不是客户
继续 等下篇～
Posted by: raptium | January 14, 2009 12:54 PM
开始了哈。：） 期待下一篇。
Posted by: 西哈土豆 | January 15, 2009 11:26 AM
你又做了一件功德无量的事情。
Posted by: jack | January 20, 2009 2:01 PM
在你提到的这个案例，PV压力不大，单位PV产出很高，钱多人单纯的地方，其实是很容易出问题的，主要原因，就是因为网站的创建初期，公司领导人在选择技术负责人或者技术平台的时候，是否能找到一个了解网站运维的，至少不是软件行业出身技术人员，来负责这个架构和体系的规划。
钱少不怕，没经验不怕，笨一点也不怕，就怕遇到没经验主意倍儿多，不重视规范和流程，什么东西修修补补弄出来再说的小聪明。
在互联网行业混了这么些年，得到的最大体会，就是规范的重要，这个规范，既包括一套流程和体系，又包括做事情讲规矩，不乱来，想一出是一出。
Posted by: 浅草妖怪 | February 25, 2009 11:27 PM
期待后续
Posted by: xiayong | April 7, 2009 10:18 AM
日志很重要
Posted by: 51qt | July 16, 2009 11:38 PM