2012年，美国科技媒体ZDNET刊载过一篇名为《Why the smart engineer is a lazy engineer》（《为什么聪明的工程师是懒惰的工程师》）的文章。
这篇文章提到说，懒惰的工程与横向思维有许多共同之处。
如果一个问题看起来很难解决或者太复杂，那么可以从另一个更容易的角度来处理它。作为一个工程师或设计师，为你做些简单的事情通常会使产品更容易使用和销售。
是的，“懒”（lazy）并不等于“怠惰”（sloth）。
一个怠惰的工程师，最喜欢的事大概就是无所事事的呆坐着，甚至尽量逃避工作。但真正聪明的工程师会用最有效率的方式赶快把事情做好。
在华为中国企业运维峰会2019上，华为EBG中国区专业服务部部长王辉提到了一个案例：
华为EBG中国区专业服务部部长王辉
华为在全球有超过200个数据中心，30多万台服务器在支撑华为的业务。经过30年的发展，现在30多个人喝着咖啡就可以把200多个数据中心运营做了。
这种“喝着咖啡”搞运维和“爬烟囱”式的运维，有着天壤之别。
一
“爬烟囱”
此前我在《华为让运维“拔掉烟囱”》一文中提到，过往企业、组织“烟囱式”的IT系统给运维环节造成了无尽的困难。
在IT系统建设阶段，企业各个部门按照自身需要建设了一套封闭的系统，这套系统的数据无法打通共享，完全处于黑洞状态。
所谓“烟囱式”的系统大概就是16个字：各自为政、条块分割、孤岛林立、信息割裂。
实际上，华为EBG中国区运维总监赵建波在华为中国企业运维峰会2019上就提到，某客户2018年7月，反馈业务数据无法上传。
华为EBG中国区运维总监赵建波
造成这个局面的原因主要是三个。第一是缺乏上云的评估，无法对业务部门的资源申请进行评估，第二是对不合理的资源浪费没有回收机制。第三是资源规划与业务发展规划不一致。
这恰恰正是很多“烟囱型” IT系统的普遍问题。
这样的“烟囱式”系统最后也造就了“爬烟囱式”的运维——传统分散式人工运维。
这种运维大多是被动式的手动维护管理，缺少有效的流程管控机制，运维工作总是处于“救火式”状态。事前无准备，事中无跟踪，事后无法追溯，运维经验无法沉淀积累与复用。最终的结果就是运维成本高、效率低。
运维工作人员日常大部分时间和精力都花在处理一些简单重复的问题上。而这些运维工作大多数却对企业业务系统的稳定运行帮助很小。
最终的结果是，同样的问题反复出现、反复犯错、反复解决，企业资源浪费严重。
此前知乎上有过这样一个提问，为什么都说运维工程师做不长久？
一位运维工程师在问题下面的回答是：
随着公司业务发展， IT系统越来越多，已经力不从心了。每天都在添加账户，添加管理配置，跑机房重装系统，管理的机器已经乱成一锅粥了，累还效率低下。
“烟囱式”的IT系统里做运维，每次出现问题之后，工程师就像是“爬烟囱”的工人一样，在一个个“烟囱”之中找问题。
“烟囱”里面流程复杂，问题搜寻的过程漫无目的，要花大量时间才能找到故障，最后运维工作完成后工程师也是灰头土脸。
