February 2011 Archives

看到微博上和各种媒体总有人将阿里巴巴 B2B 平台上的欺诈和淘宝上的假货混为一谈。B2B 上查出 0.8% 的不良商家，有人进一步问淘宝假货不止 0.8% ... 这是一种什么逻辑呢？

如果不是贪图小便宜的话，在淘宝上买到假货的可能性是微乎其微的。淘宝上的所谓假货，更多的是 A 货仿品。通常说的淘宝假货，可能是根本不能用的伪劣产品（淘宝一经发现就处理），也可能是完全能用的仿造品，这是另外的话题了。

什么是欺诈？百度百科的解释是 "欺诈是指以事人发生错误认识为目的的故意行为。当事人由于他人的故意的错误陈述，发生认识上的错误而为意思表示，即构成因受欺诈而为的民事行为。"

淘宝的另一个伟大之处，是降低了消费品的成本，削弱了所谓"名牌"们的虚高价值。同样质量的东西，贴名牌标签几千块，A货一两百块，这是一场革命。尽管有些残酷。

上面这句话引发了不少质疑。所谓"革命"，都是有血腥的。可这就是发生了。这是用户在用鼠标做的投票。质疑的人都可以投反对票，在这个大潮中同样会被淹没，洪水是灾难，洪水退后会使得土地更加肥沃。

但 B2B 的问题是欺诈。所谓 0.8% 的商户，那是说这些人通过了阿里巴巴的认证体系（中国供应商、诚信通，这个体系是给阿里巴巴带来利润的），而这么多骗子卖家能进来，没人帮着做弊是不可能的。这真的动摇了阿里集团的价值观，是阿里巴巴整个集团赖以生存的东西，是底线。所以，马云必然会震怒。

(旁白：自鸦片战争以来，可能中国人和外国人打交道终于占了外国人的便宜，而且屡战屡胜，遗憾的是以欺诈这种下作的方式。另外，受骗的不止是外国人，中国人更多。)

某业内人士质疑 "CEO 和 COO 和 100 多销售人员都不理解马云价值观" ？这人应该不懂什么是价值观，价值观，理解容易，坚持下去则非常之难，尤其是面对利益诱惑的时候。阿里巴巴 CEO 和COO 等人是为了承担责任，而不是说没理解好价值观，基本的逻辑要搞懂，否则就真的管不好自己刚上市的公司了。

卫哲和这次波及的高层之前为什么不彻查骗子卖家？最可能的解释，一个是他们认为解决不掉，二来，因为这些卖家交钱给阿里，转身去骗买家，买家几乎不给阿里带来利润，卖家才是。卫哲和管理层为什么要做利润？股价才会好看。很多人会追求自己利益最大化，你应该懂的。

卫哲的做法是拍苍蝇，发现有受害者举报的就进行处理，也不排除会局部掩盖有苍蝇这个事实。人之常情。

供需合在一起才是整个生态，这个平衡不能打破。马云关心的肯定不是阿里巴巴的短期利益，所以，老马可以果断的设置纱窗，杜绝苍蝇继续往里面飞。纱窗是否也会有漏洞? 那是后话。

卫哲最大的失败不是在对待欺诈事情的处理上，而是 1688.com 突围无效，B2B 找不到下一个增长点。"无名良品" 看起来接下来也会是淘宝的产品，B2B 想拿也拿不走。

Alibaba 在上市后最应该做什么？不是"研发"新的产品，打通和淘宝的联系，而应该去做收购，大手笔的收购，整合。B2B 现有的几笔收购几乎都没什么成色。这个应该没有人提出异议吧？尝试摸索新产品的过程中，阿里巴巴 B2B 错过了外贸 B2C 这一块大蛋糕，也错失了可能的未来。

外贸 B2C 是能够讲出很好听的故事的，很遗憾，阿里动手 (AliExpress) 太晚了。

马云说，男人的胸怀是委屈撑大的。这句话后来被演绎成了"男人的胸怀是委屈撑大的，女人的也是"。一家处于风口浪尖的公司，所有的事情必然都有猜测和演绎。

卫哲的离职有其它原因么？也许有，也或许，他就是太累了。

[此为 Twitter @Fenng 上的辑录，稍作整理。旁观者的一家之言，媒体如引用，指明出处，禁止抄袭。请勿骂战。]

--EOF--

最近问答类网站相当的热门。说起问答(Question & Answer)网站，很多人会第一反应想起 Quora ，实际上，这类网站中 Quora 并非做的最好的(但或许是借了 Facebook 的风头)，最为成功的要数 Stack Overflow 。更为准确的说，是 Stack Exchange Network，Stack Overflow 现在只是 Stack Exchange network 的子站点而已。

Stack Overflow 由 Jeff Atwood 和 Joel Spolsky 这两个非常著名的 Blogger 在 2008 年月创建，7月小范围的进行 Beta 测试，直到 9 月份才开始公开的 Beta 测试。Joel Spolsky 大家应该熟悉，国内已经引进了他的数本大作，影响力最大的应该是《软件随想录》，此外，Joel 还拥有 Fog Creek 这家运转得不错的软件公司；Jeff Atwood 是著名技术技术 Blog Coding Horror 的作者。有趣的是，这两个人过去还 打过嘴仗。Stack Overflow 面向编程人员群体，在其推出一年之后，又推出了面向系统管理员的 Server Fault ，2009 年8月正式面向一般计算机用户的 Super User。用这个方式不断进行横向扩展，到现在为止， 旗下已经有 43 个问答站点，甚至包括英语和烹调这样的主题。到2010年年末，Stack Overflow 单个站点在 Alexa 的 Rank 是 160 ，月度独立访客超过 1600 万，每月Page View 超过 7200 万 (refer)。Stack Exchange Network 在 2010 年 5 月接受了来自 Union Square Ventures 的 600 万美元的投资，在 2010 年扩大并完善了整个团队，从三个全职工程师发展到了 20 多人的队伍，搬进了 7500 平房英尺的豪华装修的办公室（当然每个人都坐着1000美元一把的椅子）。从各项指标来看，同样作为 Startup，Quora 距离 Stack Overflow 的还差得很远，虽然拿到了更多的钱、吸引了更多眼球。

Stack Overflow 为什么会如此成功？

你当然可以说是众包(Crowdsourcing)的功劳，但哪一个成功的社区能少了众包的功劳呢？如果实际一点说，不可或缺的因素我想是两个创始人的技术和社区基因。作为两个著名的 Blogger，没有人会质疑 Joel 和 Jeff 在 目标用户(开发人员)需求的精准把握。何况在上线前后，Jeff 通过技术社群又进行了大量的调研和反馈（Joel 倒是似乎第一次做 Web 项目，Fog Creek 主要是软件开发)。此前市场上已经有 Experts-Exchange 之类的老牌产品，Stack Overflow 则反其道而行之(Anti-Experts-Exchange)，作为技术人员，你一定遇到过搜索技术问题到了 Experts-Exchange 网站，但是你发现问题下面并没有合适的解答，仅仅有人提问，但是没有有效的激励回答者则是没有价值的。Stack Overflow 参考 Reddit 等网站的用户激励机制，关注问题质量，其做法是通过威望值(Reputation Point) 与徽章(Badge) 建立起信任评价体系，并且做到对参与者的有效激励。我是否说过技术人员都是"好面子"的？没有，那么现在记住这句话吧。

此外，秉承独特的设计理念。Stack Overflow 绝对没有多余的或是跟风的功能(比如一些不必要的 Social Network 特性)。如果看过 Joel 的书或是订阅他的 Blog，你应该知道他是个相当偏执的家伙，尤其是在产品设计方面，他认为对的事情绝不会妥协，参见他在《软件随想录》中的《别给用户太多选择》以及《用软件搭建社区》等章节。我不知道究竟团队在功能设计上是怎么分工的，但 Joel 一定是毫无质疑的植入自己的设计理念。另外要补充的是，Stack Overflow 重新将"标签"化腐朽为神奇，也是相当值得称道的。

横向的业务扩展模式。与 Quora 综合性的问答不同的是，Stack Exchange network 采取攻其一点，再进攻其余的方式。在面向开发人员的 Stack Overflow 获得验证并且成功之后，向类似话题领域扩展；然后与不同团队进行合作，逐渐引入更多的主题（比如 Ubuntu、面向物理学的话题等等）。最后，如果把几十个话题合起来，恰好是一个庞大的 -- 论坛。Stack Overflow是否重新"改造"了论坛这个古老的交流模式？

技术？是个关键因素，但不是主要因素。作为 Startup，罕见的使用微软了技术体系进行开发，但也用开源软件。观察 Stack Overflow 所用的技术方案，会觉得是个大杂烩，除了 C# 、ASP.net 、SQL Server 等，也有 HAproxy、Redis 这些解决方案。 据 Joel 说，效率和成本也还不错。扩展模式上则首选 "Scale Up", 总之，就是有点特别。但是，用户体验相当好，这个是最难模仿的一个地方(另一个是运营套路)。

或许，Stack Overflow 的成功因素不止这些，你认为呢？

补充，来自霍炬 (@virushuo) 的观点：首先工具本身非要重要。有足够好和专注的工具。其次，种子用户非常重要。So，小范围测试的时候奠定了基础，之后始终按照这个确定的方向积累。

补充， Joel 的说法是"push for high-quality content and its decision to segment the service into well defined verticals"。

延伸参考：

• Stack Overflow Architecture
• Stack Overflow 架构(评论)
• Stack Exchange's Architecture in Bullet Points

--EOF--

按：这篇 How Facebook Ships Code 提供了大量的细节信息，之前已经有朋友提供了一个翻译版本，阅读之后发现有些许错误，并且原文有更新，所以基于前面的翻译版本我重新翻译了一个(完整的)版本。一并谢过。希望这个版本对大家也有所参考。

我对 Facebook 的运作方式着迷。这是个非常独特的环境，很难被复制（这个方式并不适合所有的公司，即使有些公司尝试过这么做）。下面这些笔记来自我和Facebook的许多朋友的交谈，关于他们开发、运维与软件发布等方面。

好像很多人都对 Facebook 感兴趣... 这家公司的工程师驱动文化(Developer-driven culture)已经被公众大加研究，并且其它其它公司也在探求是否/如何实现工程师驱动文化。Facebook 的内部流程实在够神秘，当然，工程师团队也会发布一些关于新功能以及部分内部系统公开备忘，不过这些大多数是"说明"类的文章(What)，而非讲述"机制"(How)... 所以，外部人员很难明白 Facebook 的创新以及如何比其它公司做到更有效的对服务进行优化。我作为外部人员尝试深入理解 Facebook 的运作，汇集了几个月来的这些观察信息。出于对信息来源的隐私保护，我去掉了特定功能/产品的名字。我又等了6个月以后才发布这些记录，所以，有些信息肯定过时了。我希望发布这些信息会有助于了解 Facebook 的管理机制如何在组织中进行决策的推行而非逐步陷入混轮...很难说这与 Facebook 的成败或是 Facebook 的产品协作相关。我相信很多面向消费者的互联网公司会从 Facebook 这个案例受益。

*非常*感谢那些帮助我整理这篇文章的 Facebook 内部的朋友们。也要感谢项 epriest 和 fryfrog 这样的朋友，他们协助我进行对本文进行校正、编辑。

记录：

• 截止到2010年6月，Facebook有将近2000名员工，10个月前只有大约1100人，一年之间差不多翻了一番!

• 工程部和运维部是两个最大的部门，每个大概都有 400-500人。这两个部门人数大约占了公司的一半。

• 产品经理(PM)与工程师的比例大约为1-7到1-10。

• 每个工程师入职时，都要接受 4 到 6 周的 "Boot Camp" 培训，通过修复Bug 和听更资深的工程师的课程来熟悉 Facebook 系统。每次 Boot Camp 大约有 10% 的人无法完成课程而被淘汰。

• 培训结束后，每个工程师都可以访问线上的数据库【标准课程"能力越大，责任越大" ( "with great power comes great responsibility") 对此有阐释，另有一份明晰的"不可触犯的天条"，比如共享用户的隐私数据】。

• [修改, 感谢 fryfrog] "Facebook 有非常牢靠的安全保障，以免有人（你可以想象内部有人有这个权限的）不小心/故意做了些糟糕的的事。如果你已经"成为"了需要别人支持的人，事由将被记录，并且有谨慎的审计。这里不允许钻空子。

• 任何工程师都可以修改Facebook的代码库，签入(Check-in)代码。
• 浓厚的工程师驱动文化。"产品经理基本可以被忽略"，这是Facebook一名员工的话。工程师可以修改流程的细节，重新安排工作任务，随时植入自己的想法。[评论] "本文的作者是一个产品经理，所以这个论断引起里我的注意。你看完整篇文章后会发现，很显然，Facebook 的文化实际上是拥抱产品经理的实践的，所以，不是产品经理的角色被忽略，而是，这家公司的文化看上去是想让"每个人"感受到对产品的责任"。

• 在每月的跨部门会议上，由工程师来汇报工作进度，市场部和产品经理会出席会议，也可以做些简短的发言，但如果长篇大论的话，将如实反馈给他们的主管，"产品人员在上次会议说的太多"。他们确实想让工程师来主导产品的开发，对自己的产品负责。

• 项目需要的资源都是自发征集的：

• 某个产品经理把工程师们召集起来，让他们对自己的想法产生兴趣。
• 工程师们决定开发那些让他们感兴趣的特性。
• 工程师跟他们的经理说："我下周想开发这5个新特性"。
• 经理会让工程师独立开发，可能有时会让他优先完成一些特性。
• 工程师独立完成所有的特性 -- 前端 JavaScript/后端数据库，等等所有相关的部分。如果需要得到设计人员的帮助，需要先让设计人员对你的想法产生兴趣(专职的设计师很少)。请架构师帮忙也是如此。但总体来说，工程师要独立完成所有的任务。

• 对于某个特性是否值得开发的争执，通常是这么解决的：花一个星期的时间实现，并在小部分用户中(如1%的内华达的用户)进行测试。

• 工程师通常乐衷致力于架构、扩展性以及解决"难题"，那样能获得声望和尊敬。他们很难对前端项目或用户界面产生太大的兴趣。这跟其他业务为导向的公司可能正好相反，那些公司人人都想做客户能直接接触到的东西，然后会指着某个特定的用户体验说，"那是我做的"。在 Facebook，后端的东西，比如 News Feed 算法、广告投放算法、Memcache 优化等等，是工程师真正倾慕的项目。

• News Feed 因为太重要了，扎克会亲自审查任何变动。这是个特例。

• [更正, 感谢 epriest ]"所有的代码变更都要经过强制性的代码审查（比如一个或者多个工程师）。我相信这篇文章只是说 扎克并不自己审查每一个变更"。

• [更正, 感谢 fryfrog ]"所有的修改至少要被一个人审查，而且这个系统可以让任何人很方便地审核其他人的代码，即使你没有邀请他。提交未经审查的代码，将被视为恶意行为"。

• 工程师负责测试、Bug 修复以及启动对自己项目的维护。有单元测试和集成测试的框架可用，但很少使用。

• [更正, 感谢 fryfrog ] "补充一下，我们是有 QA 的，只是没有正式的 QA 组而已。每个办公室或通过VPN连接的员工会使用下一版的 Facebook，这个版本的 Facebook 会经常更新，通常比公开的早 1-12 小时。所有的员工被强烈建议提交 Bug，而且通常会很快被修复"。

• 回复：很奇怪只有很少的 QA 或自动测试 -- "大部分工程师都能写出基本没有bug的代码，只是在其他公司他们不需要这么做。如果有 QA 部门，他们只要把代码写完，扔给他们就行了" [编辑：请注意这是很主观的，我选择包括这部分内容是因为这和那些其它公司的标准开发实践完全相反]

• 回复：很奇怪，缺少产品经理的影响和控制 -- 产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的管理者搞好关系。需要大致了解技术，不要提一些愚蠢的想法。

• 默认情况下，所有提交的代码每打包一次（周二）。

• 只要多一分努力，终于一天会发生改变。

• 星期二的代码发布，需要所有提交过代码的工程师在场。

• 发布开始前，工程师必须在一个特定的 IRC 频道上候命，否则将会被公开问责。

• 运维团队通过逐步滚动的方式进行代码发布：

• Facebook 有大约 60000 台服务器。
• 有9个代码发布级别。
• [更正 感谢 eriest] "九个级别并非同轴的(concentric)。有三个同轴的阶段(p1=内部发布, p2=小范围外部发布, p3=完整的外部发布)，其余六个阶段是辅助层，比如内部工具、视频上传主机等等"。
• 最小的级别只有6台服务器。
• 比如，星期二的代码发布会先发布到 6 台服务器上（第一级），运维组会观测这 6 台服务器，保证代码正常工作，然后再提交到下一级。
• 如果发布出现了问题（如报错等等），那么就停止下一级的部署，提交出错代码的工程师负责修复问题，然后从头继续发布。
• 所以一次发布可能会经历几次重复：1-2-3-修复，回到 1， 1-2-3-4-5-修复， 回到1， 1-2-3-4-5-6-7-8-9。

• 运维团队受过严格训练，很受尊敬，而且极具有业务意识。他们的工作指标不止包括分析错误日志，负载和内存使用状态等等，还包括用户行为。比如，如果一个新的发布导致一定比例的用户对 Facebook 功能进行声讨，运维团队将查看相关指标，可能基于他们的调查停掉该次发布。

• 在发布过程中，运维组使用基于 IRC 的通知系统，可以通过 Facebook、Email、IRC、IM SMS 通知每一个工程师，如果需要他们注意的话。对运维组不做回应会被公开问责。

• 代码一旦发布到第9级，并且稳定运行，本周的发布宣告结束 。

• 如果一个特性没有按时完成，也没什么大不了的(除非外部依赖严重)，下次完成时一并发布即可。

• 如果被 SVN-blamed(应该指没按照规范提交代码会受到的惩罚)、公开问责(Public shamed, 示众？还是通告批评？）或工作经常疏忽就很可能被开除。"这是一个高效的文化"。不够高效或者不够聪明的员工会被剔除。管理层会在 6 个月的时间里观察你表现，"你不能适应这种文化，只能说再见"。每一级都是这个待遇，即使是 C 级别和 VP 级别，如果不够高效，也会被开除。

• [更正, 感谢 epriest ] "人们不会因为导致 Bug 而被解雇，只有在发布他们的代码时导致问题，而他们恰恰又不在场（也找不到其他可以替代的人）"。

• [更正, 感谢 epriest] "被问责不会导致解雇。我们特别尊重别人，原谅别人。大部分高级工程师都或多或少犯过一些严重的错误，包括我。但没有人因此被解雇"。

• [更正, 感谢 fryfrog] "我也没有遇到过因为上面提到过的犯错而被解雇。我知道有人不小心将整个网站宕掉过。一旦有人犯错，他们会竭尽全力修复问题，也让其他人得到了教训。就我来看，这种公然蒙羞与被解雇的恐惧相比更为奏效"。

分析 Facebook 的研发文化如何随着时间演化是件非常有趣的事。特别是当公司发展壮大到数千员工的时候，这种文化是否还能够延续？

你觉得如何？在你公司里，"开发者驱动(developer-driven)文化" 将会可行么？

译者后记：很多时候是管中窥豹也是非常有趣的，而且，应该细致一点儿。另外，或许我们更应该关注为什么 Facebook 能够形成这样的文化。你说呢？

译者后记续：Facebook 能形成工程师主导的文化，应该和 Facebook 的产品形态有很大关系。毕竟 Facebook 人人都会用 Facebook ... 换言之，如果是 Amazon / eBay 这样面向商业的用户的公司，业务逻辑会让工程师陷入五里雾中。

--EOF--

延伸阅读：Hacker News: What I Learned from Zuckerberg's Mistakes