漫天风把细小的事情做到极致

林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为 Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi 在中国的推广起到了很大的作用。

王速瑜：数据集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？

林昊：一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在 3ms内完成）来决定。当达到性能瓶颈时，通常需要进行数据的拆分或备份等策略，在这个过程中最需要考虑的，就是对应用的影响程度，因此通常会需要一个强 大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构 并存、数据冗余和同步等问题。

王速瑜：数据备份问题：对于大容量的数据备份，技术上如何做到不影响正常的服务？如何合理制定冷备、热备的实施策略、方式、时间段？在数据损坏、主服务器硬件损坏等故障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？

林昊：对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知实现数据备份，或基于高端数据 库的特性（例如Oracle的Standby）。对于冷备、热备的实施，原则要求均为不影响正常业务功能，因此可选的时段只能是系统访问量较低的时段。方 式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切 换，就必须依赖强大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制，自动切换备库为主库，并通知所有应用转换为连接 和使用新的主库，如果做不到自动的话，这个过程就仍然得基于“人肉”来进行操作了。

王速瑜：开放平台设计问题：开放平台API设计中，调用协议设计时有哪些考虑要求？对于请求类的调用协议设计， 倾向于call?A=a&B=b这种方式（这种方式对调用者比较方便，但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比 如WSDL、XML等？对用户鉴权的Token机制是怎样的？有没有对接入方进行QoS的考虑，是怎么做的?

林昊：对于开放平台而言，基本上目前Facebook引领了开放平台的技术，因此在协议上多数都采用Http， 接口的设计上则都倾向于REST风格；对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式，并且此Token一定是由开放平台公司所提供； 开放平台中是肯定会对接入方的QoS有限制的，并且这通常也影响到了开放平台的收费标准，在实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电 信行业。

王速瑜：跨IDC部署程序模块在业务发展到一定阶段后在所难免，跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断的容灾措施？

林昊：跨IDC部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其次是部署所耗费的带宽成本和 时间成本，对于部署结果验证而言，通常可采用的方法为业务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而言，通常需要 借助自动化的部署系统。

王速瑜：Web2.0网站的海量小文件的存储，如用户头像、相册微缩图等文件，这些文件的特点是尺寸小（100KB以内），数量巨大（数以百万计），这些文件的存储、读取、备份都是问题，请问您是如何提供具体解决方案的？

林昊：目前互联网公司，例如Google、优酷等，对于小文件或大文件的存储都有自己的一套解决方案，而并不会 去依赖高端的存储设备来解决。一方面是成本问题，另外一方面是伸缩问题，因此对于这些文件的存储、读取和备份多数都采用了类似GFS的方案或直接采用 Hadoop提供的HDFS方案。

王速瑜：互联网产品部署是一个很关键的环节，很多互联网公司依然采取手工部署发布产品版本的方式，但是这种方式 比较复杂而且低效，往往很容易出错，如果同时发布几个产品时，如果产品之间关联比较紧密，其中一个发布出错就会影响到其他的发布，请问作为架构师，您在日 常工作中是如何解决这样的问题？您的团队中是否考虑自动化动态部署，具体方案是怎么样的？

林昊：在部署这个问题上，目前好像只有国外的几家互联网公司做的不错，其中最典型的是eBay。eBay在很多 年前就已经做了一套自动化部署系统，在这套系统中，eBay可以将一次发布中的几个产品进行依赖关系的分析，从而决定其发布顺序，并可实现自动的发布、校 验和回滚，这套系统相信也是现在中国几家互联网公司都在追求的目标。

王速瑜：作为互联网技术架构师，您能简单总结一下海里互联网服务技术架构方面的理念、原则，方法吗？

林昊：我觉得eBay的五点总结基本已经够全面：

（1）“ 拆分”，数据库的拆分以及应用的拆分，当然这需要强大的技术的支撑，这点要做到的目标通常是便于应用的无限水平伸缩；

（2）能异步就异步，这需要业务的允许；

（3）能自动就自动，就像自动化的部署系统；

（4）记住所有失败的事情，这点非常重要；

（5）容忍不一致性，这句话的含义是尽量少用强事务，而是采用最终一致性这类方案。

当然，除了上面这五点之外，还有像多用缓存、自行实现关键技术（以控制稳定性、性能和做到及时响应）等。

王速瑜：有很多优秀的软件架构师能力很强，但是由于缺乏海量服务技术应用和实践的机会，不能很好地进行海量服务应用的架构设计，您能给他们一些宝贵建议，分享一下您是如何不断学习成长起来的？您有哪些提高技术视野的方法和途径，比如有哪些书籍可以推荐，哪些优秀的网站可以推荐？

林昊：这个问题提到点子上了，很多架构师不知道如何应对大型、高并发的场景，最主要的原因是没有这样的实践的机 会，毕竟目前只有在大型企业系统或互联网才能获得这类难得的实践机会，通常在没有实践机会的情况下是很难完全理解这些技术的。多数情况下，互联网中的技术 方案都是在多次血泪宕机下成长起来的，建议只能是多看各种互联网技术介绍的文章，例如Google共享了很多，还有网上也有很多各家互联网公司技术架构文 章的介绍，尤其是那类技术发展历程的介绍，可以设想下如果自己碰到这样的问题，会如何去解决，也许这样能慢慢掌握和理解大型、高并发系统的解决方案。书籍 方面目前国内各种高性能方面的书也开始不断冒出了，例如有《MySQL性能调优与架构设计》、《构建高性能的Web站点》、《构建Oracle高可用环 境》等，这些高性能的书通常都来源于作者亲身的经验，是非常值得学习的；另外要知道：如果想做到高性能，通常意味着要对软件（包括OS等）以及硬件技术都 有充分的掌握，因此像《深入理解JDK》、《深入理解Linux内核》、《深入理解计算机系统》这些书也是非常值得一看的。至于网站方面，像http://highscalability.com/、http://www.javaperformancetuning.com/这些都是非常不错的网站。

（本文来自《程序员》杂志0909期，更多精彩内容敬请关注0909期杂志。）

如果说惯性维持着薪水，那么加速度代表着奖金和加薪。

近来和同事们聊起个人发展问题。发现程序员（其他行业估计也是如此）一到工作一年到两年之间，就会出现一个迷茫期。不知道自己的发展方向在哪里。有些公司虽然推出了职业规划，但很多人的关键问题在于不能正确认识自己的位置。那么走哪个职业方向，便变得不能顺利掌握。

在这种情况下，很多人的选择，是由社会的表现来决定的。看到管理比较好，就感觉自己应该向管理岗位发展。就像当初我们考大学选专业的时候一样，一般都会选热门专业，而不管是否能发挥自己的性格。

在聊的过程中，为了强调目标的制定方式，我请我的同事，分别说出自己的优点和缺点，并将我的看法好不吝啬地告诉他。我告诉他，在我每年的工作总结中，最愿意听到的就是领导对我的评价。虽然最愿意听到赞许的声音，但善意的批评，更让我容易发现自己的目标。

我给同事打了一个比方，领导说出的缺点，其实就是给自己立了一面镜子。你应该感谢这些人。以前做得不好的，已经不能改变了。我们能做的就是比以前更好。而这面镜子，恰好给我们指明了奋斗的起点，同时也说明了努力的方向。

我们往往介意地去关注自己的目前的状况，这就如物理学上说的惯性一样。惯性就是保持现有状况的能力。我们总是在意现在的速度比不上别人，并可能因此而失去前进的动力，进入了迷茫期。这个时期的特点就是将自己的发展交给了惯性。

面对处于迷茫期的人，很多人也容易在认识上走入误区，容易将他们定格。殊不知，对他们来讲，前途还未可知。相对于否定，他们更需要的是一个准确定位，并借此找明方向。

而对于新人来讲，重点需要认识的是，自己的未来，需要自己去把握！不管别人的批评怎么样，都不要因此而失去对自己的正确认识。并且借此要认识非常重要的三点：

1.
你还在成长阶段，不要忙着给自己定格
2.
你唯一能做的，并且对成长有效的，就是改变现在的状况
3.
不要以为别人只会看到表面！你的每一次改变，都会让关心你的人振奋。

所有的这些，都渴望让你因此得到一个加速度，改变你现在的，实现你追求的。依靠惯性，并不需要你额外付出什么，但既然你没有额外的付出，你为什么要苛求额外的奖赏呢？相反，努力才会有加速度，而你的价值，恰恰是在加速的时候体现出来的。

这个文章写的挺不错，值此半年考核之际，放在这里给Team内年轻的程序员们看看，也行有帮助。文章内容来自：http://blog.csdn.net/xiammy/archive/2007/03/05/1520676.aspx

上午参加了KM和南极产品周例会，在运营数据分析环节，基本上还是对着数据图来进行分析和介绍，无法让大家目标集中，会议效率也比较低下。总结如下，以后开产品例会的时候，在运营数据分析环节，应该按如下环节来分析，可能会达到一定的效果:

1、整体报告与运营目标的差距有多少？提醒大家关注运营目标
2、与前2周的数据对比和趋势分析
3、在本阶段做了那些运营活动和事项，带来的效果是什么？以及其它一些关键点分析
4、本阶段运营发现的问题有那些？对后续运营有什么建议？对产品有什么反馈？

初步的思考，先记录在这里，回头好好总结一下，产品运营的方法论有那些，希望能作为经验分享给团队的人

对创业者来说，2009年是一个最坏的创业时间，也是一个最好的创业时间。最坏是因为在今天这样一个资本市场环境下获得融资相对困难，特别是今年上半年。最好是因为它为真正适合创业的人降低了机会成本，去掉了泡沫的虚幻与累赘，清掉了一些乱七八糟的竞争者，同时正好为对准下一个经济高潮的到来腾出了足够的时间。

其实，虽然大环境不同，但2009年出来创业与2008年出来创业或者2010年出来创业没有本质的区别。无论什么时候，创业成功都需要五个要素：宗教般的虔诚（坚信自己要做的那件事哪怕全世界坚信这件事的只剩下自己一个人）、竹子般的韧性（即便是在祸不单行雪上加霜的那个晚上躺在床上也从来不会想到过放弃）、老鹰般的眼睛（抬起头来能看到远处的群山轮廓，低下头去也能看清自己的脚趾头）、大海般的胸怀（性格决定命运，分享与包容的习惯是一对能够带你飞得很远的翅膀）和傻子般的运气（不错，创业者是需要运气的，正如洛斯维加斯的游客。）。

下面给2009年出来创业的朋友几条具体的建议。与其说是建议，不如说是一个打对勾的清单：

1. 创业的原因首先是因为你对自己要做的这件事感兴趣，而不是仅仅对创富感兴趣，更不是因为找不到其它合适的工作。

2. 你对这件事感兴趣的程度已经到了夜里一想起来就兴奋得睡不着觉、不去尝试就浑身难受的地步。

3. 如果你有房子有车，你愿意把它们都抵押出去来做这件事。

4. 如果你在两三年后以失败收场，你确定你在这个过程中获得的快乐和满足足以抵消创业失败带来的烦恼与挫败感。

5. 你做这件事比马路上任何一个其他人有一些特别的优势。如果什么优势都没有，至少要有先发优势。

6. 你做的这件事是一件能够帮助人们生活得更加美好、愉悦、自由或者健康的事。

7. 你做的这件事的目标市场要足够大。做擀面杖不如做包子，开包子铺不行得把它开成全球连锁的肯德包、麦当包或者星巴包。（就是打个比方，千万别真的盗用人家的品牌和标识，那样不仅违法而且很低级，永无做大的可能。）

8. 你不是只有一份商业计划书或者一项技术，更不是只有一个想法或者一个故事。

9. 你这件事在未来一年到一年半的时间内不融资也能继续往前做。

上面这九条里你要只打了六个对勾或者更少，最好别辞职。如果已经辞了，就继续找工作。不是所有的人都适合创业，也不是所有的人都有条件创业，更不是所有成功的创业都必须发生在今天。暂时没有做好准备也没关系，只要你身体里流淌着创业者的血液，2010年甚至2019年也同样有机会。

面对全球金融风暴，50%以上的投资人（甚至可能是80%以上的）都没了主意，很多人东看西看哆哆嗦嗦就是不敢出手。这个时候，我希望我们真正适合创业并且已经做好准备的创业者们会比那些一向只会人云亦云缺乏独立判断喜欢锦上添花不喜欢雪中送炭的投资人更加清醒、果断、坚定和富有主见。黑暗中启程，转过一道弯就是黎明。一路走到“黑”，机会一定远远大于半途而废。

08年做得好的地方（不分先后）：

1、有了宝贝儿子；

2、积累了比较多的人脉，包括IDG, 电信，移动，国金，广电等方面的朋友；

3、阅读了不少其它领域的读物，尝试了不少东西，不断总结，积累和收获都有一定成效；

4、团队2大产品经过不断运营和探索，都有一定的成效，同时伴随团队不断壮大和成长，thinklet更加强大了；

5、明白了要好好的工作，好好的生活的道理；

08年做得不好的地方：

1、三心二意，不专注，执行力差；

2、目标管理弱，缺乏对细节的关注；

3、缺乏激情，容易迷失方向和信心；

4、拓宽新人脉的同时，忽略了旧人脉的维持与增进；

5、团队建设做得不好，有大半年没有任何建设工作；

09年来了，暂新的开始，09年计划做好：

1、专注做好一件事情，提升执行力；

2、学习目标管理，关注细节；

3、找好定位，努力尝试，拥抱变化；

4、提升影响力；

5、好好生活；

一，不要过设计：never over design

这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化 一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最 快最有效的响应。。

ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架 构。

web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的

二，web架构生命周期：web architecture‘s life cycle

既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你所设计的架构需要在1－10倍的增长 下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长。

google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的。

三，缓存：Cache

空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓 存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快 速为好。。

缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定。

老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具

钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv

Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理 能力低于请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存

四，核心模块一定要自己开发：DIY your core module

这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访 问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其 代码是非常可怕的

五，合理选择数据存储方式：reasonable data storage

我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？

首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)

select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ……………………………………….

我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定 是非常低的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站 (指内容型社区)需要面对的问题实际是有一些偏差的

同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存储结构，lucene使用文件来存储索引和文件。

从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转 换的过程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑 定

这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一个选项

六，搞清楚谁是最重要的人：who’s the most important guy

在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在web中我们一定以为最重要的涉众莫过于用户了。，在一个传统 的互动社区开发中，最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题 我就在数据里手动帮你加得了。。这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常 的多，普通人是不可能看完的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非 常重要，有时甚至是最重要的。

七，不要执着于文档：don’t be crazy about document

web开发的文档重要吗？什么文档最重要？我的看法是web开发中交流>文档，

现在大的软件公司比较流行的做法是：

注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以通过阅读产品设计文档来了解项目的概况。

而web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是 等你写出完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢，一种是每个人都了解 软件的整个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种face2face交流比文档有效率很多。

于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说，我们的项目是吵出来的，我听完会心一笑

八，团队：team

不要专家团队，而要外科手术式的团队,你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就

总结：

0)架构是一种权衡

1)web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。

2)此外，相应的，最有效率的交流方式必须留给web开发，那就是face2face（面对面），不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来。

3)人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。

另：有关web效率，有著名的14条规则，由yahoo性能效率小组所总结，并广为流传。业已出现相关插件（YSlow），针对具体网页按彼规则评分，这 次该小组负责人Tenni Theurer也受邀来到此次大会，我把Tenni小姐（之前真的没有想到她是个女孩，并且如此年轻）和她的团队的14 rules列在下面。

Make Fewer HTTP Requests
Use a Content Delivery Network
Add an Expires Header
Gzip Components
Put CSS at the Top
Move Scripts to the Bottom
Avoid CSS Expressions
Make JavaScript and CSS External
Reduce DNS Lookups
Minify JavaScript
Avoid Redirects
Remove Duplicate Scripts
Configure ETags
Make Ajax Cacheable

通过安装firebug和YSlow这两个firefox插件(请注意要先安装firebug再安装yslow,下载后拖动到firefox里即可)我们 可以看到你的网页根据下面的规则的评分

以下是《雅虎四年衰退的原因》的要点：

1、缺乏主打产品

自雅虎创立之初，该公司就一直染指了过多的产品。在泡沫1.0至泡沫2.0期间，雅虎以高估价在市场上收购了太多的创新企业。但是如何将这些企业整合到雅虎当中却是一件难事，这也使得雅虎内部出现太多不相关的业务。

盲目收购，而无法形成主产品链条上的整合。这个值得想多元化业务发展的公司的警惕。

2、高管自我封闭

雅虎高管经常不参加那些市场表现不佳部门的底层管理人员讨论会。一位已从雅虎离职的雅虎说，“我需要同一名高管进行会谈，然后就同一件事与另外一名高管进行会谈。我也知道有人向他们提过意见，但他们从来也不听取这些意见。雅虎内部存在过多的计划，我们更需要的是执行。”

3、容忍不表现的企业文化

在一段时间之后，看上去绝大多数的雅虎员工都放弃了想要变革的想法。当员工想要努力时，高管对此置之不管。因为许多员工都认为在其它公司他们不会得到类似的职位，因此最终他们都选择了沉默。

4、母体组织结构

设置母体组织结构，原先的想法是克服一家大型的全球性公司出现的复杂性问题。这也就意味着，雅虎会依据不同的地域任命多个高管，但他们又管理着相同的产品或结构性的任务。换句话说，雅虎员工就需要同时向多个上级汇报工作。这就使雅虎员工产生的混淆，到底谁应当对产品负责。

雅虎向很多互联网企业敲起了警钟！