|
|
# 48 | 事务与工程：什么是工程师思维？
|
|
|
|
|
|
你好，我是七牛云许式伟。
|
|
|
|
|
|
服务治理的目标，是保障软件提供 24 小时不间断服务。服务治理没有简洁的抽象问题模型，我们需要面对的是现实世界的复杂性。
|
|
|
|
|
|
保障服务的健康运行，必然有大量的事务性工作，运维或 SRE（网站可靠性工程师）这样的职业也由此诞生。
|
|
|
|
|
|
## 事务与工程
|
|
|
|
|
|
但是如果我们停留在事务中不能出来，那么随着我们所服务的用户数量增加，必然需要招聘大量的人员来应对繁重的事务工作。
|
|
|
|
|
|
事务性的工作不会总是让人不开心，特别是工作不太多的时候。已知的、重复性的工作有一种让人平静的功效。完成这些事可以带来一种满足感和快速胜利感。事务工作可能是低风险低压力的活动，有些员工甚至喜欢做这种类型的工作。
|
|
|
|
|
|
但是我们必须清楚，在 SRE 所扮演的角色中，一定数量的事务工作是不可避免的，这其实是任何工程类工作都具有的特点。少量的事务存在不是什么大问题。但是一旦事务数量变多，就会有害了。如果事务特别繁重，那就应该非常担忧了。
|
|
|
|
|
|
如果花在工程项目上的时间太少，你的职业发展会变慢，甚至停滞。我们可以鼓励那些做脏活累活的人，但仅仅限于在这些工作不可避免，并有巨大的正面影响的时候才会这样做。没有人可以通过不停地做脏活累活实现自己的职业发展。
|
|
|
|
|
|
## 把问题彻底解决
|
|
|
|
|
|
那么，什么是工程师思维？
|
|
|
|
|
|
在部分所谓的技术导向型公司，可能存在一些思维惯性，销售和产品经理会觉得自己没有话语权，开发工程师会觉得自己的地位高人一等。
|
|
|
|
|
|
对此我其实很反感。推崇技术当然不是个问题，但是所有的健康公司都必然是业务导向的公司，所有的技术人员如果希望有好的职业发展，也必然需要去理解业务。
|
|
|
|
|
|
七牛是推崇工程师文化的，但工程师文化显然并不是去尊崇工程师这样的职业。
|
|
|
|
|
|
什么才是真正的工程师文化？
|
|
|
|
|
|
从浅层的意义来说，工程师就是要实现业务的自动化。DON'T REPEAT YOURSELF! 某件重复发生的事情只干一次就好，以后也不需要再重复做。
|
|
|
|
|
|
工程师的自动化思维，所体现的内在逻辑是如何把问题 Close，如何把问题彻底解决掉，而编码只是一种工具。
|
|
|
|
|
|
在我们日常生活中，很多问题不需要编码来解决，但是确实需要用 “彻底解决它” 的思维去完成。这种思维不仅限于工程师，同样适用于所有人。比如，我们开餐厅需要解决服务质量的问题，这一点可能海底捞就解决得很好，但是不一定是用编码的方式解决。同样地，假设我们办线下市场活动，要解决内容质量的问题。怎么彻底解决它，这是值得深度思考的问题。
|
|
|
|
|
|
很多人会习惯呆在自己的舒适区，习惯于做任务，每天重复相同的作业，这就不符合我们所说的 “工程师文化”。我们需要达到的状态是，今天干完一件事，明天开启新的事。
|
|
|
|
|
|
怎么判断自己在做新的事情？那就要看我们问题是否解决得够彻底。
|
|
|
|
|
|
比如我在做新媒体运营，每天写着不同的公众号文章，这是否代表我在做新的事情？答案显然是不一定。要回答这个问题，我们首先需要搞清楚的是，我每天发公众号文章，是在解决一个什么样的问题。如果我们没有想清楚这一点，那么我们就不是在 Close 问题，我们只是在做任务而已。
|
|
|
|
|
|
我们的目标显然不应该是每天发一篇文章。这是在定义一件事务，而不是定义一个目标。把问题定义清楚非常非常重要。清楚了问题，就是设定清楚了我们的目标。然后才能谈得上去彻底解决掉它。
|
|
|
|
|
|
从另一个维度看，工程师这种把问题 Close，彻底解决掉的思维，看重的是自己工作内容的长期价值。如果我们只是在做事务，如果我们并没有在实质性解决一个问题，那么这件事情的长期价值就是零。
|
|
|
|
|
|
**所以本质上，工程师文化也是产品文化，把问题以一种自动化的方式解决。**这才是我们真正应该尊崇的工程师文化。
|
|
|
|
|
|
一个公司各个岗位是彼此协作的团队，工程师并不是特殊群体。销售、技术支持、产品、开发工程师每一个角色都是平等的。每个人都应该秉承工程师精神，把一个个问题 Close，让它不要再发生。不需要显得很忙，忙不代表成就，真正的工程师文化应该是推动整个团队往前走，每个团队成员都在成长。
|
|
|
|
|
|
## 系统化思维与批判精神
|
|
|
|
|
|
从更深层次来说，工程师思维是一种系统化的思维。仅仅是编码和自动化是不够的，很可能你编码也只是在实现某种事务性工作，而不是用系统性或者说结构化的方案来解决问题。
|
|
|
|
|
|
真正的工程师会系统化地考虑方案的有效性。他们追求的是用最小化的编码工作来解决更大范围的问题。
|
|
|
|
|
|
**少就是指数级的多！**
|
|
|
|
|
|
现实中，一些工程师经常对于自己编写的代码形成一种情感依附，这是人之常情。一些人可能会在你删除多余代码时提出抗议：“如果我们以后需要这个代码怎么办？”“我们为什么只是把这些代码注释掉，这样稍后再使用它的时候会更容易吗？”“为什么不增加一个功能开关？”
|
|
|
|
|
|
这些都是糟糕的建议。源代码管理系统中的回滚其实很容易，但大量的注释代码则会造成干扰和混乱，尤其是我们还要继续演进时。那些由于功能开关没有启用而没有被执行的代码，更是像一个个定时炸弹一样等待爆炸。
|
|
|
|
|
|
极端地说，当你指望一个软件 24 小时不间断服务时，在某种程度上来说每一行代码都是负担。所以 SRE 需要推崇的实践是保证所有的代码行都有必须存在的目的。
|
|
|
|
|
|
另外，从软件工程角度来说，传统意义上的工程强调的是复制性，但软件的编码却是一项不确定性很强的创新性工作，我们总在不断迭代出新的技术。所以软件工程是颇为复杂的东西，它需要在不确定性和复制性这对儿矛盾中平衡。
|
|
|
|
|
|
所以优秀的工程师还需要有批判精神。经验当然是有价值的，但过于相信惯例就会抑制创新能力。寻求本源，不迷信惯例和权威。以数据为指导，从根源出发去系统性解决问题。
|
|
|
|
|
|
## 结语
|
|
|
|
|
|
今天看起来我们的话题有了一次比较大的跳跃，谈起了工程师思维和工程师文化。但服务治理不是纯理论，没有简洁的抽象问题模型。我们面对的是现实世界的复杂性。这些现实的复杂性，背后是大量的事务工作，尤其是我们对问题还不够了解的时候。
|
|
|
|
|
|
这个时候，工程师思维在背后起到了关键性的支撑。正是我们坚持了批判精神，坚持了以系统化的思维来把问题彻底解决，才有今天服务治理系统的日新月异的发展。
|
|
|
|
|
|
如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们聊聊 “发布、升级与版本管理”。
|
|
|
|
|
|
如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。
|
|
|
|