作者文章: Fenng

说说校园招聘这事儿

这段时间正是各大互联网公司校园招聘的高峰期,应该说,每一家具有一定规模的互联网公司都把每年一次的校园招聘当成一件大事而来抓,尤其是对人力资源部来说,更是大事儿中的大事儿。今年我已经投身创业公司,恐怕三两年内也不需要参加校园招聘这等大费周章的事情了,倒是可以说一些过去的感受,供同学们参考。

且先说两个来自 Twitter 的关于招聘的段子:

其一,据说某公司招聘,先把收集到的一大堆简历随机挑出一半扔掉,因为他们的招聘理念是 “不要运气不好的人” 。

其二,某 HR 说:校园招聘简历挑选法就是第一轮先把长得太寒碜的男生刷掉;第二轮,把长得太漂漂的女生刷掉;第三轮,再把星座和自己不和的刷掉。

且不说这两个段子真实性与否,但至少可以肯定的透漏出两个信息(尤其是对临近毕业的在校生来说):找到一份工作有很大的偶然性(运气成分)在里面,找到一份适合自己的工作则一定有其必然性;而对于招聘方来说,发出去的 Offer 信则是绝对有很大的随机性的事情。

要知道,每年的校园招聘,那些招聘人员风尘仆仆奔波几个城市的大学,还要起早贪黑的阅卷,忍饥挨饿的面试,负责联系面试的人力资源部门甚至连基本休息的时间都没有,所以有的同学收到夜半电话也是不足为奇的事情,面试官有的一天要面试数十人,需要相当有体力才能坚持下来。这种情况下,就意味着一定有疏漏发生,比如张冠李戴,比如阅卷的时候多给加了几分,或者是看着写字太烂把卷子扔掉(没错,字写得好机会都比别人多),比如想早点结束征程,所以,能拿到 Offer 的同学有很大一部分人应该先感到庆幸,要想想你找到这份工作的时候有多少人还奔波在各个面试考场呢。你真的是脱颖而出么?

的确有极少数的同学是相当优秀的,也就是那些能同时拿到几份 Offer 的人,暂且把这样的同学看做优秀吧,这类同学面对的问题是如何找到一个更为适合自己的工作,更能让自己有所施展的工作,这个选择或许比较难,但有一点,千万别因为钱而做出愚蠢的选择,你的第一位工作可能决定你以后的职业生涯,但你的第一份工资不会改变你的命运。能够做出正确的判断,要靠你自己平时多去留意一些业界信息,你得到的信息越多,你越有可能做出正确的判断。不要去和什么师兄师姐去比较,人和人是不一样的,尤其不要去比较薪水,这是最等而下之的事儿。听取建议的时候也最好不要只听来自师兄师姐的信息,其实他们自己也未必能搞清楚。考虑一下你做的事情能给社会带来多大的价值?你的能力能给你未来的雇主带来怎样的价值?你做的事情会给你怎样的回报(不只是工资)? ……

求职受挫的,不要气馁,不要去怨天尤人,那些顺利拿到 Offer 的人未必比你强到什么地方,但他们一定有些特质才会拿到好机会,而你,和周围的人相比,有什么长处与整个会场的数千人竞争呢?依靠运气是有可能找份工作,但如果没有经历过努力和挣扎,那运气未必在你这边。仔细分析一下自己,认清自己,有利于你做下一步的决断。

计算机专业的同学,我觉得求职竞争起码还算公平的,所谓”贫寒子弟无着落,富家儿女进机关,在校学业虽优秀,没有背景靠一边”的现象在这个行业少有发生。你选择别人还是别人选择你,这是要取决于你过去几年的积累与努力,取决于你是否是个有心人,所以我多希望是那些大二大三的同学也能看到这篇文章。是否花了更多时间去夯实基础知识,比如操作系统、算法、数据结构、计算机网络这些永远都用得着的知识,而不是只为了考试而学习;取决于你是否利用各种机会去获取业界信息。国内大学的这个垃圾教育网–局域网内的局域网–极大的限制了很多同学通过网络获取信息的途径,想起来就有些火大–有些扯远了,暂且不说。

对于招聘的随机性,记得自己说过一个玩笑话,我说这些学生随便站成一排,随机挑一堆带回公司按照既定的课程培养几个月,魔鬼训练之后,坚持下来的也能成为合格的工程师。这话或许没错,但很多公司看重的是候选人将来是否能融入公司的文化,是否契合某种感觉,是否是公司需要的那一类人,这才是他们眼里的”人才”,多数”人才”都是针对某类公司或者工种才是”人才”。比如做销售的,性能内向的人就很难吃的开,比如做数据的,太粗心的人也不成。所以,没被录取只能说你和这家公司不够契合,总结经验更为重要。也有的招聘人缘木求鱼,直接看这个人能否符合公司的价值观,这实际是候选人进入到公司后才应该考虑的问题。但是,当对方问你一些类似个性或是价值观相关问题的时候,你需要能传递出来一种信息,起码要能了解对方问你的是什么。比如,很多考官喜欢让你说说在大学里经历过的最有挑战的事情是什么?最简单的回答如果是:没有。这就话不投机了。

好吧,还是扣住”校园”来说吧,其实校园招聘是个成本相当高的事情,算下来,多数招聘团队在一个学校能人均招聘到一个毕业生就算不错的了。考虑到宣传和场地布置都是外包给那些专业招聘公司的,可以估算一下平均招聘一个人的成本如何了,这也是多数创业公司不希望采取的做法,这也是大家说的大公司”人才争夺战”,可谓你方唱罢我登场,不蒸(争)馒头也争口气 :) 也有些公司的校园招聘主要是出于宣传目的,比如 08 年经济危机来袭,有些公司在招聘会上根本不发 Offer ,让不少同学空等一场。

校园招聘,对很多公司或者很多人来说,是公司形象宣传会,是年底晋升的铺垫,是赚钱的好机会,是笔大生意即将来临……不过对于创业公司来说,则面临着一定的参与、操作难度,所以,采取吸引学生来实习的方式吸引人才,非常值得尝试,而且可以比较合理分配公司的资源–起码不用倾巢出动去招聘。对于临近毕业的同学来说,少了到处挤招聘会的困扰,可以专心利用这几个月多学习一些实际的东西,多锻炼一下自己,也是相当可取的。至少比参加什么北大青鸟之类的回炉培训要好得多吧。当然了,有些实习生实习期满也未必愿意留在这家公司,另攀高枝的事情常有发生,也要保持平常心才是:) 顺便说一下,我们团队近期实习生的招聘已经临近尾声了。

“临渊羡鱼,不如退而结网”。我接触过的一些同学,其实到毕业前至少还有几个月的时间,这几个月如果稍微专心一点,即使是自学,也完全能掌握一门可以混口饭吃的 IT 技能,可还是有很多人飘来荡去最后一筹莫展。诚可叹也。

以上只是我的一家之言,唠唠叨叨,博君一笑而已。

EOF

后记:想起我当初毕业求职的时候,给我机会的那位大姐来着,真该隔着互联网说声谢谢!工作后,我也曾给了不少同学同样的机会,甚至有和同事吵架争来的 Offer 机会,尽管他们有些人并不知道来龙去脉,也从来没跟我说声感谢 :)

Foursquare 长达 11 小时的宕机

今天是个值得庆贺的日子

前几天 Foursquare 经历了长达 11 个小时的宕机,没错,11 个小时。网站官方的解释是 Shard 负载不均匀造成后续的连锁反应。很多人都知道 Foursquare 在线的 DB 是 MongoDB,今天又看到 10gen (MongoDB的开发与支持团队)的 Eliot Horowitz 在得到 Foursquare 许可后,通过邮件组详细介绍了宕机的过程:Foursquare outage post mortem,不用说,也有为 MongoDB 辟谣的意味在里面。

读罢 10gen 团队的介绍(或者说解释)之后,发现这是一个很好的研究样本。值得分享。

为了提高响应速度,Foursquare 使用 MongoDB 存储 Check-in 的数据已经有一段时间了。这部分数据的数据库起初跑在一个 66GB 内存的 Amazon EC2 单实例上(全部在内存里),两个月前,出于对容量增长的考虑,迁移到两台 Shard 集群上。每个 Shard 机器都是 66GB 内存,为了冗余,每个 Shard 都有复制到 Slave 实例。迁移的目标是所有的 Check-in 数据都保存在内存中。数据根据 ID 分成 200 个 Shard 分片,两台机器各占一半,也就说联机数据在每台机器上各使用 33GB 的内存。两个月相安无事。

问题来了,因为 Shard 算法导致的数据分散不均衡,其中一台(Shard0)数据增长到 67GB(另外一台 50GB),超过了 66GB 的限制,读写部分分散到磁盘上,性能急剧下降。从而,网站宕机。

首先尝试增加第三台 Shard 机器,上线后开始迁移,读取从三台进行,Shard0 的数据迁移到 5% 的时候,但是写操作还是让 Shard0 宕机了。这个时候发现Shard0 存在数据碎片(data fragmentation),即使数据迁移走,还是会占用原来的内存。每个Check-in 文档大约占用 300 字节,而 MongoDB 是 4KB 的页(Page),也就说十几个文档会填满一个页,而迁移 5% 反而造成了页更加稀疏,并不是将页全部删除。

这个时候已经到了第二天,随着网站全面宕机,技术团队开始用 MongoDB 的 repairDatabase() 功能来对数据库进行压缩,因为数据库太大和 EBS 慢,也因为 repairDatabase() 不能充分利用多核CPU 的能力,这个过程耗费了 4 个小时。之后这 5% 的内存空间终于释放出来,系统重新上线。

随着 Shard0 修复,第三台成功上线,进而添加了更多的 Shard 服务器,现在数据已经更加的均衡,通过在Slave上运行 repairDatabase(),然后将其切换到 Master ,每台 Shard 内存占用缩减到 20GB左右。整个故障时间已经延续了 11 小时之多。

产生问题的主要原因就是系统过载,前面介绍每台 Shard 承载原来 50% 的压力,到了问题发生的时候,单台 Shard 的负载已经超过 Shard 之前的系统负载,这时候已经积重难返了,在容量的临界点增加新系统资源,必然导致更多的停机时间。暴露了 Foursquare 团队在容量规划方面的不足之处,或许也因为业务增长太快了吧。另外,内存碎片化的问题在没有宕机之前,技术团队应该没考虑过这个问题,如果文档的大小超过 4K,碎片化问题就不严重了,这是特定应用场景造成的特定问题。10Gen 现在已经着手研究如何进在线压缩(online compaction)。再次,Shard 键值的顺序和插入顺序是不同的,这造成了迁移数据的时候 Chunk 的迁移不是连续的。

这个过程给我们的启示是:最近 NoSQL 已经成为一个热词,类似 MongoDB 这样的新事物当然值得尝试,但是不能冒进,因为驾驭起来并非易事。仅仅能够使用是不够的,系统没出问题一切都好,一旦出了异常,有足够的技术力量(设想一下 Foursquare 得不到 10gen 团队的支持会如何?) 支持么?在极端情况下如何控制? 如果回答不了这个问题,那么还应该暂缓。最好的办法就是…”等待”。

给我的另一个感慨是 Amazon 在云计算领域已经真的成为一个赢家,而且越来越得到 Web 2.0 Startup的信赖。前面说的 66GB 内存,应该指的是EC2 的 “High-Memory Double Extra Large Instance”,可提供的最大内存是 68.4 GB 。CPU 和内存能力都是可以接受的,存储方面的性能似乎还有点不足,也就是其中的 EBS ,指的是 Amazon Elastic Block storage。

EOF

从 C10K 到 C500K

还在谈 C10K 的问题?这个已经过时了,现在大家已经开始说 C500K

国外的 Urban Airship 公司的工程师在其官方网志上发文章介绍他们在产品环境中做到 50 万并发客户端,Java + Pure NIO 的实现,最近又有文章介绍针对 Linux Kernel 调优的经验:Linux Kernel Tuning for C500k 。并且指出了”单个 IP 最大并发数量上限为64K” 只是一个误解。

硬件环境?操作系统为 Ubuntu(Lucid),租用 Amazon 的 EC2 ,使用 EC2 Large instances,64 位操作系统,每个 7.5 GB 内存。

当然,Urban Airship 是做手机消息 Push 服务的(Android Push 架构),所以,如果你也要做到这样的并发,还要看你的应用场景是否合适。去年了解到曾在新浪、腾讯任职的杨建已经做到超过 20 万的 HTTP 并发(现在可能已经突破这个限制了),非常的惊人。我非常想知道现在各个公司在这方面的实践数据。

EOF

另外参考:A Million-user Comet Application with Mochiweb

更新:杨建同学发来消息,去年已经单击突破 46.5万 Connections, 两块网卡, 1.5G 输出。10万请求处理每秒,每个响应 2k 左右。据说当时遇到一个坎一直没能过 50 万,不过这个坎三个月前已经过了,现在过 60 应该没悬念,四核双 CPU 机器。据杨建说,”按现在 4 Core * 4CPU 的机器,我觉得可以冲刺 80~100万,前提需要4块网卡(千兆)”。可见,把事情做到极致是没有极限的。

此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Facebook 针对 MySQL 开源 Online Schema Change 代码

有过 MySQL 使用经验的人应该知道,MySQL 要想在线修改个 Schema 结构是个麻烦事,规模不大的表增加个索引造成的锁也可能导致整个 Web 应用宕机。这一点没办法和 Oracle RDBMS 、DB2 等商业数据库相比,甚至 PostgreSQL 也具备联机 DML DDL 的能力。我在过去写过一系列并不成熟的《MySQL 大企业级应用可行性分析》 文章中,也很是担忧这个问题。有些公司想迁移到 MySQL ,也因此而只能采取保守的做法。

不过现在这个缺陷临近被彻底修复。Facebook 的数据库技术团队将 Online Schema Change (OSC) 的代码开源,并且撰文进行了详尽的阐述。这是个很大的技术革新,Facebook 数千台 MySQL 服务器在过去增加个索引需要几个月的滚动升级,现在只需要几天即可。

MySQL 5.1 的 InnoDB 引擎具备 Fast Index Creation 的功能,在创建索引的时候无需复制整个表的内容,但是对于一定规模的大表增加索引,仍然需要花费大量时间,对于在线应用来说,仍然不可忍受。而 Facebook 的 OSC 则进一步进行了改进。对于 MySQL DBA 来说,这是个福音。感谢 Facebook 的员工 Vamsi Ponnekanti 的工作。如果要我说,年度 MySQL DBA 应该授予给他。当然,Online Schema Change 的部分代码从 Shlomi Noach 的 Openark Kit 中派生,建议 Shlomi Noach 一同获奖…

对于 MySQL 来说,我认为这是个里程碑式的时刻,无论 Oracle 将给与 MySQL 多大的投入,其它公司已经主动拿过接力棒。Facebook 技术团队再次立功了!

EOF

Update: Facebook 工程师在帖子里说了”Note that the above operations can be done within the storage engine itself, or using an external (PHP) script.” 要知道,这并非只是一个 PHP 脚本的实现。我建议技术人员看帖子应该更仔细一些。也不要说这东西你早都想到了之类的技术阿Q的话,我倒现在为止没听到国内一个公司的技术人员做出来这东西。从想法到实现,其实还有十万八千零一公里呢。