原文链接： http://blog.jobbole.com/39602/

您可能也喜欢：
Tim[后端技术]:技术方案评审	工作与梦想中的工作 - 给应届生的建议	由一个问题到 Resin ClassLoader 的学习	程序员给五年前自己的10个建议	程序员的学习和积累
无觅

雷果国认为，乐于分享是促进程序员进步非常重要的一个关键点

雷果国（goosman.lei），2009年毕业于兰州商学院计算机科学专业，目前在百度任职PHP高级研发工程师。翻译有《extending and embedding php》一书，以及JQuery-UI-1.7.2官方文档、Pcntl、Pcre、Memcache和Memcached等PHP扩展的官方文档。 录有《let’s python》视频教程。 热衷分享，希望可以通过自己的努力，让国内的程序员入门及提升成本变低。

写在采访之前

在开始专访前，先和大家回顾下雷果国的《从1.5k到18k, 一个程序员的5年成长之路》博文内容（原文： 点此进入 ）：

背景：

• 2008年3月开始学习编程, 目前2013年3月。
• 2009年6月计算机专业本科毕业。
• 大学期间, 基本稳拿班级倒数第一, 高考英语49分, 大学英语除了补考没及格过。

总结：

• 5年间60%以上的时间, 每天凌晨2-4点睡觉。
• 为学习编程花费的总时间超过6000小时。
• 手写了超过50万行代码。
• 记录了超过100万字学习笔记。
• 录制了两份视频教程。
• 翻译了小型技术文档5份以上, 5个php扩展的官方文档, jqueryui官方文档一份, 书籍《PHP扩展和嵌入式》。
• 获得两次优秀员工。

雷果国先从2008年开始，讲述了自己在学校的生活状态和当时学习观念，他指出不要怕英文、出错信息和文档，它们都是学习英文的机会，同时也不要怕出错, 出错就是学习的机会。在随后做项目和找工作的小插曲中，雷果国认识到刚开始不要期望什么，放低身段，去做自己的积累就好。

毕业之后，雷果国的面试并非一帆风顺，在他人生的第一家公司中雷果国的工资也只有1千五，他和在学校学习时一样，依旧吃着泡面每天加班到9点，回家后继续学习到2点。而在这个屋里，冬天虽然有小电暖但屋里水龙头却已结冰，不过这并不妨碍他的学习和生活，因为他始终坚信：只要依然坚持学习，未来有一天他将不再这样。

2010年3月雷果国到了北京工作，他这一年始终为公司付出，从JavaScript进入，到后来页面制作、PHP和服务器等等，他没有觉得有多辛苦，相反觉得这是种锻炼，是他最大的收获。在2011年到现在的时间里，他学会了团队协作、同事关系处理，并且仍然在继续学习着，继续每天学到凌晨2-3点才睡觉，完成了Unix环境高级编程、Unix网络编程和PHP内核等重要积累。

通过这五年的努力，雷果国如今已进入自己心仪的公司。此外还值得一提的是他此前网名是selfimpr，含义是自强不息，是从self-improvement简写而来，而如今他的新网名是goosman，是从Swan Goose演化而来，他期待自己前五年的积累，能够在新环境中一展自己的鸿鹄之志。

以下为本次专访内容：

从开始到现在：我的学习历程

CSDN：为什么会写《从1.5k到18k，一个程序员的5年成长之路》博文分享这段成长经历？另外博文开头介绍了自己成绩倒数和英语不及格的背景，想给读者传递什么？

雷果国： 我其实一直想写这样一篇文章，因为我看到身边多数人都不是很努力，我觉得如果写这样一篇文章做分享，哪怕能有一个人能够有跟我一样的变化，那也是非常值得的。

正好最近得到了百度的工作机会，我觉得这算是自己这几年一个比较大的收获，所以借此机会写了这篇文章。

至于我介绍的成绩倒数，英语不及格，有两方面的原因：

1. 我希望那些看到这篇文章并且想要改变的人，不要因为自己没有基础而打退堂鼓。
2. 如果我的背景不是这么差，现在取得的成绩就不值一提了。

CSDN：当初为什么会选择计算机专业？在大学起初几年，你都在干什么？为什么突然意识到要努力学习？有什么事情影响或起到决定作用吗？

雷果国： 我当时第一志愿是物理学，对物理课本上关于爱因斯坦相对论的介绍很感兴趣，可是自己学习成绩不行，不能如愿。当时自己很爱玩游戏，调配志愿就写了计算机，结果就被这个专业录取了。

大学前2.5年就是整天玩游戏，通宵玩，玩到差不多被劝退的程度。

能够有所转变努力学习，是我老婆的功劳，有一次和老婆约会，聊我们的未来，我发现自己能给她的未来就是回家一起种地。 所以我就开始学习， 刚开始的半年也没有方向，去学习老师以前讲过的课本知识，没有效果，后来是当时尚学堂的免费视频教程，让我找到了方向 ， 大概一周时间，我就进入了状态。

CSDN：开始学习后，对自己有信心吗？身边的人又是如何看你的？你又是如何调整心态，无视这一切？这中间有没有发生什么特别的故事？

雷果国： 刚开始学习的时候，信心是十足的，问题出现在大概半年后，那些以前整天一起玩，一起疯的同学，就换了一种眼光看你，貌似在说“就你这样的，还学编程”。这段时间是很纠结的。

当时，我只是花更多的时间去学习，可能有一种要证明自己的心态。 直到第二年学校Java课我基本没上，但考试得了90多分的时候，同学们的看法才逐渐转变。

CSDN：确定目标后，你是怎么开始学习的？比如确定学什么？从哪方面入手？都用哪些书或教程？按照什么步骤进行？等等……

雷果国： 如前面所说，我前半年学课本知识没有效果。这并不是说课本知识没用，而是作为我当时的状态，我没有对整体知识脉络的了解，无从找到突破口，入不了门，建立不了兴趣。

后来是尚学堂的视频教程，给出了详细的学习路线，从Java的基本语法、到I/O、GUI、多线程、网络编程、网页编程和框架，到临毕业自己又看书学习了基本的数据结构与算法。至此，建立了在程序设计方面一个基本的知识体系，为以后独立自学打下了基础。

CSDN：在学习过程中，你还翻译了不少技术文档，为什么去翻译官方文档？这对你有什么作用？另外，大约是什么时候开始找到感觉和自信的？

雷果国： 我自己是靠别人的免费分享找到方向的，包括刚开始的时候，在CSDN论坛里提各种问题，得到很多无私的帮助，所以我愿意把自己知道的东西分享出去。

翻译官方文档，其实只是我在学习过程中的副产品，并且这个副产品对我的学习本身也有促进作用（翻译时看不懂英文的，就得去看源代码帮助理解），所以只要时间不紧张，我就愿意做这种事情。

感觉是在接触到视频教程大概一周找到的，自信是在学完数据结构和算法后才找到。

CSDN：你录制了多套视频教程，有人觉得这是比较浪费时间的事情，为什么要录制视频？它有没有影响到你学习进度，同时对你有没有起到什么帮助？另外，你称乐于分享是促进程序员进步非常重要的一个关键点，为什么会这么认为？

雷果国： 最初录制视频教程，是因为我当时要学python，但没找到python的视频教程，只能看书，而在之前我一直是看视频教程学习，所以只看书没视频很不习惯，这样学了3个月后，我突发奇想觉得自己也可以尝试录制一份教程。

想了后我就录了，我是边学边录制，大概是自己学第10章的时候，开始录制第一章内容，这份视频教程不仅没有浪费时间，反而对我的学习有促进作用， 因为你一旦要把自己学到的东西，讲给别人的时候，你会发现很多自己学的时候根本没有发现的问题就出现了 ，所以这份视频的录制，让我对python的学习更加深入和全面。

我们知道完成功能的软件和可交付的软件是有差距的，分享也是这个道理，你学习完一个知识，只是完成了功能，当你要把这些知识打包分享出去的时候，就是交付。从完成功能，到可交付，你会发现有很多不足需要改进。此外， 如果这个分享是被分享者和分享者可以互动的，那就更有意思了，被分享者就是分享者的QA，分享过程中会暴露更多的问题。因此，我说“乐于分享是促进程序员进步非常重要的一个关键点”。

CSDN：从你霸王面试开始，到进入心仪公司，能不能从你求职经历中分享一些面试经验？另外在面试中，你都有过什么挫折？如何面对的？

雷果国： 关于面试，我主要是放低自己的心态，这有好处也有坏处，坏处是薪资通常比实际能力要低一些，好处是放低心态，可以让自己在技术这条路上走的更远。

面试过程中的挫折就是第一次到北京的时候，去用友面试一败涂地，会的不会的都说不出来。所幸还有一家创业游戏公司收了我，我就沉下心来继续修炼，后来基本就没有在面试上被PK的太惨。

这一切都来自于心态

CSDN：从开始学习，到学有所成和找工作，再到工作中遇到各种困难，然后获得突破，在整个过程中，能总结下你心态都有哪些变化？是用运用什么方法或方式进行调整？

雷果国：

• 学习之前，我是破罐子破摔，爱怎样就怎样。
• 开始学习后，是因为找到了兴趣，开始有了目标，有了追求。
• 学习了一段时间之后，我开始认为自己不是破罐子，所以不再破摔，而是修补缺口。
• 能够给别人分享知识后，我觉得人的价值不在于自己挣多少钱，而是为这个社会创造多少价值。

• 目前，我觉得团队的价值大于个人的价值。

关于心态调整方法，我觉得是就是塞翁失马焉知非福，好的时候，想想未来的不好，不好的时候，想想未来的好，总之及时做好自己的心理平衡就好。

CSDN：你提到只有会管理自己情绪，才利于朝着目标达成的方向发展，你都是如何管理和培养自己的情绪？另外如何才能激发自己潜能，让自己对学习很兴奋？

雷果国： 情绪这方面，我们知道做技术的需要一颗平静的心，所以我会在平时就给自己心理暗示，告诉自己遇事要心平气和，然后当我急躁了之后，比如给人发火了，或者论坛里和人对骂了，在自己气消了之后，检讨自己，有可能的话还要拉下脸来给对方道歉，这样时间久了，就能慢慢做到遇事不惊。还有一点，就是劳动报酬方面（薪资等），我会尽可能的不去关心这一点，因为我觉得欲望是造成浮躁一个很重要的原因。

激发潜能方面，举一个例子：高中的时候，我经常去网吧通宵达旦的打游戏，那个时候，我喜欢听《2002年的第一场雪》，后来学编程之后，我已经基本不玩游戏了，但是到现在为止，每次带起耳机听这首歌的时候，我都仿佛置身当时网吧的环境，非常向往当时游戏的状态。

所以我在家写代码的时候，会喝点小酒，哼个小曲儿，让自己写代码的时候非常兴奋，长此以往，对这种环境形成一些心理上的依赖，这样就培养了对编程的兴趣。

CSDN：你的成长经历让很多人佩服，从当初的那个“我”到如今的“我”，很多人都很好奇你是如何寻找到发展方向，一步一步走到今天？

雷果国： 在我发表了那篇博文后，从评论中看到很多人说，这篇博文能够激励到自己，但能不能坚持不一定。我觉得问题的关键在于兴趣，很多人是不得已才从事这行。

如果有正在上大学的同学能够看到这份采访，应该趁还没有走出校门，赶快寻找自己的兴趣和工作的结合点，不要等到临出校门被现实逼着去做一份工作。 做工作很简单，但把工作要做成事业，没有兴趣的支撑，真的很难做到，工作4年，我目前没有见到过一个没有兴趣却能写好代码的人，哪怕是曾经在百度、阿里巴巴和腾讯这样公司工作的员工，也不例外。

CSDN：很多人都知道坚持就是成功，但很多人都坚持不了，这五年你是如何坚持下来的？都是如何激烈自己？有哪些方式或手段？

雷果国： 坚持就是成功，但不坚持不代表失败。有的人坚韧，有的人果断，有的人善言，每一种性格特点的人都有适合从事的工作，我觉得我能坚持下来，是所做的工作和兴趣、性格契合。条条大路通罗马，每个人要找到自己的路。

激励自己的手段，除了培养兴趣外， 产出是很重要的一点，在工作学习的过程中，对自己的产出做评估，比如我的博文列出的数据，我每隔一段时间都会去统计这些数据，当你看到自己一直在进步的时候，就会更加有信心向前走。

CSDN：博客下面不少人都很关心一个问题：刻苦学习长期熬夜，你身体状态是否一直都很好？这样健康的身体你是如何保持的？

雷果国： 我一般晚上回家吃完饭会先陪家人1-2小时，然后学习到2-3点睡觉，8-9点起床，多数时候是能保证6个小时睡眠时间。此外，就是周末睡个懒觉，陪家人出去郊游调整一下，总体算下来，比别人没少睡多少觉。所以，健康不会是太大的问题。

我的认识和感悟

CSDN：错过基础课让你面临技术上很多瓶劲，在这里能谈谈基础课的重要性吗？在众多基础课中，您认为哪些基础课比较重要？

雷果国： 虽然我是从应用开始学习，但是基础理论知识真的非常重要。我觉得应用是腿，决定你能不能走路，理论是干粮，决定你能走多远。

我做linux-web方向，所以就说说我认为对于linux-web方向研发比较重要的基础理论知识（不见得是大学的课程）：计算机网络、网络编程（套接字，TCP/IP）、Unix环境编程（进程，线程，内存管理，I/O系统）、数据结构与算法、HTTP协议、字符串处理（编译，正则，模板引擎）和C语言（学习C对理解底层环境有帮助）。

CSDN：自学成功你最大的收获和感悟是什么？对于那些在编程学习道路上仍在努力的初学者，有什么建议送给他们？

雷果国： 最大的收获：写程序时我很开心，我很开心我全家都很开心，我全家开心我就更开心……无限循环。 最大的感悟：无私必能成其私。

对于初学者，我想说：如果你不是发自内心的喜欢写程序，趁着还没陷入泥潭，赶紧找到自己的兴趣所在吧，如果你是发自内心的喜欢写程序，跟随你的内心，惬意的发挥吧。

CSDN：你的成功可以复制吗？如果别人也这么去做，作为过来人你觉得应该注意哪些问题？另外，有人在钦佩之余还指出，这样学习会失去生活的意义，你是如何看待这个观点？

雷果国： 我倒也算不上成功，但这份经历如果要复制，也是有前提的。 我觉得，在走这条路之前， 一定要在开始之前想清楚两个问题：这个职业是否真的有兴趣，这个职业特点是否真的符合自己性格特点。 如果想清楚这两个问题，我觉得过程是多彩的，每个人都有自己的精彩。

起初看到有人评论说这样学习会失去生活的意义，我困惑过几天。不过我想开了，每个人对生活的定义是不一样的，现在如果不让我这样学习，那生活的意义是什么？

PHP是最易学的语言，但难点也是这——简单易学难精通

CSDN：一开始学Java为什么会转到前端？后来又为什么从前端跑去做PHP？另外，在Java和PHP间，为何最终选择了PHP？你在这个转变过程中有没有遇到什么坎？

雷果国： Java到前端，以及前端到PHP的转型，都是工作的需要。

在我刚开始学习编程的时候，有一个长期目标是做程序员，有一个短期目标是做好Java编程，当我第一次换工作时，请假来北京找工作，3天时间并没有找到愿意接纳我的公司，所以我退而求其次，以前端开发工程师的身份进入到了一家创业游戏公司。在这里，我修正了短期目标做好前端开发。后来， 我接触到了PHP，而此时已经做了一段时间前端，我觉得做前端没有一些艺术细胞很难做到很好，而我是理性思维更多的人，所以我开始学习PHP。这次，我又修正了短期目标做好php编程。

在PHP和Java之间的选择，是因为PHP的完全开源，有任何问题，我都能以比较透明的技术手段追踪到根源。

其实这也是一个职业规划的问题，我们无法预估十年乃至二十年后自己的兴趣和能力，只能按照自己当前的兴趣和喜好程度，定出长期规划和短期规划，并根据发展的情况做出调整，应该说，只要你把职业规划当做一件事情来做，那目标肯定会越来越稳定。

转到前端时，困难比较明显，我是计算机专业，程序写的再好，做前端没有艺术感还是比较困难。而到PHP的转型，比较困难的就是java语法比较严格，到了一个松散的语法环境中略有不适，不过这一点相对比较好克服，严格要求自己就好。

CSDN：在百度做PHP方面的开发，新公司在技术或文化上哪里让你感触最深？另外工作这么长时间，你现在如何看待实践和理论这两者关系？

雷果国： 到百度之后，同事平均素质明显高于以前的公司，而且百度的文化执行的很好，在一个这么大的公司，却明显能感觉到身边的人都在执行“简单可依赖，具有狼性”的文化。

技术方面的感触，我就说说敏捷开发吧： 我是在进入百度后才接触到敏捷开发的，满打满算，才 40天时间，但这种开发模式真的对我冲击很大，它改变了我一个固有的看法——大公司专人做专事、流程化安全而缓慢。

在敏捷的团队中，大家更多的是强调团队的产出，弱化个人能力对团队的影响力，让团队成为一个原子性的整体。对工作量，进度的估算都不再按照个人进行，而是按照团队为单位估算，同时强调弱化角色分工，减小团队对个人的依赖性。

我觉得，站在项目的角度，这一切简直太美妙了：

1. 进度预估的风险： 过去以成员为单位预估，问题是难于估算，并且准确度低，现在以团队为单位估算，成员间的误差是有互补性的，提高了准确度。
2. 人力风险： 角色的弱化，大家都可以根据兴趣或团队需要做一些其他方面的工作，这使得每个团队成员都能放宽眼界，提升综合能力，另一方面，单个成员请假等特殊状况的风险也可有其他成员互补，降低产生团队人力瓶颈的风险。
3. 质量风险： 持续集成，持续测试，这使得每一次发布都是经过集成后测试的，降低了产品质量方面的风险。
4. 需求变更风险： 敏捷要求快速迭代，这就使得我们在迭代计划的时候，只安排少量高优先级的开发任务，因此，对低优先级的开发任务我们不会花过多时间关注，当需求变更时，多数情况都只是从需求池中将尚未细化的需求拿走，而很少会影响我们已经详细规划并进入迭代计划的需求。

当然，站在个人的角度，这其实提出了更大的挑战，每个团队成员需要对项目整体负责，需要掌握更多的技能。 虽然只接触了 40天，但敏捷开发带给我的感想是很深刻的，我觉得互联网公司特别需要敏捷开发，因为它的目标是快速发布、拥抱变化和降低风险，这非常切合互联网产品的特点。

如果没有实践，就不会有产出（专门搞理论的科学家，也是要经过实验验证理论的），但是如果没有理论，就只能重复性的实践，很难提升产出价值。所以，我认为实践和理论并没有孰轻孰重的关系，两者相辅相成，缺一不可。

CSDN：你比较擅长PHP，能不能就你学习和工作经验与大家分享下PHP学习如何开始和深入？有没有什么窍门？另外，PHP学习有什么难点？如何解决这些难点？

雷果国： 关于语言的学习，每个人有不同的方法，我就说说自己的学习过程：

在学习PHP之前，我有3种语言的经验，所以就随便找了本入门书籍，花一周时间，看看语法和函数库就上手做事情了。 对PHP了解的第一次进阶，是阅读PHP手册，PHP的手册非常棒，组织结构清晰，讲解详细，内容涵盖面非常广，认真读一遍，收获非常大。

接下来是两个方向：工程设计和底层实现。 工程设计方面，主要是找一些设计模式、持续集成和开发方法方面的书籍，广泛的阅读，并尝试在实际应用中去领悟书中所讲的内容。 底层实现方面，主要就是先去了解操作系统和网络等一些底层的知识，掌握C语言，然后去阅读PHP的源代码，看看PHP怎么运转。

众所周知，PHP是最易学的语言。但我觉得这就是PHP最大的难点——简单易学难精通。这方面，我认为要克服的主要还是心理因素，千万不能有“已经学会PHP”的想法。另外，PHP语法灵活，很难把握到底该怎样去写，这方面需要量的积累以及不断的思考。还有一点，PHP从内核的设计上，比较强调自由的扩展，所以对PHP内核的了解也很重要，这一点难度也很大，需要大量的基础知识积累，要克服也只有玩命的学了。

CSDN：你是什么时候开始接触CSDN的？它对你学习和工作都带来哪些影响？另外，你对CSDN有什么建议和期待吗？

雷果国： 我大概是2008年接触CSDN的，到现在也5年多时间了，起初它是我求知的主要平台，后来它是我分享的主要平台。一直以来，CSDN上的大牛们都是我奋斗的目标，当我低迷的时候，我就会想，或许有一天我也能成为那样的大牛。

也许是我最近两年逐渐转向博客，BBS这边光顾的少，目前对CSDN的感觉是在媒体方面的力度比社区方面大。从技术人员的角度来看，当然是希望CSDN这样的大平台更多一些社区特性，能够刺激国内技术人员的交流和成长。

写在最后：

在与雷果国的交流中，他还和我分享了一些总结，记者觉得这些分享蛮有价值，虽然有的点或许会与专访内容重复，但丝毫不影响其中传递出来的另外一种心态和观念，有心的朋友可以看下。

内容摘录如下：

心态上：我开始学习编程的时候，已经大三第二学期了，当时有自己的质疑，有周围人的质疑，”现在学还能来得及吗?”，对于跟我一样，在大学的最初几年已经荒废的同学来说，这个心态的调整很重要，就是坚信自己能行。

• 期望值：不少同学(包括那时的我)，在刚毕业的时候，觉得自己给老师做过项目，就感觉自己找工作会很容易，导致对自己期望过高。其实，就我自己的发展而言，如果不是这几年恶补基础理论，肯定不会走进自己梦想的企业。
• 目标定位的问题。我觉得很多大学生甚至毕业一两年都找不到自己的人生定位。我自己在刚开始学习编程的时候，已经有了一个目标定位，就是做程序员，这个目标定位非常符合我的兴趣，所以我可以5年间丝毫不改变这个目标定位。
• 态度上：分三个方面来讲，一方面是要付出很多努力;另一方面是不能认为自己已经付出了很多努力，就要求短期回报，而是向着长远目标看齐，宁肯放弃一些短期回报;还有一个方面就是持之以恒的坚持前两点。
• 方法上：坚持读英文，坚持读源代码，碰到问题就死磕，我在刚学了半年的时候，在没有网络的条件下，碰到一个问题靠跟踪源代码，花了7，8个小时才找到一个异常的根源。
• 情绪培养上：要学会管理自己的情绪。可以刻意找一些让自己兴奋的事情，在写程序时激发自己的潜能。同时生活中有不顺心事情的时候，尽量减少编码，防止这种心情潜在的影响自己对编码的看法。
• 熬夜的问题：有不少人表示自己做不到，或身体不行。其实，都是对自己要求不够（当然，不可避免有些人确实会受身体因素限制）。
• 码品如人品：我以前是一个邋遢的人，但是自从我刻意的去规范自己的编码风格后，我自己也变得不那么邋遢了，同时改变他的代码风格，也会潜移默化的改变他处世风格。
• 分享会迎来进步和尊重：乐于分享是非常重要的。因为一次分享过程，收益最大的通常不是听的人，而是讲的人。我翻译了很多文档，录制过视频教程，这背后最大的受益者其实是我自己。并且除了自己知识上的收获，分享者还能得到更多人的尊重。
• 实践与理论孰轻孰重：实践决定你能不能走路，理论决定你能走多远。 （文/张勇 责编/魏兵）

若想获悉雷果国更多动态，请关注：

个人博客： 请点此进入

社区之星访谈系列文章

专访邓凡平：Android开发路上的快速学习之道

专访阿朱：企业信息化的革命前夜

您可能也喜欢：
The C10K problem	新的 HTML5 Datalist 元素	博客可能被百度k站了	CSDN首页:软件研发 当程序不再工作时，程序员说	2012年，开发人员对HTML5都有哪些期待？
无觅

在互联网行业，基于Unix/Linux的网站系统架构毫无疑问是当今主流的架构解决方案，这不仅仅是因为Linux本身足够的开放性，更因为围绕传统Unix/Linux社区有大量的成熟开源解决方案，覆盖了网站应用扩展的方方面面。

我记得十几年前第一波互联网浪潮的时代，采用Windows平台ASP架构的大型网站是非常普及的，而如今采用Windows平台.net架构的大流量知名网站已经凤毛麟角了。很多采用Windows平台.net架构的大型网站都面临了架构上的扩展问题：

例如国外的SNS网站MySpace网站面临过很严重的性能扩展问题，国内电商网站京东也不止一次受困于架构扩展带来了性能瓶颈。因此，一些Windows平台.net架构为主的网站，不得不考虑“去.net化”，抛弃.net，全面迁移到以Java为主的架构上。

但是大型网站的架构迁移，本身也是伤筋动骨的事情，风险极高，成功案例尚不多见，失败案例俯拾皆是，这是因为：

1. 架构迁移是在现有业务系统上进行的，并不是从容的开发新产品，有足够的时间测试和完善，相当于给正在高空飞行的客机换引擎，必须一次切换成功，没有第二次机会，稍有差池，就会机毁人亡。而我们都知道，新开发一个大型系统，没有上线磨合和完善过，无法做到一次100%完美。
2. 架构迁移意味着老的研发团队将被淘汰，而往往老团队体系随着公司壮大已经掌握了足够话语权，新架构的团队在公司又根基未稳，出于维护自身利益的本能，新旧团队之间很容易爆发政治斗争，相互排挤，导致迁移失败。

5173“去.net化”的教训

5173网站以游戏装备交易起家，曾经在客户端网络游戏发展黄金时期，迎来了业务爆发性的增长期。此时，用.net架构开发的网站已经不堪重负，由于现有的.net研发团队长期无法解决网站的性能问题，5173决定将网站从.net架构全面迁移到Java为主的架构上。为此，5173花了很大的代价，从淘宝和SUN公司挖了很多工程师，组成了一个六七十人的Java架构研发部门。

新的Java研发部门开发新的5173网站，而老的.net研发部门维护现有的5173网站，两个部门并行工作，两个版本的网站并行运行，这带来了公司内部激烈的政治斗争，新开发完成的Java版本的5173网站从未正式上线过，老的.net研发团队在面临严重生存威胁的情况下，努力解决了一些核心的可用性和稳定性问题。同时随着端游黄金时代的结束，网站性能问题也逐渐显得不再重要。

在围绕新版本网站是否要正式替换老版本网站的问题上，各个利益方争执不下，反反复复拉锯战，而空降而来的女CTO不属于任何派系，态度模棱两可。最终斗争的结果.net利益方战胜了Java利益方，Java研发部门被清洗。

我的.net系统架构改造的经验和教训

3年前，我刚接手CSDN的产品和研发团队的时候，CSDN的核心系统大约2/3是Windows平台.net架构，1/3是LAMP架构。研发人员当时也很少：只有2个.net程序员，3个PHP程序员，后来还有1个我带过来的Ruby程序员。当时的计划是：网站整体架构改造的方向是Linux架构，逐渐替换掉现有的.net系统。因此不打算继续招聘和补充.net程序员了，现有的.net程序员负责老的核心系统维护工作。

但硕果仅存的2个.net程序员在随后不到半年时间都走了：一个.net程序员跟着微软出来的高管去创业，另一个.net程序员跳槽去百度做了前端工程师。这中间的道理也很简单：既然公司要去.net化，那.net工程师就会担心等到将来.net系统都换掉之后，自己在公司还有价值吗，不就彻底边缘化了吗？

当然我在制订架构迁移计划的时候，也考虑到了这一点：我给那个更资深的.net工程师制订的是整个公司总架构师的培养计划，那个精通JS的.net工程师制订的是未来前端团队Leader的培养计划。不过有不确性的承诺总是不如现实的威胁更迫切，所以我也特别能够理解.net工程师的流失。

这个时候，我陷入了一个两难的处境：

• 如果未来还是沿着“去.net化”的计划往下走，就算重新招聘和搭建了.net研发团队，由于.net在公司是注定要被替换掉的，那么新的.net团队是不可能稳定的，很可能来一两个月，一看形势不对，立马走人了。而当时.net的核心系统占整个网站的比重很高，且极端复杂，一旦出问题，根本就束手无策，必须要有好手坐镇维护。当时我已经开始review核心系统的.net代码，准备亲自上阵了。
• 如果未来放弃“去.net化”的计划，也许短期可以解决一些头疼的系统维护的问题，但是对整个网站长期的发展会带来很多不利的方面：例如网站的安全性问题，网站的架构扩展问题，网站服务端软件全面正版化的成本问题等等。如果当时不下定决心去.net化，那么将来再想做这个事情，代价只会越来越高。

当时，我最初的想法是：招聘2名水平尚可，没有太大上进心，可以安于现状，踏踏实实工作的.net程序员来维护老的.net核心系统；同时招聘和搭建ruby研发团队，以我过去用ruby开发网站的惊人开发效率，争取时间，逐一重写老的.net核心系统。但是这样做，风险也很大：

1. 我来CSDN的时间不是很长，当时CSDN线上产品又多又杂，足有上百个之多，很多系统我都不清楚干什么的；
2. 公司领导也不太支持我这么快动手，甚至很担心我大刀阔斧的改造网站，会把当时已经很脆弱的网站彻底搞休克；
3. 我来北京以后，只带过来1个Ruby程序员，而搭建Ruby团队，磨合团队，开发核心系统，都不是一朝一夕的事情，想快也很难快起来；

幸运的是，我招聘过程中，面试到了两个相当不错的.net工程师，有很强的上进心，编程功底和悟性都很好。虽然不符合我当时想找安于现状的工程师的标准，但我又不太想错过好的人才，所以我临时改变了自己的想法，将他们招过来，组建了新的.net团队。

为了避免出现之前.net团队流失的问题，给新的.net团队创造在公司发展的机会和空间，我想来想去，决定采取一个折衷的方案：即保留和沿用.net编程语言和框架，但是网站整体架构仍然去Windows化，概要说来：

1. 数据层放弃SQL Server数据库和存储过程，全部迁移到Linux平台上的MySQL数据库上；
2. 缓存不再依赖.net自身提供的缓存机制，迁移到部署在Linux平台上的分布式的Redis上；
3. 服务之间的调用，避免使用.net自身专有协议，改成Restful的HTTP Web API调用；
4. 静态资源请求，不再让IIS自己处理，分离到Linux平台上的nginx去处理；
5. 需要读取的文件系统，也改成访问Linux平台上的分布式文件系统；
6. 部署.net代码的Windows服务器放在LVS后面，用LVS做负载均衡和故障切换；

简单说来，就是单纯让.net做应用层的编程语言和框架，其他都交给Linux平台的开源解决方案。而.net框架单纯做应用层，无论ASP.net MVC的开发效率，还是.net CLR虚拟机的运行效率都非常好，目前我们单台Windows服务器上跑几百万的动态请求毫无压力，而且应用层架构是可以横向扩展的：如果请求负载非常高，只需要添加更多Windows服务器即可。总之，做到了扬长避短。

此外，我也比较注重不同编程语言研发团队之间的交流，鼓励.net工程师熟悉Linux操作系统，培养.net工程师整体架构意识。我们现在的主力.net骨干和我说，感觉来到这里以后技术上最大的提升就是视野一下被打开了。

在后来两年的整个网站改造过程中，也证明了这样的做法是相当成功的：

1. .net团队稳定的延续了下来，而且成为整个研发部门表现一直非常突出的团队；
2. 整个系统改造的过程非常稳健和平滑，没有碰到过什么风险；
3. 对网站用户的冲击很小，基本上都是在潜移默化当中，不知不觉的完成了整个网站产品的翻新；
4. 对公司线上业务也没有造成任何影响，而且随着系统不断改造，对业务的支持越来越好；

当网站架构全面Linux化，并且架构解决方案全部统一以后，其实在应用层用什么编程语言来写，就不是一件重要的事情了，我们目前应用层现有产品线，既有.net，也有PHP和Ruby写的，但是架构都是统一的，用什么编程语言，主要取决于研发团队资源的调配情况而定。

总之，以我的经验来说，一个传统上严重依赖微软解决方案架构的网站，如果要进行架构改造，迁移到Linux平台，甚至用其他编程语言重写，从来都不是一个单纯的技术问题，它至少涉及如下几个层面的问题：

1. 如何保障旧系统的研发团队的利益问题，如何做到激励老团队参与架构改造，分享成功。这是最重要的，往往也是架构迁移最容易出现的致命问题，如果架构改造注定要牺牲老团队，完全不考虑和保障他们的利益，我认为一定会产生残酷的政治斗争，最终必然失败；
2. 现有业务系统如何保持正常运转和平滑过渡的问题，如果架构改造影响到了业务，那一定会夭折；
3. 如何保证网站用户体验的平滑过渡和改善的问题，如果架构改造影响了用户基本使用体验，那也一定会被叫停；
4. 领导对架构改造当中出现风险的容忍度问题，以及领导对架构改造周期拉长以后的耐心问题；

一点题外话

我感觉我们互联网行业有一个不太好的现象：有些网站在促销期间瘫痪了，有些网站经常出现访问不稳定的现象，公司老板就喜欢跑到微博上来放狠话，请下属喝茶，或者急就章的嚷嚷百万年薪招CTO，这些都是很幼稚的做法。这就好比一个人，平常生活习惯差，花天酒地，从不注意养生，结果长年累月下来，终于病倒了。在这个时候狠狠的挥舞支票嚷嚷，哪个名医能给我药到病除，我给谁百万报酬。

所以，当一个网站出现严重的技术问题，其根源往往都不是单纯的技术问题，也不是单纯换个CTO就可以药到病除的，要反思公司企业文化是不是从来没有重视过研发，对技术团队的激励到位了吗？对架构师的意见重视过吗？对未来可能面临的技术门槛是否有过长期的研发投入？

关于这个现象，我记得Fenng说过一句很精辟的话：“技术问题，总是在短期被高估，在长期被低估”，我也想补充一句：“技术出现了问题，从来都不单纯是技术导致的问题”。

您可能也喜欢：
引入新编程语言的经验教训	NoSQL生态系统	林仕鼎：系统架构领域的一些学习材料	robbin谈管理：要给下属challenge你的机会	一些产品经验
无觅

系统架构是一个工程和研究相结合的领域，既注重实践又依赖理论指导，入门容易但精通很难，有时候还要讲点悟性，很具有“伪科学”的特征。要在此领域进阶，除了要不断设计并搭建实际系统，也要注意方法论和设计理念的学习和提炼。

经常有同学询问如何学习，特贴一篇学习材料，供大家参考。09年时写的，在系统领域浩如烟海的文献中提取了一些我认为值得研究和学习的项目，没包括近几年出现的一些工作，也不够全面。不过，其实也足够了，看paper是一个从少到多再到少的过程。对问题本质、背景和发展历史有大致了解，再辅以hands-on的实践（长期的真正的实践），足以摸到本领域的门径。

此文在网上转载不少，但多数没有说明出处。今天在这里重发，也顺便向315致敬。

—

对于工程师来说，到一定阶段后往往会遇到成长瓶颈。要突破此瓶颈，需要在所属技术领域更深入学习，了解本领域的问题本质、方法论与设计理念、发展历史等。以下提供一些架构相关领域的学习材料，附上简单点评，供有兴趣的工程师参考。希望大家能通过对这些领域的了解和学习，掌握更多system design principles，在自己的工作中得心应手，步入自由王国。

1. Operating Systems

Mach [Intro: http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html,Paper: http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/doc/publications.html]

传统的kernel实现中，对中断的响应是在一个“大函数”里实现的。称为大函数的原因是从中断的入口到出口都是同一个控制流，当有中断重入发生的时候，实现逻辑将变得非常复杂。大多数的OS，如UNIX，都采用这种monolithic kernel architecture。

1985年开始的Mach项目，提出了一种全新的microkernel结构，使得由于70年代UNIX的发展到了极致而觉得后续无枝可依的学术界顿时找到了兴奋点，也开始了沸沸扬扬的monokernel与microkernel的争论。

插播一个花絮：Mach的主导者Richard Rashid，彼时是CMU的教授，受BillGates之托去游说JimGray加盟MS。结果把自己也被绕了进来，组建了Microsoft Research。他到中国来做过几次21Century Computing的keynotes。

Exokernel [Intro:http://pdos.csail.mit.edu/exo/，Paper:http://pdos.csail.mit.edu/PDOS-papers.html#Exokernels]

虽然microkernel的结构很好，但实际中并没有广泛应用，因为performance太差，而且大家逐渐发现OS的问题并不在于实现的复杂性，而更多在于如何提高application使用资源的灵活性。这也就是在kernel extension（例如loadable module in Linux）出现后，有关OS kernel architecture的争论就慢慢淡出人们视线的原因。

Exokernel正是在这样的背景中出现的，它并不提供传统OS的abstraction（process,virtual memory等），而是专注于资源隔离与复用（resource isolation and multiplexing），由MIT提出。在exokernel之上，提供了一套库，著名的libOS，用于实现各种OS的interface。这样的结构为application提供了最大的灵活度，使不同的application可以或专注于调度公平性或响应实时性，或专注于提高资源使用效率以优化性能。以今天的眼光来看，exokernel更像是一个virtual machine monitor。

Singularity [Intro:http://research.microsoft.com/os/Singularity/,Paper: http://www.
research.microsoft.com/os/singularity/publications/HotOS2005_BroadNewResearch.pdf]

Singularity出现在virus，spyware取之不尽、杀之不绝的21世纪初期，由Microsoft Research提出。学术界和工业界都在讨论如何提供一个trust-worthy computing环境，如何使计算机系统更具有manage-ability。Singularity认为要解决这些问题，底层系统必须提供hardisolation，而以前人们都依赖的硬件virtual memory机制并无法提供高灵活性和良好性能。在.Net和Java等runtime出现之后，一个软件级的解决方案成为可能。

Singularity在microkernel的基础上，通过.Net构建了一套type-safed assembly作为ABI，同时规定了数据交换的message passing机制，从根本上防止了修改隔离数据的可能。再加上对application的安全性检查，从而提供一个可控、可管理的操作系统。由于.NetCLR的持续优化以及硬件的发展，加了这些检查后的Singularity在性能上的损失相对于它提供的这些良好特性，仍是可以接受的。

这种设计目前还处于实验室阶段，是否能最终胜出，还需要有当年UNIX的机遇。

2. Virtual Machines

VMWare ["MemoryResource Management in VMware ESX Server"，OSDI’02,Best paper award]

耳熟能详的vmware，无需多说。

XEN [“Xen and the Art of Virtualization”, OSDI’04]

性能极好的VMM，来自Cambridge。

Denali [“Scaleand Performance in the Denali Isolation Kernel”, OSDI’02, UW]

为internetservices而设计的application level virtual machine，在普通机器上可运行数千个VMs。其VMM基于isolation kernel，提供隔离，但并不要求资源分配绝对公平，以此减少性能消耗。

Entropia [“The Entropia VirtualMachine for Desktop Grids”, VEE’05]

要统一利用公司内桌面机器资源来进行计算，需要对计算任务进行良好的包装，以保证不影响机器正常使用并与用户数据隔离。Entropia就提供了这样的一个计算环境，基于windows实现了一个application level virtual machine。其基本做法就是对计算任务所调用的syscall进行重定向以保证隔离。类似的工作还有FVM：“AFeather-weight Virtual Machine for Windows Applications”。

3. Design Revisited

“Are Virtual Machine Monitors Microkernels Done Right?”，HotOS’05

这个题目乍听起来，十分费解，其意思是VMMs其实就是Microkernel的正确实现方法。里面详细讨论了VMM和Microkernel，是了解这两个概念的极好参考。

“Thirty Years Is Long Enough: Getting Beyond C”, HotOS’05

C可能是这个世界上最成功的编程语言，但其缺点也十分明显。比如不支持thread，在今天高度并行的硬件结构中显得有点力不从心，而这方面则是functional programming language的长处，如何结合二者的优点，是一个很promising的领域。

4. Programming Model

“Why Threads Are a Bad Idea”

单使用thread结构的server是很难真正做到高性能的，原因在于内存使用、切换开销、同步开销和保证锁正确性带来的编程复杂度等。

“SEDA: An Architecture for Well-Conditioned, Scalable Internet Services”，OSDI’01

Thread不好，但event也没法解决所有问题，于是我们寻找一个结合的方法。SEDA将应用拆分为多个stage，不同stage通过queue相连接，同一个stage内可以启动多个thread来执行queue中的event，并且可通过反馈来自动调整thread数量。

Software Transactional Memory

如果内存可以提供transaction语义，那么我们面对的世界将完全两样，language, compiler, OS, runtime都将发生根本变化。虽然intel现在正在做hardware transactional memory，但估计可预见的将来不会商用，所以人们转而寻求软件解决方案。可想而知，这个方案无法base在native assembly上，目前有C#,haskell等语言的实现版本。资料比较多，参见Wikipedia。

5. Distributed Algorithms

Logical clock, [“Time,clocks, and the ordering of events in a distributed system”, Leslie Lamport, 1978]

这是一篇关于Logic clock, time stamp, distributed synchronization的经典paper。

Byzantine [“The ByzantineGenerals Problem”, Leslie Lamport, 1982]

分布式系统中的错误各种各样，有出错就能停机的，有出错了拖后腿的，更严重的是出错了会做出恶意行为的。最后的这种malicious behavior，就好像出征将军的叛变，将会对系统造成严重影响。对于这类问题，Lamport提出了Byzantine failure model，对于一个由3f+1个replica组成的statemachine，只要叛变的replica数量小于等于f，整个state machine还能正常工作。

Paxos [“The part-time parliament”, Leslie Lamport, 1998]

如何在一个异步的分布式环境中达成consensus，这是分布式算法研究的最根本问题。Paxos是这类算法的顶峰。不过这篇paper太难了，据说全世界就3.5人能看懂，所以Lamport后来又写了一篇普及版paper：“Paxos Made Simple” ，不过还是很难懂。另外，也可参看Butler Lampson写的“The ABCD’s of Paxos”（PODC’01），其中关于replicated state machine的描述会严重启发你对并行世界本质的认识，图灵奖的实力可不是盖的。

这上面反复出现了一个名字：Leslie Lamport，他在distributed computing这个领域挖坑不辍，终成一代宗师。关于他，也有几则轶事。记得以前他在MSR的主页是这么写的，“当我在研究logicalclock的时候，BillGates还穿着开裆裤(in diaper)…”（大意如此，原文现在找不到了）。另外，他在写paper的时候，很喜欢把其他牛人的名字变换一下编排进去。这可能也是他还没拿到图灵奖的原因。

关于Lamport的其他成就，还可以参见这篇向他60岁生日献礼的paper：“Lamport on mutual exclusion: 27 years of planting seeds”, PODC’01。

6. Overlay Networking, and P2P DHT

RON [“Resilient Overlay Networks”, SOSP’01]

RON描述了如何在应用层搭建一个overlay，以提供秒级广域网网络层故障恢复速度，而现有的通过路由协议来恢复通信的时间至少在几十分钟。这种快速恢复特性和灵活性使得overlay networking现在被广泛应用。

Application Level Multicast

“End System Multicast”, SigMetrics’00

“Scalable Application Layer Multicast”, SigComm’02

关于ALM的paper很多，基本上都是描述如何搭建一个mesh network用以鲁棒的传输控制信息，另外再搭建一个multicast tree用以高效传输数据，然后再根据多媒体数据的特点做一些layered delivery。前几年出现的coolstream, pplive等系统都是这类系统的商业化产品。

P2P

P2P的出现改变了网络。按照各种P2P网络的结构，可以分为三种。

1.    Napster式，集中式目录服务，数据传输Peer to peer。

2.    Gnutella式，通过在邻居间gossip来查询，也被称为unstructured P2P。

3.    DHT，与unstructured P2P不同的是，DHT进行的查询有保证，如果数据存在，可在一定的hop数内返回。这个hop数通常为logN，N为系统节点数。

典型的DHT有CAN, Chord,Pastry, Tapestry等四种。这些研究主要在算法层面，系统方面的工作主要是在其上建立广域网存储系统。还有一些人在机制层面进行研究，例如如何激励用户共享、防止作弊等。

7. Distributed Systems

GFS/MapReduce/BigTable/Chubby/Sawzall

Google的系列paper，大家比较熟悉，不再多说。在此可查。

Storage

Distributed storage system的paper太多了。下面列出几篇最相关的。

“Chain Replication for Supporting High Throughput and Availability”, OSDI’04。

“Dynamo: Amazon’s Highly Available Key-value Store”，SOSP’07。

“BitVault: a Highly Reliable Distributed Data Retention Platform”, SIGOPS OSR’07。

“PacificA: Replication inLog-Based Distributed Storage Systems”, MSR-TR。

Distributed Simulation

“Simulating Large-Scale P2P Systems with the WiDS Toolkit”, MASCOTS’05。Distributed simulation有意思的地方是simulated protocol是distributed的，而这个simulation engine本身也是distributed的。Logical和physical的time和event交杂在系统中，需要仔细处理。

8. Controversial Computing Models

现在的软件系统已经复杂到了人已经无法掌握的程度，很多系统在发布时都仍然带着许多确定性(deterministic)或非确定性(non-deterministic)的bugs，只能不断的patch。既然作为人类，不够精细的特性决定了我们无法把系统的bug fix干净，我们只能从其他角度入手研究一种让系统在这令人沮丧的环境中仍能工作的方法。这就像一个分布式系统，故障无法避免，我们选择让系统作为整体来提供高可靠性。

以下3个便是典型代表。基本上，主要研究内容都集中于1) 如何正确保存状态；2)如何捕捉错误并恢复状态；3)在进行单元级恢复时，如何做到不影响整体。

Recovery Oriented Computing

Failure oblivious computing, OSDI’04

Treating Bugs as Allergies, SOSP’05

9. Debugging

系统很复杂，人类无法从逻辑上直接分析，只能通过data mining的方法在宏观上进行观察。

Black box debugging[“Performance debugging for distributed systems of black boxes”, SOSP’03]

对大型系统的performance debugging非常困难，因为里面的问题很多都是非确定性的，而且无法重现。只能通过对log的挖掘，找出配对的调用/消息以定位问题。

CP-miner [“A Tool for Finding Copy-paste and Related Bugs in Operating System Code”, OSDI’04]

很多人在重用代码的时候，都使用copy-paste。但有时候简单的CP会带来严重的问题，例如局部变量的重名等。CP-miner通过分析代码，建立语法树结构，然后mine出这类错误。

您可能也喜欢：
由一个问题到 Resin ClassLoader 的学习	什么时候学习编程都不晚	谈谈新手如何学习PHP^_^	关于任务管理系统	浅谈Oracle学习方法
无觅

今天在新浪微博上看到@朱志一条微博：

听到一个真事，腾讯pony晚上一点在微信群里面提了一个小bug，下属立即组织行动小组，第二天6点解决了问题。360，新浪大都这样。以前总觉得大公司官僚，执行力低下，现在看看，能超越大公司执行力的创业公司寥寥无几。要在大公司夹缝中生存，只能模式创新。

然后看到@胡宁一条转发评论：

这段子表现出国内公司典型的敬畏上司，无原则讨领导欢心的倾向。回国这些年，感觉下属们普遍很＂乖＂。老板提出的意见，即使再微不足道甚至可能是错的，优先级自然是最高的，加班加点地处理。这种特权，固然体现执行力，令领导舒服，更值得警惕。调查一下：带团队的你，怎么看？

然后看到@纯银V的一条评论：

普通职员和高级职员最大的区别，不在于经验或者才能，而是普通职员靠上级安排的任务来驱动自己，高级职员靠责任感与成长目标来驱动自己。

觉得这个话题蛮有意思的，所以想写篇文章谈谈我的个人观点，一家之言，非常可能谬误，权当抛砖引玉。

腾讯微信的执行力是不是媚上？

@朱志这个段子需要一些上下文，前不久马化腾参加两会期间接受的采访谈到：

我们也是跟Line一样，在同一个月内，在美国也是设立办公室，在加紧去拓展欧美市场。但是大家都知道美国其实可能是最难的，所以现在还很难说，因为当地最强的就是Facebook。 可能竞争是要按天来计算的，都是生死时速 ，每天都在计算的这样一个竞争场景，我们也希望能够尽一把力，成和不成可能这辈子就这个机会了。

微信和Line的国际化竞争已经按天来计算了，必须要求按天来修复产品bug，这并不是媚上的需要，而是产品竞争客观上必须要求的执行速度。所以我对马化腾的勤奋，对微信团队自身的勤奋，抱着高度的敬佩，同时我也非常看好微信的前景。

要求下属服从的企业文化未必不好

国内的公司，无论是国企，外企，还是民企，普遍要求下属无条件服从上司，这本身不一定是坏事，特别是公司如果有想法的人太多，想法又无法统一起来，公司的整体战略呈现精神分裂状态，那基本上就离死不远了。所以管理层统一公司战略，一线员工强调使命必达，也是一个必要的基本要求。

我感觉国内的外企格外强调下属的服从性，把这一点作为员工的基本职业素养来培训，常用来讲解的故事就是《把信送给加西亚》，强调上司安排一项工作以后，下属不允许谈任何条件，不允许challenge上司，必须无条件服从，克服一切困难也要完成工作任务，以解领导之忧。这种执行力正像胡宁所说，让上司感觉很舒服，而且公司管理实施难度也比较低：

• 公司的领导制订战略方向，管理层各负其责，KPI层层分解，层层落实；
• 一线员工只需要按部就班，听话服从即可，不需要一线员工提出问题和解决方案，只需要执行，避免了工作执行过程中的损耗；
• 工作效率虽然未必是最高的，但是保证了工作效率的可预测性和可重复性；
• 工作是以岗定人的，员工最好是不偏不倚的适应岗位需要，不多做也不少做，员工的可替换性强，降低人员流失风险；

但一昧过于强调下属服从可能是有害的

多年来无数成功实践证明这种企业文化是行之有效的，可能当公司规模增大到一定程度，或多或少都需要转变成这种管理模式，但这种企业文化并非没有问题，一昧过于强调下属服从，可能带来的问题有：

一、当下属内心并不认可工作本身，仅仅出于工作职业性完成工作，成绩最多是合格，很难达到卓越

我带团队，更希望看到下属是发自内心认可工作，能够从工作当中获得成就感和个人成长，而不仅仅只是为了拿一份工资糊口。只有这样员工才能尽可能的发挥自己最大的潜力，甚至超出我的预期；而不是由于被我拿着鞭子逼着去做，员工心里的想法也就是赶紧交差了事，不可能做出超出我预期的结果。

二、当下属过多被动接受上司工作指派，甚至是上司的上司越级临时性指派，实质上被剥夺了工作安排的主动性，只能被动等待任务，最后变成了牙膏，上司挤一下动一下，不挤就纹丝不动，没有上司安排好工作任务，就完全不知道自己该干什么了

我看到过很多挤牙膏式的员工，其中印象特别深刻的一个，他发年终奖的时候嫌我对他的KPI评估低了，他的理由是：我领导安排给我的工作任务都完成了，所以我的工作是优秀的。我对他说：你领导没有给你安排工作任务的时候你在干什么？我看到你上网聊天，网购打发时间，既没有给自己安排任何学习计划，也从来没有主动向领导要过任务。一年来你技术水平毫无提升，岗位责任毫无扩大，工作量毫无增加，工作从不主动，任务能推则推，原地踏步了一年，在团队当中工作表现最靠后，你还认为你的KPI是优秀？

如果团队里面都是这样的下属，上司非常累，事事都要自己亲力亲为，哪件事情不抓哪件事情就会出问题。这样的团队是做不出来优秀的事情的。

三、非常容易养成下属逃避责任的习惯，导致下属缺乏工作积极性主动性，凡事明哲保身

反正不需要我动脑筋了，领导说什么我就立刻做什么好了，做对了领导自然会肯定我，做错了，也是领导自己决策错误，我态度好没责任；领导不说的事情，我绝对不去做，做对了也未必是领导期望的，如果做错了，那更加是罪过了；如果领导决策本身是错的，我明知道不对，也要硬着头皮做，不然抗命做事，即使做对了，领导也会认为我工作态度不好，缺乏职业性，罪过就大了去了。

我不喜欢这种明哲保身，人人推卸责任的团队：没有任何下属敢给你提意见和想法，怕给自己惹麻烦；团队对你有疏离感，你根本不知道团队成员心里是怎么想的；如果你自己决策错了，根本不会有任何下属站出来纠正你，你会陷入孤军奋战的状态当中。

四、对于互联网行业，特别是面向消费者的互联网行业，最致命的问题是：员工到底是为谁做产品？是为了用户做产品？还是为了老板做产品？当员工凡事以服从上司为出发点，那用户在他心目中是无足轻重的，一旦上司决策错误，缺乏自我修复和纠正的能力

很多互联网产品都败在这个问题上了，上司要是天纵英才，下属三军用命，自然是无往而不利，但现实是上司不可能每个决策都是对的，如果决策错误，下属又不敢或者不愿意站出来纠正，最后必然失败。产品失败了，老板调整或者砍掉产品团队，最终为失败买单的还是员工。

伟大如乔布斯，最早决策iPad用Intel的CPU，时任苹果工程副总裁，iPod之父Tony Fadell拍桌子以辞职相要挟，要求乔布斯改用ARM的CPU，被乔布斯采纳。试想，如果没有Tony的抗命，iPad用的是Intel CPU，一定会落的和今天微软WindowsRT一样的下场：电池续航能力不足4小时，iPad还能有今天的成功吗？

很多互联网产品的负责人，过于强调下属的服从，非常在意维护自己的领导权威性，十分忌讳下属challenge自己，下属的态度就是唯上司马首是瞻，上司说的事情极其高效的完成，上司关注不到的地方，即使用户呼声很大，也毫不理睬，心里只有老板，而无用户；就算发现产品的问题，也不会和上司提，唯恐上司不爽，哄着上司开心。这样的产品本质上是做给老板用的，并不是做给用户的，那用户岂能买账？产品岂能成功？

要给下属challenge你的机会

我信奉的管理理念不是制造一个个笼子，把员工分门别类往里面放，或者实施一套管理方法学，强制要求所有人一丝不苟的遵循。我希望寻找到适合的人才，创造让人才能够充分发挥自己潜能的环境，搭建一个默契的、相互信任的、有战斗力的团队，激励每个人尽可能的为公司创造最大的价值。我认为，手段是为目的服务的，当你清晰的确定目标之后，并不需要拘泥于特定的手段，凡是可以达到激励团队目标的手段，都可以为我所用。

因此，尽管我从事IT行业15年，从传统软件工程到CMMI的实施，从推广敏捷软件开发方法到了解精益创业，全部都熟谙于心，但是我管理团队，从不对团队强制实施任何形式上的软件开发过程管理，比方说我对极限编程很熟悉，但从不要求团队必须结对编程，测试驱动开发，也不要求每日站立会议，但是当项目开发进入关键冲刺时期，我就会有选择性的使用一些特定的手段例如每日站立会议来加强项目控制。如果仅仅只是为了实施特定的软件开发方法，但忽视了背后本质的目的，无疑是舍本逐末的。

所以，我觉得作为上司，一定要鼓励下属积极主动的思考，让下属能够自己设定成长目标，对工作拥有归属感和责任感；尽量给予下属更自由的空间，不要设置过多形式主义的约束；要允许下属去challenge你，参与你的决策，甚至质疑你的决策。这样做的好处有很多：

一、下属对工作有归属感，工作责任心更强，更积极主动，能够自我驱动，这样上司就省心了

二、当你的决策错误的时候，下属可以帮你纠错，集体的智慧毕竟高于个人

我带的团队还是比较敢于challenge我的，至少我自己的感觉是这样，如果我提出的意见他们不同意，就会立刻在办公区当面说出来，不会有什么不好意思的，也不会非要刻意私下在办公室里面才敢说。而且事实上也确实会经常提出很多正确的意见，纠正了我很多想法。

三、当下属获得了更多的决策参与机会，成长的很快，往往一两年就可以独当一面了

我观察到有些下属就是这样的，一年时间就从普通的一线员工成长为核心骨干了。

当然，很多上司可能不喜欢下属challenge自己，更喜欢迎合自己的下属，总结来说无非几类心态：

一、害怕自己的权威被挑战

如果对团队的控制能力不够强的话，容易产生这种心态。如果下属恶意挑战或者人品有问题的话，应该及时换人；如果下属对工作责任心很强去挑战，应该更加宽容一些，并且尝试改变一些工作方式去适应下属。

我有一个下属就会时不时挑战我，我发现他之所以挑战我，原因在于他工作经验丰富，做事情逻辑性又比较强，当他发现任务存在不合理的地方，他就会提出自己的意见，说这个事情没有办法做，然后用很充分的理由让你无话可说，最后把任务给推掉。那么问题的本质不在他的工作态度上，而在于我给他安排工作是否考虑周全，是否真的合理？是否让他心服口服，这样就会迫使我在给他分配工作任务之前，必须考虑更周全，这样他就会很顺利的接受。

二、认为顺从的下属更好用

顺从的下属管理起来可能感觉上更舒服一些，但未必能够把事情做好。如果最终事情没有做好，做上司的不得不去擦屁股，谈何更好用呢？其实最好用的下属是那些和你在工作上进行了充分的磨合的团队，彼此非常了解，配合默契，沟通顺畅，可以毫无芥蒂的相你提意见，甚至反对你意见的下属。

我的直接下属很多跟我一起工作差不多都2-3年了，非常熟悉和默契，有意见就会提，我也不会强迫他们做事情，比较尊重他们自己的意愿，这样感觉配合就很好，工作更顺利一些。而且我个人比较喜欢能够独立提出自己想法，愿意主动去做有挑战工作的下属。

三、心态上高人一等，不会放低心态倾听下属的意见

做上司的一般都比下属能力更强，或者经验更丰富，做事情更老练，所以在下属面前，有相当强的心理优越感，同时上司为了维护自己的领导权威性，会端着更高的架子。这种心理优越感和等级差异形成的架子会造成一种障碍，让你无法真正放开自己的内心，倾听下属的意见。所以很多上司倾听下属意见的时候，总觉得下属想法幼稚，看问题角度太低，眼光不够高，先在自己心里把下属意见从战略高度给否了，然后再也不可能听得进去了，最后就会觉得太有想法的下属不好，还是听话执行力高的下属好。

我自己在这方面也很难免俗，有时候也会站在心理优越感的高度直接否定下属。但我还是希望能够不断提醒自己，再渺小的一线员工在工作当中也有值得认真倾听的意见。

四、害怕向下属认错，抹不开面子

有时候上司不喜欢下属challenge自己，很大程度上是面子挂不住，认为维护在下属面前的威信很重要，即使犯了错误，内心也意识到了，也想修正，但也坚决不开口向下属承认自己决策错误。我可能是草根创业出身，不太在乎面子，让我在下属面前认错，毫无心理障碍，张口就来。就一周多以前，我还向手下的一个研发团队认了错。

其实上司敢于向下属认错，敢于承担责任，能够真正修正错误，不但无损于自己的权威，更会获得下属的信任感。因为当事情出现了问题的时候，每个人心里都有一杆秤，不会因为你不承认错误而有所改变，反而会让下属对你积累怨言。当你勇敢的承认自己决策错误的时候，下属会打开一个心结，变得和你更无芥蒂，更敢于向你提出意见，更加信赖你。

下属challenge上司，结果会怎样？

下属challenge上司，有这么几种可能发生的情况，我下面列出来了：

• 上司听从了下属意见
  • 1) 最后结果证明下属意见对的：皆大欢喜！
  • 2) 最终结果证明下属意见错了：做上司的要承担责任，不应归咎给下属
• 上司驳回下属意见，并陈述理由
  • 下属接受并执行
    • 3) 最终结果证明上司意见是对的：皆大欢喜！
    • 4) 最终结果证明上司意见错了：上司应该向下属道歉
  • 下属非常坚持自己的意见
    • 5) 给下属按照自己意见尝试的机会，但要让下属清楚自己需要承担的责任
    • 6) 下属意见非常不靠谱，且没有试错的机会：上司强制要求下属必须服从

以上多个可能发生的分支条件，总共6种可能的结果，我经历过5种结果：

• 结果1和3是最常见的情况，一般都是这样的结果，这样的结果是最好的；
• 最近发生了一次结果2，出了点状况，我向公司承担了责任，向团队道了歉；
• 结果5很早以前发生过一次，下属非常坚持，我给了尝试机会，但失败了，我及时制止了；
• 结果6应该是作为上司极力避免发生的，我碰到过两次，下属最后都离职了；

所以，可见允许下属challenge上司，结果并不糟，即使是结果6，员工如果和上司非常合不来，离职并不是一件坏事，除了结果6，其他情况都是可以接受的，而且绝大多数情况下，都会带来很好的结果，不是吗？

您可能也喜欢：
robbin：大公司体制内创新的困境	从一个程序员笑话看软件开发管理	（转载）IT项目管理的六种错误思维	项目管理心得：一个项目经理的个人体会、经验总结	为什么老板要的是结果，却偏偏喜欢听过程
无觅

今年3月，盛大文学旗下起点中文网人事动荡，吴文辉以及起点创始团队成员离职，同时还有部分中层及核心编辑变动。作为盛大文学旗下最重要的资产之一，起点中文网的变动是起点与资方盛大之间矛盾的集中爆发。

上述人士透露，吴文辉等团队成员出走后，百度、腾讯等公司纷纷伸出橄榄枝。百度方面由于受到文库版权问题，对优质原创内容的需求尤为迫切，但是由于价格等原因，最终未能与吴文辉团队达成一致。

据悉，腾讯与吴文辉团队达成投资合作协议后，已经在内部发出邮件，通知腾讯即日起停止任何形式的男频内容签约，包括买断和分成。

吴文辉在与新浪科技连线时并未否认上述消息，但他表示：“在竞业禁止期间，不会对任何新工作动向做评价”。(爱文)

您可能也喜欢：
腾讯 vs 百度	马化腾内部邮件：腾讯全面无线化	腾讯：企鹅帝国的风雨路	“渐进式”腾讯产品的创新方式	开心网和腾讯将实现同步应用接入
无觅

博客今天开始继续更新

您可能也喜欢：
后天开始休假至3号，博客停止维护	如何在Google成为一名优秀的产品经理？	保持简单----纪念丹尼斯•里奇（Dennis Ritchie）	Browser和Server持续同步的几种方式（jQuery+tornado演示）	Python 代码性能优化技巧
无觅

原文链接： http://cdc.tencent.com/?p=7162

您可能也喜欢：
腾讯发布UIDesigner 2.0，软件原型设计工具	MongoDB 2.0.3 发布	Java ME SDK 3.0.5发布！	YUI 3.7.0 正式版发布，显著性能提升	新起点 新突破 ThinkPHP3.0正式版发布
无觅

原文链接： http://www.cnblogs.com/wly923/archive/2013/04/14/3019518.html

dbpath=D:\mongodb\test\replicaSet\A\Data
bind_ip=127.0.0.1
port=11111
replSet=replicademo/127.0.0.1:22222

dbpath=D:\mongodb\test\replicaSet\B\Data
bind_ip=127.0.0.1
port=22222
replSet=replicademo/127.0.0.1:11111

db.runCommand({"replSetInitiate":
    {
        "_id":'replicademo',
        "members":[
               {
                "_id":1,
                "host":"127.0.0.1:11111"
               },
               {
                "_id":2,
                "host":"127.0.0.1:22222"
               }
        ]
    }
})

replicademo:PRIMARY> use person
switched to db person
replicademo:PRIMARY> db.person.info.insert({name:"tom"})
replicademo:PRIMARY> db.person.info.find()
{ "_id" : ObjectId("516a629b91dee924cc38e01a"), "name" : "tom" }

replicademo:SECONDARY> use person
switched to db person
replicademo:SECONDARY> db.person.info.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }

您可能也喜欢：
华为NAT配置	基于LNMP平台web应用的LB集群，并将MySQL服务器独立出来	由一个问题到 Resin ClassLoader 的学习	不要复制别人的代码 自己敲出来！	什么时候学习编程都不晚
无觅