产品完成开发之后，当然就要推出去。推出去之前，有些产品需要进行风险控制。比如，支付类的产品经常会做发布前评估（Pre-launch Review）。
所谓发布前评估，就是在发布之前，根据具体的产品或者该次发布的特点，做一些诸如发布策略、需监测的核心数据、产品演示、核心算法改变等方面的讨论。我在做产品讨论的时候，要求参会的人员都思考这个问题——“如果这次发布出现大问题的话，可能会是什么？”主要目的是在发布之前思考可能会出现失误的节点，如果是大风险，做一些必要的防护措施；如果是小风险，心里要清楚自己在冒这个险，准备好一旦出问题该如何补救。另外，由于Facebook发布的产品比较多，经常出现互相影响的情况，做发布前评估可以让大家知道什么产品即将在什么时候推出去。
对于发布前评估，我有这样一些经验。
1.要短。不应超过半小时。做产品预览是需要成本的，不能因为这件事而产生面面俱到、追求完美的副作用。
2.形式可以多样。成本比较高的会议形式，比较适合大的或者新产品的发布。也可以是成本比较低的邮件方式，比较适合改错（Bug Fix）或者产品改进（Product Improvement）。甚至可以是几个技术人员口头聊聊，适合于小的改错（Minor Bug Fix）。
3.人员选择可以多样。如果是产品发布，一般找与该产品关联的相关产品的人员来参与。如果是邮件，会发相关列表。由于涉及人员的时间成本，选择时尽可能只找有可能会提出建议的人。
4.内容可以多样。前面提到，根据产品的特性或者代码改变的特点，讨论的内容可以不同。如果是发布策略，一开始先针对哪些类型的用户之中百分之几的人发布产品，然后观察哪些核心数据能够得知产品成败与否。如果是产品演示，在有限时间内展示哪些核心功能，这些功能的上游和下游产品分别是什么，和他们的集成以及团队的沟通做得如何。如果是核心算法的一些改变，要把核心的改变解释清楚。
不过，不管你在产品发布之前做了什么样的准备，都不可能100%确保发布是安全的。大家要坦然面对这一点，也不需要在发布之前做出极端的准备措施。
但不能藐视发布过程中的风险，一种发布工程的做法是阀门控制式的灰度发布（Gated Launch），就是有所控制地选择发布的人群及其比例。在Facebook有一个比较完善的工具，可以允许在产品源代码中嵌入一行灰度控制代码，这样就可以很容易地控制该产品的发布对象。比如第一次发布时只让1%的美国用户使用这个新功能，如果没有什么大问题，接下去再扩大到5%、10%、50%、90%、100%之类的，或者扩展到其他国家。具体的扩展策略根据产品来决定，并没有严格的规定。不管如何，目的就是在尽可能短的时间内将产品安全地发布到所有Facebook用户面前。灰度发布工具允许控制的属性很多，比如年龄、国家、城市、性别、语言、学历、工作单位等，还有这些属性之间的条件并列，发布者都可以控制。比如你可以把产品发布到“当前居住在旧金山的会讲中文的女大学生”。
灰度发布是控制发布的范围和速度，但如何才能得知某一阶段产品发布的质量，何种状况下才提高灰度发布的范围呢？只有通过数据监测来判断发布状态。
需要监测的有两类数据。
一类数据反映当前的系统状态，比如访问总量、访问成功量及其占总量的比例、致命范围错误的量和比例、访问速度、出现最多的错误类型统计，等等。这些数据的统计和展示都应该是实时的，这样才能确保一旦发生问题，能够在最短的时间内发现并采取措施。如果问题仅局限于新功能之中，由于是有控制的灰度发布，可以马上关掉或者降低发布范围，使损失得到控制。但如果新功能对已有的系统带来了致命的问题（Critical Bug），导致其他核心功能无法使用，那危害性就大了。我就曾经在发布礼物商店（Gift Shop）的一个功能时导致Facebook无法访问达半个小时。当时还没有灰度发布工具，否则只需要在这个工具上点一下鼠标，就能关掉新的功能，尽可能减少损失。
另外一类数据反映新功能的用户影响（User Impact或者Business Insight）。比如新礼物商店是否提高了用户的点击率；从点击到购买虚拟礼物的转换率，提高了多少，等等。这部分数据能直接反映出一开始做这个产品或者功能的目的。只有这部分的数据反馈是正向的，而且其变化达到了让人接受的程度，才可以考虑扩大发布范围。
当然，并不是发布过程中所有的改变都可以通过灰度发布工具来实现，比如后台数据库的格式改变（Schema Change），这种改变一般是所有用户同时迁移，做到逐步迁移的成本非常高。这个时候就要另想办法。
上述这两类数据都需要有非常简单的收集和直观的展示方式。为此Facebook做了一套数据收集、处理、存储、查询、展示系统。对于项目人员而言，只需要一行代码，就可以把项目相关数据记录到一个大服务器群中的一个相应的计数器中。这个计数器会自动对数据进行整理，在预先设定的时间窗口（Time Window）对数据进行平均（Average）与求和（Sum）。在存储过程中，时间越早的数据的取样率（Sample Rate）会越大，而最近的数据则比较精细。对于监测过程而言，最最重要的是简单的查询和可视化的展示。相关人员可以登录数据仪表（Data Dashboard）工具进行简单的设置就可以立马生成一张和相应的计数器对应的图表。你可以设置这张图的时间跨度，是最近的15分钟、几个小时还是一天、一周，等等。还可以和上周或者上月的数据进行同图层叠显示、加以比较。这种图表会实时更新。我们发布产品时，习惯在旁边专门用于显示数据的电脑上打开几张相应的表，进行实时观察。
另外一个很重要的功能，就是实时警报。比如点击率和上周相比突然下降了30%，马上给指定的人员发邮件或即时消息、短信等。警报可以分重要性的等级，如果最高等级的警报（Critical Alert）在半小时内甚至更短时间内，没有得到响应，Facebook有一个24小时值班的全球团队（Site Reliabiity Organization，“SRO”）会做出反应，他们会根据你事先制定的对应措施进行应对，如果还不能解决问题，就会打电话给你，即使是凌晨3点。
上述第二类数据对于产品后续版本的开发有很强的指导作用。核心数据中反映的问题可以成为后续版本专注的对象。像我们反支付欺诈组在很长时间内都关注支付退还率（编者注：通常是用户投诉，银行把钱返还给用户并对商家进行罚款），每次改变都密切关注对不同类别支付退还率的影响，比如当我们大幅降低了盗用信用卡造成的支付退还率之后，我们就把注意力放到了盗用账号引起的支付退还率上面。而这种重心的转移都是通过数据反映出的问题严重程度来决定的。
并不是所有的发布都是成功的。其实从我的经验来看，追求完美的发布是不现实的，不管之前的Pre-launch Review多么全面，每次发布都有这样或者那样的问题产生，最好的情况就是每次的问题都是新的，而不是上次已经出现的失误。但在问题发生之后，通常通过Post-Mortem尝试尽可能从失误中吸取教训，让每次的发布带来的学习价值最大化。
所谓Post-mortem，就是通过分析过去发生的问题，从中总结可以采取的行动方案，以避免类似的错误再次发生。不仅仅适合于产品发布产生的问题研究，同时也常见于任何突发事件的事后分析。
如果是比较小的事件，Post-Mortem可以由当事的工程师们自己讨论总结；如果比较大的话，这需要召开会议要求所有相关的人员（包括非产品技术）参与。
Post-Mortem会涉及以下几个方面。
1.发生了什么（What Happened）？一句话总结发生的事件，比如曾经发生过的一次系统停顿事件，“在4月1日早上6点到7点，反欺诈人工规则系统失效”。
2.影响多大（What"s the Impact）？总结这个事件造成的影响，最好能量化。比如“有1500条交易没有通过任何的规则审查”。
3.问题的原因是什么（Why）？解释问题发生的根源。如果是bug（代码错误），具体解释这个bug是什么，必要的话可以把出错的代码展示出来。
4.事件发生的具体时间表（Timeline）。具体描述从发现问题、报告问题、寻找问题到解决问题的整个过程，并把时间点表示出来。
5.如何避免将来犯类似错误的行动方案（Action Items and Lessons Learned）。这是整个Post-Mortem最重要的一部分，就是从这次事件中学到了什么，应该采取什么样的行动避免将来重复犯错。Facebook很少惩罚犯错的工程师，所以Post-mortem不会去深究究竟是谁的责任；但会把主要的精力放在研究暴露出来的问题和应该采取的相应的解决方案上，不允许同样的错误被重复。对于每一项行动方案（Action Item），都会有一个执行人的名字在其后面，以确保有效执行。
我们曾经发现一次改了人工规则系统的代码之后，把一个条件弄反了，造成的结果就是所有应该通过的交易都禁止了，还好这是在运营组做内部测试的时候发现。通过Post-mortem，我们肯定了在公开开放新功能前进行内部测试的价值，也发现了这部分的代码并没有单元测试（Unit Test）来覆盖，所以赶紧把相应的单元测试加上，并对规则系统的代码做了一次审查以确保单元测试的覆盖率。如果一个问题要暴露的话，我们希望其越早暴露越好。我们非常庆幸那次事件以最低的成本暴露，然后我们尽可能地挖掘并暴露更多的问题，并采取行动避免将来相关问题的再次发生。
Post-mortem总结的内容会通过邮件的方式发送到所有相关的人员，并在相关组的邮件列表中存档，最大程度地公开对事件的调查和反省，以方便所有人的学习。
Facebook不追求完美的一步到位，而是通过Post-mortem从失误中不断学习，让做事的质量越来越高。
以上就是我所总结的Facebook产品开发流程，当然，对于每一个具体的产品来说，不一定严格按照这些步骤进行，但大体的思路类似。根据需要，部分步骤可以被省略。根本目的是为了在产品满足基本的质量标准之后，尽可能早地发布出去，然后根据监测数据再快速迭代。
我跟国内的一些创业公司就产品开发流程进行过沟通，希望硅谷公司的思路可以带给他们启发。然而，Facebook的这些做法不一定适用于中国的互联网企业。在Facebook，很多时候是在证明你不行之前，假设你有能力完成一件艰巨的任务。由于Facebook招的人都是最顶尖的，这种假设在多数情况下被证明是可行的。
我帮助过的一家公司CEO曾说过：“Facebook的做法我会借鉴，但绝对不会照搬。中国互联网有自己的特点。”我很赞同这种态度。中国团队到底能不能效仿Facebook这样的产品开发流程，或者说能学到多少，我不清楚，这也许和中外互联网环境有关。真正关键的是，通过相互了解和借鉴，知道别人都在做什么、怎么做、为什么这么做，可以开拓思路，就能比之前有所进步。
