Facebook程序员是如何背锅的？

facebook| 2018-09-13

前言：本文来自微信公众号“MrPeak杂货铺”，作者是一位在硅谷Facebook工作的程序员，他的文章描述了硅谷的生活，文化的差异，很有意思，推荐给大家。

上半年绩效考核终于接近尾声，我也有机会静下心来回顾过去半年的经历。

来 Facebook 工作虽然已半年多，但我骨子里依然是从毕业起就耳濡目染的那一套价值体系，任何在 Facebook 所经历的公司文化或者工程文化上的差异，都会带给我强烈的体验冲击和后续的思考，比如说最近在脑子里挥之不去的程序员背锅话题。

Facebook 曾经有一句名噪一时的口号：“Move fast and break things”。鼓励员工快速大胆的去实践自己的想法，而不需要过分担心风险。

我这半年的经历可以印证这句话所言不虚，这种精神确实是 Facebook 工程文化的一部分，就我所在的部门，就经历了大大小小的工程事故。但这并不表明 Facebook 在产品质量的把控上存在明显问题，相反在我看来， Facebook 的这套持续交付质量控制系统非常有效，并不逊色于国内的做法，这个话题可以再起一篇文章另谈。

有一个线上事故印象特别深刻，据同事说，应该是部门成立有史以来发生过的最严重的问题，我全程参与事故的调试，修复以及复盘。

在事故刚出现，后台数据狂飙的那一瞬间，我着实跟着紧张了一把，因为那个版本里有我最大的一次代码提交，在找出真正的事故原因之后我松了口气，然后开始持续高度密切关注背锅的问题。这么大的故障，这口锅得多大多沉。后续发生的事每一件都偏离了我的预想。

修复

刚确认事故的那一刻起，先是几个人在一个群里讨论事故细节，之后越来越多的 Engineer 和 Manager 加入进来，讨论很热烈，鉴于影响规模之大这点倒不难想象。没多久就确认了原因以及提出好几个解决思路，有几个 Engineer 主动领了任务分头并行。

整个过程中有几个细节让我很在意。

想象一下，如果支付宝线上版本全面 crash，后台收到海量的用户反馈，一星评价，然后上了科技新闻，而所有的讨论和处理仅仅发生在一个二十多人的群里，除此之外，感觉不到任何异样，部门里其他团队依旧是在忙自己的活，好像什么都没发生，这种气氛是不是有些反常。

我中途还和另一个团队哥们聊了一会，他简单询问了下过程，嘿嘿一笑后就转身和别人讨论自己的需求去了。

群聊里，部门老大出现了一次，确认事故原因已找到，修复方案已在执行之后就消失了。下午五点多，热闹的群聊突然冷清了下来，我知道这是因为下班的时间点到了。

有个哥们还在群里留言，嘿，我要赶回家的巴士先撤了，等我到家再看下有什么我可以帮忙的。我第一反应是黑人问号脸，哥们胆子真肥，问题还没最终修复，老大还在群里呆着，你就准点下班了，还在群里高调宣布，几个意思？我以前在国内不是没经历过这么大的事故，现在能记起来的是每个人脸上的凝重，和部门老大涨红了脸的咆哮，而且我知道，谁要是在那个时候准点下班，一定会遭遇老板最炙热的目光拷问。

期间，还有个非常资深的哥们在群里开玩笑：“this review is gonna be so exciting!（emoji 笑脸）”，心情看着不错呀你！

当天晚上十一点的时候，问题还在，修复并没有那么快。群聊里突然没了一点动静，我知道这是因为睡觉的时间到了。最后一条留言是，有个哥们说自己晚上会再测试一把，确认问题真正修复，还顺带解释道，正好自己晚上要喝啤酒通宵看球。我觉得他这后面一句不说会更好。

事后我回想起整个过程，也问自己，如果大家在处理时都更严肃，更紧张，甚至部门老大当众发一顿脾气，会不会问题就解决的更快一点。好像并不会，我认为处理的核心在于，是否在积极寻找事故原因和修复方案，如果这条主线在高效的往前走，除此之外的方式和手段都于事无补，都是多余的或者出于其他考量的。

复盘

我期待已久的复盘会议发生在大概一周之后，我知道事故一定由于一个 Engineer 的代码改动导致的，期待见到这位背锅侠。

遗憾的是，在一个二十多人的会议室里，我确信这位大侠一定就在现场，但就是不知道是哪一位。奇不奇怪？

会议的全程都在讨论事故是如果绕过系统流程进入线上的，在讨论后续可能的方案来避免类似的故障。简单提到事故的原因是由于某某团队的某次改动导致的，但仅此而已，只有团队的名字，不知道具体是谁，好像也没人关心，会议的主要讨论都集中在解决方案。

部门的终极老大坐在一个角落的桌子上，如果不是看过照片，还真不知道他是哪位。老大主要的发言是: “我们确信某某团队的项目对我们是必须的，所以不该因为项目的风险而质疑，应该想办法来规避风险”。

后来我找机会和一位资深员工又聊了这个话题。他说他经历过很多个复盘会议，会议的目的都不是去指责谁，而是如何避免类似的风险。

有一次他参加的时候，有位苦主可能过于紧张，慢慢进入了状态，说自己不该这样不该那样，应该怎样怎样，然后他就被大家集体制止了，说，hey，hey，stop！我们开会不是来责怪你，别跑题了，我们还是继续讨论解决方案吧，然后哈哈哈的把尴尬带过去了。

复盘

就我以前经历而言，最高级别的线上故障肯定会有一个责任人，而且这位兄台的年底绩效考核基本上是完蛋了，没有奖金，没有股票，更别提升值机会了。

这种直接关联，事故与责任人一对一的惩罚机制意义在哪？它是否能有效降低程序员因为粗心而导致故障的概率？

我明白所有程序员都会写 bug，早些年的时候，我认为 bug 虽然是无法避免的，但程序员可以凭借经验的累积和技艺的提升来完全规避大的故障。

随着代码越写越多，经历也多了之后，我彻底否定了这一想法。我现在认为，无论你多么资深，在某个领域沉浸了多少年，你始终有一定概率会写出大 bug。

来 Facebook 之前和之后，我都见过我认识的非常厉害的程序员，写过因为粗心而导致的大故障。当然粗心的对象并不一样，刚毕业的新手是在写一个排序函数时粗心，经验老道的程序员则可能是在重构一个系统时粗心。

通过绩效考核的惩罚能不能降低粗心的概率呢？能，在一天，一个星期或者一个月里绝对能，但长期来看，这种压力总会有松懈的时候，是人就会犯错。在关键的时候，我们更应该依赖不断打磨日渐成熟的系统和工具来检测杜绝错误，而不是依靠人的神经系统。

因为一次的故障而否定某个程序员一年的努力，显得太不人道。

那事故的责任人是不是就可以高枕无忧，在事故之后依然可以没事人一样逍遥法外呢？这是绝无可能的，每个人都不是孤立的个体，所有的行为都会有其群体效应，每一个醒目的大 bug 都会在潜移默化中削弱你在团队里的影响力和认可度，我们完全可以把事故的责任交给成熟的工程文化去消化，而且在这种文化里，一旦犯了错，至少还有机会去弥补，可以促使责任人用更大的成绩来抵消过错。

事故的真正价值在于对现有系统漏洞的补充，从而规避未来风险。

最后值得一提的是，Facebook 很早前就将口号换成了“Move fast with stable infra”，意思是要稳中求快。

程序员之路长且远，路上多荆棘，诸君还是应该通过持续学习来提高自身姿势水平，要稳不要皮。

（完）