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