Facebook程序员是如何背锅的?

前言:本文来自微信公众号“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”,意思是要稳中求快。

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

(完)

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注