假如你的代码让公司亏了100万

虽然标题是假如,但是这种事我早就干过了,而且亏了不止一百万。今天就来聊一下这个问题,假如你的代码让公司亏了100万,最终的责任分配应该是什么样子?你会被炒吗?

我在面试中跟几家公司的面试官也讨论过这个问题,不出意料,在很多公司,被炒是大概率事件。 而同样的事情,发生在Facebook和google这样的公司,员工不仅不会被炒,甚至批评都不会有,不会被追究任何责任。有传言说在Facebook,如果你把生产环境搞挂或者造成重大损失,大家会庆祝你在Facebook成年了。这种差距的背后是什么?是这些公司有钱,不在意这些亏损?恐怕并不是,这背后其实是一种对待错误的价值观的不同。

回顾一下上面的一篇文章《归因理论》的一个阶段性结论,重要的事情,不管是不是由于客观因素引起的,最终必须归因到主观因素,否则是很难被大家接受的。回到我们的场景,线上bug,还造成了重大损失,肯定算是重要事情了。那首先,这件事情的归因无论如何,都无法归因到客观因素了,比如我们依赖的某个系统恰好在这个时候发生了概率为百万分之一的宕机事故,比如用户操作的时候手抖点到了平时不会点的一个按钮。因为,归因到这样的客观不确定因素,背后隐含了的命题是,如果运气不好,这样的事情还会发生,我们不能接受。

因此从负责人的角度讲,这件事情一定会被归结到一个非常具体的有能动性的人身上,由这个人来对这件事负责。那这个人选其实只有几个,QA,OP,RD,还有用户,通常最好的结果就是,QA和RD以及对应的领导,都要承担一部分这个责任,并提出改进措施,避免类似的事情再次发生。其实在一定程度上,这个处理已经非常的好了,比不分青红皂白直接把RD开了的公司,已经是一大进步。这种已经是一家有责任感的公司的处理方式了。

因此,这个问题的本质,是一个价值观问题,而不是甩锅问题。我们有更好的责任分配方式,涉及到的价值观有两个,这两条价值观都非常重要,非常有启发性:1、在Google和Facebook这样的公司,有一种很流行的价值观:人是一定会出错的,只有机器才可能完全不出错,我们不能对人吹毛求疵。因此,最关键最重要的流程应该由自动化的脚本和流程来保证,而不应该由人来保证。也因此,上线的责任应该归结于上线机器,或者说整个上线流程,而非人。2、在Google 的SRE这本书中,首次提出了整个SRE的核心理念之一:问题总会出现的,努力去保证问题不出现,不如做一个在问题出现后能够自动恢复的系统,这与传统的运维观念完全相反(在这本书中,Google同样指出,SRE是devops在Google的具体实践,我们EA目前的SRE虽然同叫SRE,但实际上还是更接近传统的运维,而非Google SRE)。

在这两种价值观的主导下,这件事该被怎么处理呢?1、只有机器才不会出错。RD,QA等具体的人不需要承担具体的责任,绩效也不会被影响,因为错误的代码应该在整个流程的保障下无法对线上产生大规模的影响,各种灰度流程和自动化测试应该提前发现这一问题。因此这个问题暴露了自动化测试或者灰度流程或者其它上线流程中的不足,从而得出需要改进的地方,进而,整个上线流程会变得更为可靠。2、问题总是会出现,更多的精力应该放在自动化恢复上。SRE应该分析这个问题为什么会发现的太晚导致损失较大才被发现,系统监控报警是否需要改进?为什么在发现后恢复时间这么长,没能及时止损?是否有一些系统指标没有被正确监控? 这两点,一点从事前保证错误代码不会大规模应用到线上造成损失,另一点保证事后可以快速止损,从错误状态恢复出来。这两种能力的建立,非常非常重要,而这两种思想,非常非常有启发性。

这两种处理方式并不是好与坏的区别,而是好与更好的区别。基于归因理论所作出的朴素的归因和改进措施已经很不错,而Google和FB这种换个角度看问题和解决问题的方案则更加优秀。我们回到归因理论之所以要归结到人的出发点,是因为如果归因不到具体的个人,很容易没有能动性,没有具体的措施,从而发生事后根本无人负责,同样的事故再次发生的惨案。Google和FB这种做法,看似没有归因到人,实际上是从另一个角度把责任归结到了具体的人身上,最终负责维护上线脚本和自动化测试的人和SRE的人,都会积极的去改善他们的系统。而且这种改善不是被批评之后的改进,而且普通的发现系统的不足之后的改进,情绪上也会更好一点。

对于这一开放问题,你怎么看呢?

发表评论

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