可以装一个 CI 服务器，然后不同的 slave

这样就可以在不同的 slave 上编译了

这个组合不错

不错的文章，学习学习

有多少人用过 UrbanCode 的产品？

因为只是增量打补丁，而不是全量覆盖。所以 “各种路径” 必须要弄明白，且每次都要细致的整理好，以防弄错

能否用 vpn ？

这应该是个猎头公司，在给其他公司找人

Release engineering and push karma: Chuck Rossi by Chuck Rossi for Facebook Engineering (Notes) on Thursday, April 5, 2012

Facebook updates the site with new features, product improvements, and bug fixes every work day. This can sometimes be a huge challenge, given that there are hundreds of engineers working on thousands of changes every week, and many of those changes immediately impact the over 800 million people using Facebook worldwide. But Chuck Rossi, who has worked in release engineering for over 20 years and started as Facebook's very first release engineer in 2008, helps make it all happen. Read on to learn about the team behind the daily push and the tools and processes they built to make it possible.

Q: How did a daily push become part of Facebook's engineering culture?
A: It's something that grew out of the way Mark and the early engineers set things up—a very lightweight process that allows us to iterate quickly to get new features out. While there have certainly been some bumps, I'm very proud of the fact that we've built a system that supports so many changes on such a large scale.

Q: How do you keep things moving fast as the company grows? A: When I came to Facebook in 2008, I was the only release engineer. Now that the company is so much bigger, my small team and I are focused on how we can maintain the culture and the tools that let us operate as quickly and efficiently as possible. Every day, we're trying to answer the question, "How can we move faster?" This means expanding the role of release engineering, improving and expanding the test automation systems, and increasing push frequency.

We do these things because engineers build really quickly here. I don't want my systems to be a bottleneck or a hindrance, but at the same time, I want to manage risk so that people using the site have the best experience possible. No one should have to deal with down time or silly bugs. To assess how risky changes might be at a very meta level, I can look at how big a diff is and how much discussion there has been around it. There are also stars that indicate an engineer's push karma. Everyone is born with 4 stars, and you can only go down from there. People with low push karma have a higher bar to get into the daily push.

Q: How do you gear up for the daily push? A: I have a secret weapon to battle the tough commuting conditions here in Silicon Valley, so I'm usually at work by 8:45 a.m. I use this time to get things organized, fight any fires with my infrastructure, or work on any open tasks I have. Some days I give two different onboarding classes for new engineers, which is something I enjoy. I think my onboarding sessions are critical because I really try to instill the company culture of being responsible for your changes from beginning to end. From the time they check their code into our source base until it's out in front of their moms, our engineers understand that they're the ones who need to make sure it works.

Starting around 1 p.m., I switch over to "operations mode" and work with my team to get ready to launch the changes that are going out to facebook.com that day. This is the more stressful part of the job and really relies on my team's judgement and past experience. We work to make sure that everyone who has changes going out is accounted for and is actively testing and supporting their changes. We look for anything that might introduce risk so we can pay more attention to those areas during the release. It's like playing air traffic controller—a lot of things are in the air and trying to land at once. And they're all important.

If everything looks good and our test dashboards and canary tests are green, we push the big red button and the entire facebook.com server fleet gets the new code delivered. Within 20 minutes, thousands and thousands of machines are up on new code with no visible impact to the people using the site.

Q: What about the dev process at Facebook lets you get stuff done? A: I live and die by the developer and operations tools we've built here. We've been really aggressive about automating as much ofthe dev and deploy environments as possible. Because of that, I'm able to get significant changes out to facebook.com every day.

Q: Why do you come to work in the morning? A: I can't get over the impact that Facebook has had on the world. Since I've started here, I've taken the quality of people's experiences on the site very personally. I want everyone to experience Facebook as a solid, reliable service. If something doesn't go as planned, I document what happened and we do a postmortem to figure out how we got into that situation and how we'll improve to make sure it doesn't happen again. I'm also compelled by the impact I have as an engineer here, mainly knowing that on the other side of my 'Enter' key (on an old IBM keyboard my wife gave me for my birthday 14 years ago), there are thousands of machines and more than 845 million people who will be affected by the actions I take.

Q: What advice do you have for other engineers? A: Ship early and ship often. But tell the releng team what you're doing—we hate surprises.

To learn more about Chuck and the Release Engineering team, check out his tech talk here and watch him do a live push here and watch a live push here.

http://www.facebook.com/note.php?note_id=10150660826788920

再学习一遍

Facebook Facebook 的面试机会同样是同学推荐获得的，这也是这次求职经历中走得最远的一次。正如 Cat 在他的面经中所述，Facebook 的 HR 邮件回复非常及时，而且经常在非工作时间回复，整个过程中非常认真负责，不得不赞一下。Facebook 的第一轮电话面试是由 HR 进行的，时间是 Amazon 第一轮电话面试的第二天早上，而 Amazon 第二轮电话面试那天，Facebook 方面已经进行到委托旅行社替我安排 onsite 行程的阶段了，其工作效率可见一斑。

HR 电话面试

之前从 Cat 的面经中看到 Facebook 会在 HR 面的时候问一些基础的问题，并留一道作业题。但我的 HR 面试却只问了过去的工作背景。后来了解到 Cat 所说的情况是前端工程师招聘流程特有的，而我申请的是 Infrastructure 组，就没有这一环节了。如前所述，Facebook HR 面的前一天就是 Amazon 的第一次电话面试，有了前一天沟通不畅的教训，面试前我将想得到的问题和之前的工作背景等信息全部写了下来，实践证明非常有效。对方了解到我有管理经验但仍然希望做一线工程师之后似乎很满意（这确实是我的真实意愿）。末了约定了下一次电话面试的时间。这次面试进行了大约半个小时，就沟通顺畅程度而言比 Amazon 的第一次电话面试要好多了。

技术电话面试

接下来的电话面试是技术面，面试官是位女性，看名字觉得是中国人，事后果然在 LinkedIn 上查到是毕业于交大的同龄人，仰慕。虽然面试官是中国人，但仍然是用英语交流的，因为语言沟通能力本身也是考察环节之一。此外，由于这是该面试官的初次面试，还有一人旁听。一上来仍然是简单介绍下背景，介绍期间面试官通过邮件将 CollabEdit 上面试用的白板地址发送给我。点开之后 CollabEdit 戏剧性地报出 500 Server Internal Error。然后面试官似乎比我还要手足无措，经旁听的工程师指点后转战 Stypi 继续面试。第一题要求解释下大端序、小端序，并写个函数判断本地字节序，秒杀。然后是一道二叉树相关的题，写了一个递归版本，途中犯了一个小错误，经提示后纠正；通过后面试官要求再写一个迭代版本，写了一半有点卡壳，面试官提醒了两次我都没能走上正轨，直至面试时间结束。

面完之后比较郁闷，因为那道题并不难。结果如厕时猛然意识到之前错在哪里——马桶和浴缸果然是灵感迸发的绝佳场所……由于面试过程中面试官曾给我发过一封邮件，我就迅速回复了一封邮件，给出了一份带有测试用例的可编译的代码。之后面试官很礼貌地回信说这是她第一次面试，我在面试时给出的解法和她熟悉的套路不一样，因此不知道该如何提示和引导，同时表明已在面试反馈中建议再找一名更为资深的工程师对我进行面试，“可能” 还会有一次机会，并祝我好运。

之后便是焦急地等待。求职过程进行到这个时候，Google 方面已经被拒，Amazon 的第一次电话面试让我很沮丧，Facebook 的这次面试前景似乎也很黯淡。等了好几天没有回音，一度令我很是消沉，每天只是默默地在 LeetCode 上切题。不想临近春节，Facebook 的 HR 发来邮件预约第二次技术电话面试，没多久 Amazon 的 HR 也发来面试预约邮件，师弟@mikeandmore2又通过邮件帮我引荐了 AeroFS 的一位创始人（AeroFS 是一家 YC 投资的做 P2P 文件同步/共享的 startup）。这大概就是所谓绝处逢生吧……

Facebook 第二次技术电话面试的面试官仍然是中国人。走到这一步，之前的训练效果开始显现，基本上找到快速搞定这类入门级算法题的窍门和感觉了。这一轮面试也比较顺，和之后进行的 Amazon 第二次电面类似，四十五分钟连切三题，第三题也是因为时间关系只需讲思路。面试官听上去比较满意。面完之后很兴奋，心想这下至少能去 Menlo Park 溜达一圈了，就算面试没通过，也权当是参加电话竞猜中了个加州三日游了——没想到最后真被我乌鸦嘴说中，唉！第二天便收到了 HR 的 onsite 邀请，然后便开始办签证。

签证

Cat 曾经在某群内说过一句话，大致是说 “某些人整天说要出国，却连个旅游签证都不肯办”。好吧，看到这句话的时候我就有种躺枪的感觉——此前我还从未办过签证。收到 onsite 邀请时已经是二月中旬，为了赶上 4 月 1 日的 H1B 申请，HR 敦促我务必尽快完成面试。收到 Facebook 用于办理 B1 商务签证的邀请函后，紧张的签证准备工作就开始了：准备材料、填写 DS160 表格、预约面签，各种头大，按下不表。

非常幸运的是，我预约到一个非常近的面试时间，这样一来三月初便可以抵达 Menlo Park。由于去年八月份已于百度离职，我不禁担心会否因为当前没有雇主而导致面签被拒。为此，准备了户口本、结婚证、过往聘用合同、银行交易记录、学位证、毕业证等林林总总一大堆材料。不想面签当天这些材料一份都没有用到，美女面试官只询问了赴美目的和我所申请的职位的工作地点，期间在电脑上确认了一下我之前的工作经历，末了微笑着说了一句 “Good luck” 便放行了，整个过程不到 30 秒，连 Facebook 的邀请函都没有看。

Onsite

HR 告知海外候选人的 onsite 面试一般安排成周五出发周一面试，中间隔一个周末，以便休息和倒时差，同时也尽量减少在职候选人请假的天数。我的 onsite 时间表也是如此。这个安排还是比较人性化的。不过事实证明短短一个周末是绝对倒不过来 16 个小时的时差——在美期间每天夜里都清醒得跟打了鸡血一样，完全没有睡意，以至于面试前一晚我只睡了不到四个小时，周一五场面试狂灌了四杯咖啡。今后再参加海外 onsite 恐怕得提前一个礼拜在家就开始倒时差才行。

Onsite 前后，HR 和负责协调旅社的 Facebook 工作人员都十分尽责，提供的信息十分详细。预订的酒店就是 Cat 面经中提到的 Sheraton Palo Alto，地理位置极佳；缺点是网络龟速，恍如置身墙内，当时心想要是全美都这么个破网速，肉身翻墙又为哪般？

由于 onsite 是在总部进行，事先要签署一份 NDA 协议。协议内容十分严格，其中规定在面试期间获悉的任何 information 都属于保密范畴，所以我只会拣 GlassDoor 上涉及到的内容来写，面试中问答环节的内容就略过不提了（Facebook 方面曾发邮件说欢迎到 GlassDoor 上写面经，所以这样做应该是安全的）。

Sheraton Palo Alto 到 Facebook 总部大约 20 分钟车程。面试当天早上在酒店门口打车过去，在前台签到时大约是 9:30，然后便是静候 HR。期间连入 Facebook 的访客用无线网络上了会儿网，这才总算找回了对美帝网速的信心。十点钟帅哥 HR 准时现身，一番寒暄后便带我简单逛了一下园区，灌了杯咖啡。其中我最口水的是站立办公用的桌子和超大的显示器。其他细节各种面经都有介绍，按下不表。

面试在一个小号会议室进行，两面墙上都有答题用的白板。面试开始前，HR 先介绍了各轮面试的内容和顺序。面试官分三种角色：

Ninja（忍者）：面 coding，白板写代码； Jedi（星战里的绝地武士）：面文化内容，诸如个人兴趣、职业规划等务虚内容； Pirate（海盗）：面系统设计。 我的面试安排是上午一轮 ninja、一轮 jedi 加 ninja、一轮 pirate，下午两轮 ninja。每轮 45 分钟。

第一轮 ninja 是个华人面试官。一共两道题，第一题先写出了一个正确但不太高效的解法；优化了一会儿，面试官勉强满意，进入第二题。第二题是道完全没见过的图论题，面试官题目描述到一半的时候我自以为想出一个很简单的做法，于是迅速说了思路，结果面试官也迅速给出了一个反例……来回两次之后面试官告诉我此路不通，挣扎了一会儿仍然没思路，最后终于时间到，不得不放弃。事后发现也是个经典问题，做不出来纯属复习不到位。这也是之前过于依赖 LeetCode 的恶果——LeetCode 上的题目类型较窄，很多方面没有覆盖到。

第二轮是 jedi 加 ninja，有两个面试官，一个负责面试，一个见习旁听。一上来先是 jedi 角色，聊了大约二十分钟，还算比较投机。余下的时间做了道题，一次性顺利通过。末了提问环节的时候聊到园区内各种涂鸦，顺手在白板上给旁听的面试官画了个漫画像（那位是光头，好画……）。

第三轮开始之前有十分钟中场休息时间，HR 再次现身，又带我转了一圈，再灌一杯咖啡（困啊）。然后发生了一件比较坑爹的事情——面试官放鸽子了。我们回到会议室后，面试官并没有按时出现。又等了两分钟，HR 出去打了个电话，叽哩咕噜了一会儿，然后一脸郁闷地骂了句 “fuck”。原来面试官搞错了时间表，接电话时人还在家里……好在 HR 快速找到一位临时面试官，得以继续面试。虽然面试开始时间比预订时间晚了十五分钟，但这位临时面试官的表现却很专业。面完之后我自我感觉还不错。但事后才知道这一轮我的表现并不太好。原因有两个：第一，这是我这次求职过程中的第一轮也是唯一一轮系统设计面试，没有经验；第二，想太多了，一上来就往大数据上去想，从磁盘存储着手，没有及时发现面试官给出的数据量完全可以放入内存，面试官提示了几次才发现想复杂了（明明以前自己当面试官的时候还给候选人下过这个套的说）。

之后便是午餐。按惯例是由推荐人领候选人去餐厅，如果推荐人不在或没有推荐人，则由 HR 领去餐厅。我的推荐人当时正在国内，我本以为 HR 会过来，没想到发现 Cat 等在会议室门口。原来 HR 根据我简历上的背景资料给公司内可能认识我的人群发了邮件，希望找到熟人陪我吃午饭，而 Cat 在最后一分钟发现了这封邮件。由于我的日程是面试完毕后立即回国，没有时间游玩，所以事前基本没有通知在加州的同学和朋友，能见到熟人实在是意料之外的惊喜，让我对 Facebook 招聘工作的印象再次大大加分。午饭前后各一杯咖啡下肚，Cat 又带我略逛了下园区，期间聊得十分愉快，感谢感谢！

下午是接连两轮 ninja。第一轮是个欧洲口音的美女面试官。第一道题在第二轮电话面试中问过，告知之后换了一道，结果悲剧地卡在这道题上。题目本身不难，我也有思路。写到一半的时候面试官说这个算法占得空间太多，不够好，于是我试图按照她的思路走，结果自己没太想清楚，越走越绕，小错不断。眼看时间所剩无几，决定还是按照我原先的思路来，好歹先解出来，好坏再说。最后磕磕绊绊总算写出来。但这一轮只做了这么一道题，显然不理想。最后一轮又是两个面试官，一个主导一个旁听。这一轮的状况跟第二轮电话面试时差不多，非常顺，45 分钟切了三道题，而且都写出了完整的代码。

第五轮结束后面试官直接将我送出了园区。本以为 HR 还会出现，打算再次道谢（整个招聘过程中他的工作确实非常出色），但最后没有见到。上午面试官放鸽子前就看他一副神色匆匆状，估计其他事情也忙得够呛。当时我还没有意识到上午最后一轮系统设计面试的评价不够高，心想除了上下午第一轮表现不好以外，其余三轮还不错，应该有胜算，于是心情还不错。

事后和 Cat 交流时了解到，一般 onsite 面试只安排四轮，如果四轮表现模棱两可，最后会加面一轮。但我的五轮面试是一早就确定好的，这点比较奇怪。我猜有可能是因为第一轮电话面试的结论比较模糊的缘故。

拒信

不知道是不是因为时差导致神智不清，我居然将机票上的出发时间 1200PM 错看成 200PM，然后华丽丽地以误机画上了个人第一次国际旅行的句号……还好改签免费，不然可就亏大了（来回机票、住宿、餐饮、地面交通费用都是由 Facebook 报销的）。精疲力尽地回到北京之后，首都机场的 Wifi 死活连不上，回到家里立即查收邮件，于是就收到了拒信。不由得埋怨 Facebook 招聘工作未免太过高效了吧，各位面试官要不要再慎重考虑下啊？（哭……）不得不说当时还是相当沮丧的。HR 在邮件中说可以另约时间沟通一下面试反馈的细节。考虑到 onsite 期间这位 HR 似乎工作非常繁忙，出于节约对方时间的考虑，回复邮件时我附上了一份用 Google Docs 做的在线问卷，其中列出了所有想问的问题，并尽量安排成了选择题的形式。同时，考虑到某些问题可能不方便作答，所有问题都设置成了选答题。

之后，不光收到了 HR 对问卷的答复，还收到了 onsite 面试官的反馈细节。由此我才得知系统设计面的反馈不佳。此外 jedi 面的反馈似乎很好，看来就算换了门语言，嘴皮子功夫也还是过得去的。总之，在决定性的面试官投票中我以一票之差落选。

小结

Facebook 的面试从头到尾都如 Cat 所说的那样，没有高难度的题目，完全看基础是否足够扎实。我在电面和 onsite 面中出的状况全都是自己复习不到位或不够熟练所致。即便是系统设计题，也几乎不需要什么工作经验，我的感觉是比较优秀的应届生也不会有什么大问题，想得太多反倒容易栽跟头。

此外，如果不是 Amazon 反馈过晚，我应该还会在湾区再待上一两周，这样的话也许还来得及再争取一两家 onsite 面试机会。当然，Facebook onsite 结束后我再次抱着侥幸心理盲目自信，没有下决心改签机票同样罪不可恕……

事后 Facebook 又发了一份在线调查问卷，对面试体验做调查，末了还提供了一份礼品清单，T 恤、帽子、鼠标、记事本等等任选一样。总之从头到尾 Facebook 的招聘工作给我的感觉都很好，无论是工作质量、效率，还是人文关怀，都做得非常到位甚至超出预期。

后记 从最早萌生人肉翻墙的念头，到亲身实践一遍，再到机会擦身而过，感慨良多。不过，至少这次的经历证明了自己虽然功力还不够，但也差得不太多。我尚未放弃，准备充分之后还会再试一次。面试是个经验活儿。此次求职经历中，第一次电话面试、第一次跟老外交流、第一次系统设计面试等等，都表现不佳。此前虽然当了无数次面试官，面人没有一百也有几十，但轮到自己以候选人身份经历的求职面试却只有一次。如果之前不那么犹豫不决，在试 Google 之前多试几家积攒经验，结果可能就完全不一样了。

最后，跟同样有意向通过找工作翻墙的朋友们说一句：翻墙的可行性其实很高，只要技术和英语这两个硬指标过关，且家人不反对，再加上胆大心细，就很有希望。可惜我的例子不足以鼓舞人心，只能写点流水帐供大家参考罢了。

这篇面经欠了将近一个月，一方面是因为求职不顺心生懒散，一方面是 blog 主机服务商接连故障，前两天才完全恢复。今日终于把欠债补上了。

本文基于署名 2.5 中国大陆许可协议发布，欢迎转载，演绎或用于商业目的，但是必须保留本文的署名连城 (Lian, Cheng)（包含本文链接）。如您有任何疑问或者授权方面的协商，请联系我。 Share on facebook Share on twitter Share on google_plusone_share Share on delicious Share on digg Share on reddit Share on sinaweibo More Sharing Services 33 « 译：复杂系统故障面面观

welcome to join us

Fighting for dollars

从图来看，他们是主干发布

这个职位是北京的

谢谢分享。

你可以参考下面的信息

http://kb.flexerasoftware.com/doc/Helpnet/IA2011/Content/helplibrary/ia_ref_ant_task.htm

In order to redirect InstallAnywhere’s build process output to Ant’s log, you must specify a redirector as described in the Ant documentation (Exec task). For information about using Ant, see http://ant.apache.org/manual/.

然后在 http://ant.apache.org/manual/ 看到

redirector

Since Ant 1.6.2 A nested I/O Redirector can be specified. In general, the attributes of the redirector behave as the corresponding attributes available at the task level. The most notable peculiarity stems from the retention of the attributes for backwards compatibility. Any file mapping is done using a null sourcefile; therefore not all Mapper types will return results. When no results are returned, redirection specifications will fall back to the task level attributes. In practice this means that defaults can be specified for input, output, and error output files.

Errors and return codes

By default the return code of a is ignored; when you set failonerror="true" then any return code signaling failure (OS specific) causes the build to fail. Alternatively, you can set resultproperty to the name of a property and have it assigned to the result code (barring immutability, of course). If the attempt to start the program fails with an OS dependent error code, then halts the build unless failifexecutionfails is set to false. You can use that to run a program if it exists, but otherwise do nothing.

What do those error codes mean? Well, they are OS dependent. On Windows boxes you have to look at the documentation; error code 2 means 'no such program', which usually means it is not on the path. Any time you see such an error from any Ant task, it is usually not an Ant bug, but some configuration problem on your machine.

Sends the string "blah before blah" to the "cat" executable, using an to replace "before" with "after" on the way in. Output is sent to the file "redirector.out" and stored in a property of the same name. Similarly, error output is sent to a file and a property, both named "redirector.err". Note: do not try to specify arguments using a simple arg-element and separate them by spaces. This results in only a single argument containing the entire string.

Timeouts: If a timeout is specified, when it is reached the sub process is killed and a message printed to the log. The return value of the execution will be "-1", which will halt the build if failonerror=true, but be ignored otherwise.

使用 svn 的外部依赖功能——externals 属性

转自：http://dola.xinfan.org/?p=105

最近在做的项目有一个需求，就是我开发了一个模块，这个模块不仅我的服务要用，而且还要提供给另一个服务用。因为这两个服务会部署在不同的机器上，因此这个模块的代码不能被重用。

简单地说，就是有一个模块 A，会被 B 和 C 同时依赖，因此会出现两份 A 模块。

为了避免出现代码冗余，同时又满足三个模块的依赖关系，我把 A 模块独立了出来。

然后用 svn 的 externals 属性给 B 和 C 要模块添加依赖。

具体的做法很简单：

首先找到 A 模块的 svn 路径，比如 http://dola.xinfan.org/svn/project_A/。 然后在 B 或者 C 的本地 checkout 目录中找到 A 模块要存放的位置。 比如 B 的本地路径是 /path/to/B，要把 A 放在 /path/to/B/deps/A 。那么只要：

会出现一个列表，输入数字选择想要的编辑器。vim 选择 vim.basic 那个。

支持

猎头职位还是直招？

猎头职位报薪水，直招职位说公司

北京时间 6 月 16 日消息，据国外媒体报道，社交网络巨头 Facebook CTO Bret Taylor 在其 Facebook 上透露，今年夏天晚些时候他将从 Facebook 离职。离职后，Taylor 将会创建一家新公司，具体业务内容 Taylor 没有透露。目前这一消息已经得到 Facebook 官方确认。

履历：任职谷歌，颇具影响力

Taylor 曾经任职于谷歌，有较强的创业背景。从谷歌离职之后 Taylor 加盟了 FriendFeed，FriendFeed 是一家一度很流行的发现类社交聚合服务类公司。Facebook 于 2009 年收购了这家公司，Taylor 随后加入 Facebook。

目前 Taylor 在 Facebook 负责平台与移动业务。

在成为 Facebook CTO 的两年前，Taylor 在 Facebook 的各种会议中已经颇具影响力，包括 Facebook 最近的开发者大会。本周召开的苹果 2012 全球开发者大会上，Taylor 再次成为焦点，他在大会上宣布 Facebook 与最新推出的 iOS 6 系统深度合作。

发展：与谷歌前员工一起创业

Taylor 称自己在 Facebook 的这段时间是 “职业生涯中实现个人追求的时间”，而自己的离职也只是硅谷人生活最为平常的一部分。

“我此前一直在与 Mark（Facebook CEO Mark Zuckerberg——编者注）沟通，告诉他我最终还是希望能够离开 Facebook 出去创业，” Taylor 告诉记者，“我们觉得现在公司完成了 IPO，推出了一些新的东西，对我来说就是最好的时机。”

Taylor 所说的这些东西包括与苹果的合作、推出 Facebook Camera 以及能够帮助用户寻找喜欢的移动应用及桌面应用的 App Center。除此之外，有报道称 Facebook 正在运作自己的智能手机项目 “Buffy”。

Taylor 在离职之后将会与前谷歌员工 Kevin Gibbs 一起创业，但目前 Taylor 还没有确定自己的创业方向。他认为自己可能会进入一个自己作为消费者不熟悉的领域，正如之前他加入谷歌地图工作那样。

接班人：有资历，面临考验

Taylor 在接受采访时表示，他明白自己的离职将会对公司造成较大的影响，但他同时表示，公司创始人兼 CEO Mark Zuckerberg 领导下的 Facebook 中技术人才板凳能力深厚。

在 Taylor 离职之后，他的两名手下 Mike Vernal 和 Cory Ondreijka 将分别接管平台及移动业务。

Vernal 2008 年从微软跳槽至 Facebook，负责领导最初的 Facebook Connect 项目，同时还负责平台相关业务和信息实时分享平台 Open Graph 的开发工作。

Ondreijka 于 2010 年加盟 Facebook，当时 Facebook 收购了他所在的 Walletin 公司，在此之前，Ondreijka 曾在 Linden Labs 参与《第二人生》（Second Life）的开发工作。

业内人士分析，虽然这两位接班人的资格足够，但 Taylor 离职一举动备受关注，对 Facebook 影响较大，尤其是 Facebook 上市之后遭遇股价下跌引发媒体关注与投资者指责的环境之下，两人的表现至关重要，对两人来说，这绝对是一次极大的考验。

公司：面临挑战及信任危机

当被问及对公司的担心时，Taylor 表示公司上市对公司内部人员来说是急需关注的一个挑战。

“随着收到越来越多的关注，我们需要处理公司文化的改变，我们在从一个受到很多审查的私人公司转变为一个受到更多审查的公共公司。” Taylor 说。

但 Taylor 认为 Facebook 在不断壮大的同时仍然有能力保持灵活运转，小团队在高科技项目上仍然在不断努力。“这些细节非常重要。” 他说。

Taylor 的离职必将又一次引起媒体及投资人对 Facebook 的关注，这将会影响到投资者对 Facebook 上市之后能够留住重要人才的信心。

而 Taylor 在接受采访时表示，“一家公司发生血液更新的事情能够促进公司创新能力发展，我不认为这值得太过关注，我相信新的移动及平台业务负责人将会完全胜任他们的工作。”

Taylor 发表在 Facebook 上离职的博文：

我想告诉大家一件事，我将于今年夏天晚些时候从 Facebook 离职。对于离开 Facebook 这件事，我很伤心，但我也很高兴自己能够同我的朋友 Kevin Gibbs 一起开创新事业。

做出转变都是很艰难的，但我对我们的团队和领导人员非常有信心。从 Open Graph 平台和 App Center 到 Facebook Camera 和 iOS 整合，我们的这些成绩让我感到很自豪。我们非常兴奋全世界能看到我们团队所带来的这些神奇的事情。

在 Facebook 工作的这段时间里，我学到了比我预想的要多得多的东西。我还要感谢这些与我共事的天才们。

这里我还想特别感谢 Mark Zuckerberg，在过去的三年里，你不仅仅是我的老板，还是我的导师和最好的朋友。

感谢 Facebook 所有的同仁，这三年里你们让我的生活非常丰富多彩。

延伸阅读

---

Facebook CTO Bret Taylor 离职创业 2012/06/16 Facebook 高调的 CTO Bret Taylor 刚刚通过自己的 Facebook 页面宣布了将离职的消息。他表示 “我将在今夏晚些时候离职，虽然有些忧伤不舍，但是我也将兴奋的开始与老朋友 Kevin Gibbs 新的创业历程。”

Taylor 是通过收购进入 Facebook 的。其之前就职于 Google，随后离职创办了社交聚合网站 FriendFeed。FriendFeed 于 09 年被 Facebook 收购，Taylor 因此随之进入了 Facebook 并且在 10 年被任命为 CTO。

Taylor 离职后，其麾下的两位高层 Mike Vernal 和 Cory Ondreija 将分别担负起 Taylor 之前的主要任务，平台和移动。不过考虑到硅谷有收购的传统，Taylor 会不会再次开发一款应用，卖给 Facebook 或 Google，然后回归老东家呢？

可以把 node 适当分组

不错，谢谢总结。

我帮你调了下格式，去掉了 QQ 号等没用的信息

怎么寻找 tag？