这是一个关于工程师如何“修身养性“，以此提升自我的系列文章。

网络犯的错？

年轻时曾经编写了一段异步处理的代码，需要做的事情很简单：

kafka consumer消费和处理数据。完成了开发，自己完成e2e测试。处理的数据T+1分钟显示在前台。

最终在AWS部署的QA环境中出现了数据不显示的问题，当然现在的我肯定一眼就知道这是队列积压，并考虑优化代码。但是谁不曾年轻呢，我在数据消费的节点之间用ping命令查看延迟。发现这个环境中，2台机器之间的延迟相对其他机器间的延迟要高上10倍。最终得出一个结论： AWS的网络可能出了问题。需要排查AWS的问题。

领导激动地说：aws怎么会有问题呢，并让我继续去排查。

后来我才发现，原来是同一个region下是双AZ部署，不同az的机器间通信延迟更高，导致开发环境（单AZ）和QA（双AZ）环境基线不同，因此在开发环境看不到问题，而在QA环境出了问题。

好吧，这是我第一次有了az的概念。最终我优化了算法，在大数据量下也可以保证及时的消费。

为何我总是第一时间找别人的问题？依赖的服务到底犯了什么错?

自我服务偏好

所谓自我服务偏好（self-serving bias）是指对自己、自己的行为以及他人的行为以一种有利于自我的方式所进行的判断或解释。从查理·芒格口中所说，这算是一种潜意识的极端的意识形态，我们应该尽量避免。为了避免，必须对此意识的存在和自身有足够的了解。

好吧，我就是想尽快甩锅。而抵抗这种思维的难点在于，他是一种潜意识。

在今后的日子中，我看到这种自我服务偏好不断地上演在身边的研发身上。我也是时而给其他人兜底。因为自我服务偏好会让你的解决问题效率大打折扣---你总之在错误的方向上使劲：* *

• 网络不稳定，延迟高 --- 即便如此，针对不可靠的基础设施，你有面向故障做设计么？
• 编程框架出了什么bug吧 --- 难道不是你自己写了什么死锁在业务逻辑里？访问数据没有出现超时么？

事实是，基本上都是业务逻辑实现问题。

又是网络犯的错？

一个定位了3天没有解决的简单问题：

程序经常抛出异常，表示数据库连接异常，这个时候研发就登录到kubernetes托管的pod实例中ping mysql的地址并表示，这个时候是ping不通的。

于是得出了一个结论：kubernetes的容器网络到mysql的宿主机网络不稳定。并要求这些软件的提供商来定位问题。

这件事情因为阻碍了当天的上线计划，被捅到我这里了。但是我还是秉持着“提升研发解决问题能力”这个主张，不打算辅导什么，就放手让他们折腾。

直到再过去2天。我不得不去给研发们看看了。

我找到了研发后，了解了下情况后，我说了句：ping命令行走的是icmp协议，数据库链接走的tcp协议，icmp不稳定不代表tcp不稳定。

并问清楚了代码的异常信息和使用的数据库链接池代码（一款开源软件），根据异常信息走读代码，找到进入这段异常的if分支，大概有3个条件，总之大概的意思是：数据库链接池太忙了。我看到这儿就已经决定了关键性问题，于是就让研发再去排查怎么写的业务逻辑。不到30分钟，就得到了反馈：是因为数据清洗逻辑所有的insert操作都是for循环，而没有用batch insert。

3天vs分钟级根因定位。举这个例子只是为了让大家直观体会自我服务偏好对工作效率的影响。

可以评价这件事为：只是研发因为耽误上线而进行的快速甩锅操作。

而我之所以对这个案例印象如此深刻在于自我服务偏好的魔力之强：这个负责的研发原本是位网络工程师，熟知网络层知识。

结语

随着技术的发展或许你可以傻瓜式的使用很多技术，比如Java有着自动垃圾回收，Go语言有协程和channel，不断解放工程师的心智，降低开发门槛。但是工具在人手中，人是发挥它的关键，当你组合一些能力完成软件功能时，难免会出现错误的用法造成不可挽回的重大事故。这时候工程师首先应该想到的是自己逐层下钻，定位到问题根因，当自己能触摸的全栈技术都排查后才能断定问题来自依赖层，而不是找人定位自己处于躺平状态。

减少由于心理作用造成的技术误判是每个工程师应该做到的。这需要抗拒人性，需要刻意练习。

那么当你这么做之后收益是什么呢？

每一次的定位经验都会增加你的知识深度和广度，让你不断增强自己的能力。

这种修养（其实是思维）是拉开工程师间差距的原因之一。这也是个人认为作为最底层小兵期间，最需要培养的。因此我写在了系列开篇之中。

我计划编写更多的工程师的自我修养系列。除了自己的一些感悟会按部就班的编写发布，也欢迎读者们私信留言，提出自己关心的任何问题，上下文信息越多越好，不限于本篇文章。我会尝试解答。我将以类似书信的形式和各位读者沟通，帮助更多的工程师提升自我，高效地完成工作。

如果觉得有收获，请点赞转发收藏关注，感谢读者们