48 | 事务与工程：什么是工程师思维？

Oct 11, 2019



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

48 | 事务与工程：什么是工程师思维？

2019-10-11 许式伟来自北京

《许式伟的架构课》

课程介绍



讲述：丁伟

时长08:11大小7.49M



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

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 20

提建议

47 | 服务治理的宏观视角

49 | 发布、升级与版本管理

 写留言

精选留言(30)

humor
2019-10-11
“经验当然是有价值的，但过于相信惯例就会抑制创新能力。” 对于这句话不理解哎，许老师帮忙看一下啊 1、什么是过于相信惯例呢？如果对于一个问题，已经有了一个经过验证的惯例解决方案了，那我们还需要再去尝试其他非惯例的解决方案吗？如果去尝试其他解决方案可能会导致费时费力，最后使用的解决方案的效果有很大的可能还不如惯例解决方案。 2、创新能力与经验是呈负相关的吗？很多公司都很强调创新能力，那为了拥有比较强的创新能力，我们是不是就应该不去学习前辈的知识经验惯例了呢？但是不学习知识经验的话，可能连最基本的问题都解决不了了。
展开
作者回复: 1、是否应该创新与你的目标定义有关。如果你觉得花费几天时间从杭州到上海已经很好了，那么马车就足够了，但是4个小时你就得创造汽车，如果50分钟就要创造高铁。 2、学习前辈经验不能局限于技能本身。汽车和高铁并不是无中生有产生，也是前辈经验的产物。有种学习叫迁移学习，把旧经验应用到新领域中，大部分创新由此而来。
36
靠人品去赢
2019-10-12
不是工程师强势，是不强势可能被搞死，一张嘴两三天白干了。你突然来了个灵感要求立刻马上，你有没有考虑对现有业务的影响，工程的复杂度。实际上赚钱的业务部门才是真的强势，还是要听人家话的，按照人家的来。但是脱离事务型工作，确实有的时候是一种脱离舒适区的感受，成长是一件逆人性的事。
共 1 条评论
15
往事随风，顺其自然
2019-10-11
这个工程师地位问题，我要说句，看在什么公司，互联网还是传统行业，传统行业很低下
共 2 条评论
10
丁丁历险记
2019-11-08
我作为一个客户，可以保证，七牛的销售是绝对有地位的，几年前去找气流的时候，服务热情满满。现在再去找七牛，基本上对你爱搭不理。
作者回复: 有可能是客户交接出了问题？可以加我微信（xumingyu07）我们聊一下。
共 2 条评论
8
张裕
2019-10-11
重复性的事务确实是很多人的舒适区，很多时候会成为工程化改进的阻力，比如在测试部门推广测试自动化，在研发推广全栈开发。老师能不能分享下在推行工程师文化时的一些经验？
作者回复: 谈收益和目标，不从技术出发
共 2 条评论
8
业余爱好者
2020-02-22
即使是google这样看起来是技术驱动的公司，其实也是业务导向的。google的mapreduce,bigtable什么的技术确实很牛逼，但要是没有在业务上应用的产品（如搜索引擎），这些技术充其量就停留在理论层面。技术本身只有被使用了才有意义。所谓技术导向是指，一些大公司把技术看做一种基础设施，不断地丰富它。而发展哪个技术也是有选择的，最终还是看它落实成产品，用到业务上的可能性。不存在盲目的唯技术主义。不光技术，就连看似阳春白雪的科研，也是在一直盯着商业前景的。
展开
作者回复: 是这样。这个理解非常到位。所有投入只是一个商业化预期周期的问题。
7
Geek_88604f
2019-11-05
工程师文化是大众文化还是精英文化，不知道老师是倾向于哪一种？因为从现实情况来讲大多数公司中的工程师只负责某个模块或微服务的开发，他可以引入新技术把模块的开发工作到极致，但是可能缺乏全局视眼而没有往更高的层次发展。从另一个角度来讲，主要靠经验积累的技术工作是否属于老师讨论的工程师文化的范围？（例如:芯片行业的核心设备光刻机，其核心中的核心是光刻镜头，出人意料的是该镜头并非高精尖的机器打造的，而是人工打造的）另外，工程师文化和工匠精神有什么区别和联系，老师能不能谈谈这方面的看法？
展开
作者回复: 我觉得工程师文化不在于精英还是大众，在于思维方式。也许有人还不太擅长彻底解决问题，但是需要建立彻底解决问题的思考方式，以此获得不断改善的机会。工匠精神强调的是追求极致，工程师文化不只是要极致，它更在意极致的可复制性和代价。光刻镜头不能机械打磨，只是临时状态，并不代表以后不能，坚持这种想法这就是工程师文化。
共 2 条评论
6
技术修行者
2019-11-18
1. DRY，Don't Repeat Yourself。 2. 做事要平衡短期价值和长期价值，重复性的事务工作，没有长期价值，但往往是“舒适区”。 3. 工程师文化或者说工程师素质，不仅仅局限在软件开发领域，想一想工程师出现的时间，要远早于软件开发。 4. 工程师素质强调的是解决问题，而且是永久的高质量的解决问题，这在任何领域都是普适的。
展开
5
ky
2019-10-12
工程师以系统化的方式寻求较为彻底的解决方案，软件编码是手段之一，可能也是当今世界最为通用强大的手段。工程师需要不断迭代，不断改进系统以增强事务解决能力。技术的复杂与新奇不足以过于沉醉，能够用来解决问题的思路方才是价值。
作者回复: 👍
4
小名叫大明
2019-10-15
从我的经历看，做到商务，开发，产品平等基本是不可能的。举例如下: 项目型的公司，商务签单就是一个项目，如果有一个比较着急，原本3个月的排期所有程序员加班可以2个月完成［伴随bug多］，那么好，以后都是这个标准了，你要再说三个月，人家会说"上次两个月就完成了，这个也着急" （矛盾的本源可能也不是这里，矛盾的本源是工期压缩，所有人加班，待遇什么也不会变，身体垮了，身体垮了不能加班只能请你离开）
展开
4
tingye
2019-10-12
从小受的奉献精神教育，对个人职业发展有时候反而有害。应该花更多时间在有价值的事情上，解决问题同时提升自己，而不是脏活累活，实际上公司没人在乎你的苦劳，尤其传统行业
共 1 条评论
4
CoderLim
2019-10-11
1、用系统化结构化的方案 close 问题； 2、反思自己做的是新事，还是简单的重复； 3、代码只是工具。
4
花儿少年
2020-07-24
系统化思考更多是一种思维方式，如何培养这种思维方式，徐老师有没有推荐的书籍
作者回复: 把自己的知识尽可能串起来，这是一种系统化的思维训练。尽可能从反复要做的事务中抽象出更多的共性，这也是系统性思维。
2
程序员小跃
2019-11-26
一个公司各个岗位是彼此协作的团队，工程师并不是特殊群体。销售、技术支持、产品、开发工程师每一个角色都是平等的。每个人都应该秉承工程师精神，把一个个问题 Close，让它不要再发生。不需要显得很忙，忙不代表成就，真正的工程师文化应该是推动整个团队往前走，每个团队成员都在成长。这段话我要分享给公司的同事，其实大家都是平等的，都是为了团队而努力，并不存在所谓的优越感
展开
共 1 条评论
3
Aaron Cheung
2019-10-11
需要关注业务导向
2
耿梦雅
2020-10-11
我一直以为工程师是解决问题，现在理解了工程师是彻底的解决问题。
1
鸠摩·智
2021-06-24
许老师，能否谈一下您对工程师思维与完美主义和强迫症的看法。
张浩
2021-05-23
用彻底解决问题的工程师思维去解决问题，而不是每天去做长期价值是零的重复性工作。
不温暖啊不纯良
2021-05-18
看完老师这篇文章，我把自己昨天刚做完的功能，又完善了一下。昨天使用iview的级联选择器组件进行动态加载，发现里面有一个bug，那就是当用父节点的ID去查所有子节点的列表时，我们不知道这个子节点下面还有没有子节点，于是只能假设它有，但是当我把这个子节点作为父节点，去查询的时候发现他的下面已经没有子点了，于是需要根据数据结构的变化把它改成叶节点，但是发现修改不成功，最后只能放弃了这层节点，就是说它本来有三层节点，但是第3层节点不好处理成叶节点，于是我就把它的第2层节点当做叶节点处理了，这样取巧只是为了完成工作任务。
展开
xtepCool
2021-04-20
抽象问题模型的根据点在哪里呢，系统性思维的做法是什么样的
作者回复: 找到根本性的问题是最重要的，也就是加深我们对事情本质的认知。对事情认知不同，解决问题的方式就会不同，产生的效果也会有巨幅的差异。
1

