48 事务与工程：什么是工程师思维？ 你好，我是七牛云许式伟。

服务治理的目标，是保障软件提供 24 小时不间断服务。服务治理没有简洁的抽象问题模型，我们需要面对的是现实世界的复杂性。

保障服务的健康运行，必然有大量的事务性工作，运维或 SRE（网站可靠性工程师）这样的职业也由此诞生。

事务与工程

但是如果我们停留在事务中不能出来，那么随着我们所服务的用户数量增加，必然需要招聘大量的人员来应对繁重的事务工作。

事务性的工作不会总是让人不开心，特别是工作不太多的时候。已知的、重复性的工作有一种让人平静的功效。完成这些事可以带来一种满足感和快速胜利感。事务工作可能是低风险低压力的活动，有些员工甚至喜欢做这种类型的工作。

但是我们必须清楚，在 SRE 所扮演的角色中，一定数量的事务工作是不可避免的，这其实是任何工程类工作都具有的特点。少量的事务存在不是什么大问题。但是一旦事务数量变多，就会有害了。如果事务特别繁重，那就应该非常担忧了。

如果花在工程项目上的时间太少，你的职业发展会变慢，甚至停滞。我们可以鼓励那些做脏活累活的人，但仅仅限于在这些工作不可避免，并有巨大的正面影响的时候才会这样做。没有人可以通过不停地做脏活累活实现自己的职业发展。

把问题彻底解决

那么，什么是工程师思维？

在部分所谓的技术导向型公司，可能存在一些思维惯性，销售和产品经理会觉得自己没有话语权，开发工程师会觉得自己的地位高人一等。

对此我其实很反感。推崇技术当然不是个问题，但是所有的健康公司都必然是业务导向的公司，所有的技术人员如果希望有好的职业发展，也必然需要去理解业务。

七牛是推崇工程师文化的，但工程师文化显然并不是去尊崇工程师这样的职业。

什么才是真正的工程师文化？

从浅层的意义来说，工程师就是要实现业务的自动化。DON’T REPEAT YOURSELF! 某件重复发生的事情只干一次就好，以后也不需要再重复做。

工程师的自动化思维，所体现的内在逻辑是如何把问题 Close，如何把问题彻底解决掉，而编码只是一种工具。

在我们日常生活中，很多问题不需要编码来解决，但是确实需要用 “彻底解决它” 的思维去完成。这种思维不仅限于工程师，同样适用于所有人。比如，我们开餐厅需要解决服务质量的问题，这一点可能海底捞就解决得很好，但是不一定是用编码的方式解决。同样地，假设我们办线下市场活动，要解决内容质量的问题。怎么彻底解决它，这是值得深度思考的问题。

很多人会习惯呆在自己的舒适区，习惯于做任务，每天重复相同的作业，这就不符合我们所说的 “工程师文化”。我们需要达到的状态是，今天干完一件事，明天开启新的事。

怎么判断自己在做新的事情？那就要看我们问题是否解决得够彻底。

比如我在做新媒体运营，每天写着不同的公众号文章，这是否代表我在做新的事情？答案显然是不一定。要回答这个问题，我们首先需要搞清楚的是，我每天发公众号文章，是在解决一个什么样的问题。如果我们没有想清楚这一点，那么我们就不是在 Close 问题，我们只是在做任务而已。

我们的目标显然不应该是每天发一篇文章。这是在定义一件事务，而不是定义一个目标。把问题定义清楚非常非常重要。清楚了问题，就是设定清楚了我们的目标。然后才能谈得上去彻底解决掉它。

从另一个维度看，工程师这种把问题 Close，彻底解决掉的思维，看重的是自己工作内容的长期价值。如果我们只是在做事务，如果我们并没有在实质性解决一个问题，那么这件事情的长期价值就是零。

所以本质上，工程师文化也是产品文化，把问题以一种自动化的方式解决。 这才是我们真正应该尊崇的工程师文化。

一个公司各个岗位是彼此协作的团队，工程师并不是特殊群体。销售、技术支持、产品、开发工程师每一个角色都是平等的。每个人都应该秉承工程师精神，把一个个问题 Close，让它不要再发生。不需要显得很忙，忙不代表成就，真正的工程师文化应该是推动整个团队往前走，每个团队成员都在成长。

系统化思维与批判精神

从更深层次来说，工程师思维是一种系统化的思维。仅仅是编码和自动化是不够的，很可能你编码也只是在实现某种事务性工作，而不是用系统性或者说结构化的方案来解决问题。

真正的工程师会系统化地考虑方案的有效性。他们追求的是用最小化的编码工作来解决更大范围的问题。

少就是指数级的多！

现实中，一些工程师经常对于自己编写的代码形成一种情感依附，这是人之常情。一些人可能会在你删除多余代码时提出抗议：“如果我们以后需要这个代码怎么办？”“我们为什么只是把这些代码注释掉，这样稍后再使用它的时候会更容易吗？”“为什么不增加一个功能开关？”

这些都是糟糕的建议。源代码管理系统中的回滚其实很容易，但大量的注释代码则会造成干扰和混乱，尤其是我们还要继续演进时。那些由于功能开关没有启用而没有被执行的代码，更是像一个个定时炸弹一样等待爆炸。

极端地说，当你指望一个软件 24 小时不间断服务时，在某种程度上来说每一行代码都是负担。所以 SRE 需要推崇的实践是保证所有的代码行都有必须存在的目的。

另外，从软件工程角度来说，传统意义上的工程强调的是复制性，但软件的编码却是一项不确定性很强的创新性工作，我们总在不断迭代出新的技术。所以软件工程是颇为复杂的东西，它需要在不确定性和复制性这对儿矛盾中平衡。

所以优秀的工程师还需要有批判精神。经验当然是有价值的，但过于相信惯例就会抑制创新能力。寻求本源，不迷信惯例和权威。以数据为指导，从根源出发去系统性解决问题。

结语

今天看起来我们的话题有了一次比较大的跳跃，谈起了工程师思维和工程师文化。但服务治理不是纯理论，没有简洁的抽象问题模型。我们面对的是现实世界的复杂性。这些现实的复杂性，背后是大量的事务工作，尤其是我们对问题还不够了解的时候。

这个时候，工程师思维在背后起到了关键性的支撑。正是我们坚持了批判精神，坚持了以系统化的思维来把问题彻底解决，才有今天服务治理系统的日新月异的发展。

如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们聊聊 “发布、升级与版本管理”。

如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e8%ae%b8%e5%bc%8f%e4%bc%9f%e7%9a%84%e6%9e%b6%e6%9e%84%e8%af%be/48%20%e4%ba%8b%e5%8a%a1%e4%b8%8e%e5%b7%a5%e7%a8%8b%ef%bc%9a%e4%bb%80%e4%b9%88%e6%98%af%e5%b7%a5%e7%a8%8b%e5%b8%88%e6%80%9d%e7%bb%b4%ef%bc%9f.md