后端开发甩锅指南

甩锅,最重要就是技术的方法论。

如果在代码质量、后端架构上你有处于鄙视链上端的方法论,那么甩锅就能易如反掌事半功倍。如果对于软件工程、项目管理有方法论,那么你的甩锅将信手拈来无往不利。

其次,对不同的角色需要有不同的侧重。

例如甩锅对象是产品,那重点应该放在需求和时间上;

如果甩锅对象是组里的新人,重点通常是「性能」、「优雅」、「设计模式」;

面对测试,可以讲讲如何难以实现和如何难以复现;

面对的是同级开发,情况比较复杂,通常可以侧重code review;

想要把锅分担给运维时可能比较轻松,讲一讲十年前留下来还没处理掉的基础设施的bug。如果公司还没有十年的话,可以谈谈做压测和走部署流程有多不方便。

考虑甩给leader,则需要再三谨慎,因为对方很可能掌握着强于你的方法论。

最后,一定需要结合实际情况。

例如,虽然重点是抱怨产品的需求,但千万不能主动提起「用户体验」;再比如,甩锅给运维提到「机器性能」时,也注意不要犯「给公司省点钱」的错误。


下面,就具体情况举一些实例。

API响应慢:

对测试:只有一/几个用户反馈吗?影响主流程吗?能稳定复现吗?

对前端:前端能做缓存吗?能改成轮询吗/能改成长连接吗?有前端日志吗?

对产品:功能太复杂了,得砍。

对同级后端:这个API调用的五个函数里面有一个之前是你实现的吧?能优化一下吗?

对实习生:我是让你这么实现没错,但是是基于高内聚低耦合的原理。嗯,这个数据库是我让你这么设计的,是为了符合第二范式。你听过反范式吗?

对运维:会不会是阿里云的问题?

线上业务接口出错:

对测试:我以为测试应该能覆盖到这个情况的。

对前端:你们接入的时候也没讲清楚你们必须要这个形式/格式/类型的字段。

对产品:功能太复杂了,我代码实现起来很ugly,没有办法考虑到所有情况。

对同级后端:这一段我复制的你两年前的代码,谁知道居然有bug没有被发现。

对运维:你们监控报警太少了/日志收集太慢了。

任务delay:

对测试:你们报过来的bug太多了,有些小的bug就可以降低一点优先级过来吧。

对前端:接口都设计好了,开发的时候一直让改动。

对产品:需求改来改去/功能不合理/时间排的太紧。

对同级后端:老不干活。

低级错误导致业务挂掉:

对运维:你们应该把redis的keys命令禁掉吧?

对测试:这个接口慢成这样,测试的时候应该当bug提出来啊?

对前端:这个接口慢成这样,接入的时候应该当bug提出来啊?

对产品:这个需求太奇怪了吧,我只能这么实现吧?

对同级后端:唉,我代码写成这样,你code review居然没看出来?

对自己带的实习生(在疯狂查阅资料后):我让你遍历key的时候,意思是用scan。当然,这个主要还是需求不太合理。

没有理会依赖包的deprecated warning,导致某次部署后挂掉:

对基础团队:为什么一个基础库要改的和以前不兼容?

对产品:需求太多了,根本没有时间做技术的升级。

对同级后端:我记得你上个月就说要升级的,啊?我还以为你已经做过了!

不理会文档写的约束,疯狂调用其他业务导致对方业务挂掉:

对运维:你们的熔断机制不完善啊?什么?没有熔断?

对产品:讨论方案的时候我就讲过这个不太合理了。

对对方业务组:你们的提供的接口需要做一下限制,不应该信任调用方。


以上。

实际上我想有相当一部分技术人员并不擅长所谓甩锅,上面的例子统统浮于表面。真正的甩锅是不形于色,谈吐自若,依靠春秋笔法和强大的精神力控制住所有相关利益者的喜怒哀乐,最后于无形之中理所当然的把锅嫁祸给别人。

发布于 2019-03-20