物料、工作中心、工艺路线、时段、计划、车间、MRP......每当这些字眼出现在我眼前，头脑中都会产生这样的疑问：我又不从事制造业，这些东西跟我有什么关系？

《凤凰项目》一书中，主人公比尔对此有着同样的疑问。

书中的他临危受命，被迫担任IT运维部门副总裁——之所以说“被迫”，是因为他完全不想搅和到公司的那堆烂摊子之中：大量如同在地板上被反复踩踏，直至发黑发硬的口香糖一般难以根除的IT有效性问题、高管因公司里的各种恶性事件频频登上新闻头条，审计师步步紧逼，“不怀好意”地试图挖掘出更多的头条新闻、公司押宝的“凤凰项目”则更是一个烂摊子，长时间延期、超预算，公司一再投入人力物力，然而项目本身却如同一头倔驴，你越是试图拉着它往前走，它越是拼命地在原地杵着。

正当比尔被折磨得死去活来之时，大神埃瑞克登场。公司高层非常重视埃瑞克，让比尔无论如何也要和他见一面。

比尔无可奈何地放下手头堆积如山的工作，却被埃瑞克带到公司MRP-8的生产车间，像是大学生被迫参观工厂一样，听他一一讲解车间的运作原理。

他指了指离我们最近的卸货道口边上的一张办公桌，说：“看到那张桌子了吗？”

我点点头，同时也毫不避讳地看了看手表：下午4点45分。

他对我的不耐烦不以为意，说：我来给你讲个故事吧。

听完一段长篇大论后，比尔悠悠说道：

“谢谢你给我上了一堂历史课。但我已经在工商学院学过这些了。我不明白这些和管理IT运维部有什么关系，管理IT运维部和管理工厂是不一样的。”

“哦，真的吗？”他转向我，眉头紧蹙，“我来猜一下。你会说，IT完全是知识工作，你们的工作就像手艺人的工作一样。因此，工作标准、流程说明，以及其他所有你钟爱的‘严明纪律’的条条框框都毫无用武之地。”

我皱了皱眉。我想不出他是想说服我相信一些我本已相信的事，还是想让我接受一个荒谬的结论。

“如果你认为IT运维部没有什么可向生产运营部学习的，那你就错了。大错特错。”他说，“作为IT运维部的副总裁，你的工作是确保形成一条迅速、可预测、持续不断的计划内工作流，从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏，那样你才能提供稳定的、可预期的、安全的IT服务。”

“你以为，和生产制造相比，IT运维是高深的学问？这完全是胡扯。”他不屑一顾地说，“在我看来，到现在为止，你们的所作所为都不过如此。这栋楼里的人可要比你们这些IT工作者更有创意，也更有胆量。”

他们站在车间的顶层，以一种俯视的视角去审视整个车间，埃瑞克试图向比尔说明，运维部门就如同这个车间，它们的运行模式是一致的，车间里使用的种种概念、理念等完全适用于对于运维部门工作的管理。

如果说之前比尔在运维部门的工作如同在一团迷雾中摸索，那么此时的他们则是以上帝视角去审视，从而得到一个全面的宏观图景。

对此，比尔仍将信将疑，但很快，他便开始用思考车间的方式来思考他的日常工作：

我怀疑自己可能站到了某种宏大而深远的图景边缘。埃瑞克问过我，在我的部门里，哪部分相当于工厂车间的工作任务发布台。变更管理和这个有关系吗？

突然间，我为自己这一连串的荒唐问题而笑出声来。我感觉像是加入了一个单人辩论俱乐部。或者是埃瑞克诱骗我钻进了某种哲学牛角尖。

在比尔的感染下，他的得力助手帕蒂也开始用这种方式来思考对于运维部门的管理工作：

帕蒂想了一会儿，说：“真奇怪。尽管我们有那么多项目、变更和报修的数据，却从来没有以这种方式把它们组织和联系起来过。”

“我想，这又是一件我们可以向制造部门学习的事。”她继续说，“我们正在做工业生产控制部所做的事。他们安排并监督所有的生产过程，以确保能够符合客户的需求。在接受一个订单时，他们会确认，每一个需要的工作中心都有足够的生产能力和必要的投入，可以在必要时加快工作进度。他们和销售经理、工厂经理一起排定生产计划，因此能够兑现他们作出的承诺。”

“我对自己学到的东西感到由衷的兴奋。生平第一次，我明白了我们应该怎样管理工作，即使是对这些简单的服务台任务也一样，我知道，一切都会大有改观的。”她指着房间前方的变更板说：“我真正期待的是把这些技术用于更加复杂的工作。一旦弄清楚最经常出现的任务是什么，我们就需要建立起工作中心和工作路径，就像我对服务请求所做的那样。我开始认为，这一整套工作中心的概念确实很好地描述了IT工作。在这个服务器设置的例子里，我们知道几乎每个业务项目和IT项目都要经过这个工作中心。”

为什么那些原本用于生产管理的概念、方法与理念能够适用于运维管理呢？又如何理解这种普适性呢？

我看了大量关于《凤凰项目》的书评，却从未见到一个人提出过相关的问题，人们在讨论时所使用的，仍然是“DevOps”、“敏捷开发”等IT领域的概念，完全忽略了书中埃瑞克以车间管理隐喻IT运维工作的做法。

而我认为，这些被人们忽略的东西恰恰是本书的关键所在。

接下来，笔者将试图剖析这一关键。

“洞察力”与本质

刘润这样定义“洞察力”：所谓洞察力，就是透过表象的层层迷雾，看到表象背后的系统的能力。

表象与系统

在书中，比尔曾这样感叹：

真是奇怪，现在我对IT世界的观察如此清晰，而且在我看来，它和几个月前相比又是如此迥异。

最开始比尔对于整个运维工作的认识，就是停留于系统表面的种种表象——灾难事件接二连三地发生，他和他的团队四处救火，忙得不可开交，但局面丝毫不见好转，因为他们所做的，都是“头痛医头，脚痛医脚”的症状解。

而真正有效的解决方案，是在洞悉了表象背后系统后，基于系统的运作原理所给出的根本解（杠杆解）。

埃瑞克带着比尔俯视车间，其目的正是以这种方式让比尔看到整个系统的运转模式，进而这种眼光来审视、理解其工作，这也是为什么他最后“对IT世界的观察如此清晰”但“和几个月前相比又是如此迥异”的原因——他对于工作的认识不再停留于日常的表面，而是基于对于系统的理解。

所谓“凡所有相,皆是虚妄;若见诸相非相,即见如来”，这种洞悉事物表象，直达本质，进一步带着对于事物本质的认知来采取行动的能力，是解决问题的关键。

麦当劳曾对奶昔进行多次改善，试图提高其销量。麦当劳不断地改进奶昔口感、增加更多的配料、巧克力，降低价格，但销量都不见改善，最后他们只好请来哈佛商学院的团队来共同解决这一问题。研究后发现，口感、味道、价格等都不是人们购买奶昔的主要原因，人们主要是为了应对在开车时的无聊，用吸管一口一口慢慢吃奶昔以解闷，相对于其他的食物，奶昔方便、不容易弄脏手，而且能吃很久，这才是人们购买奶昔的原因。

口感、味道、价格等因素如同层层迷雾，遮掩了事物的本质。凡人着相，因而其所见、所思、所行，皆是虚妄，正如《教父》中马里奥·普佐所说：花半秒钟就看透事物本质的人，和花一辈子都看不清事物本质的人，注定有着截然不同的命运。

埃隆·马斯克的“第一性原理”所强调的也是如此：

我确实认为每个人因该有一个良好的思维框架。这和物理学、第一性原理推理这方面相关。我认为，应该将事物剥离到最基本的事实基础上进行推理思考。

但是，为什么埃瑞克能通过这种方式理解IT运维工作的本质呢？为什么生产管理中的概念、理念与方法能够迁移到其他领域，并发挥如此巨大的作用呢？

我们可以通过查理·芒格所提出的所谓“多元思维模型”来理解这一点。

查理·芒格

查理·芒格与多元思维模型

什么是模型呢，芒格是这样定义的：

A model is ahuman construct to help us better understand the real world.

任何能够帮助你更好理解现实世界的人造框架，都是模型。

不同事物的本质往往是相通的，我们可以用同一套模型来理解大量不同的事物，一键直达其本质。《凤凰项目》一书中用生产管理来作为IT运维管理工作的隐喻，其原理便是如此，“物料、工作中心、工艺路线、时段、计划、车间”等概念实际上就是搭建了一个模型，这一模型无疑是具有普适性的。

查理·芒格所推崇的“多元思维模型”，正是强调要通过跨学科的方式，收集各个学科中那些具有普世意义的模型，并将这些模型组合起来，从而形成一个看待世界的宏观图景。

如芒格所说：

必须在头脑中拥有一些思维模型，必须依靠这些模型组成的框架来安排你的经验，包括间接的和直接的。

你必须把经验悬挂在头脑中的一个由许多思维模型组成的框架上。

在《穷查理宝典》中，芒格极为推崇的模型有：

复利原理、排列组合原理、费马帕斯卡系统、决策树理论、会计学、复式簿记、质量控制理论、后备系统、断裂点理论、质量概念、误判心理学、微观经济学、规模优势理论。

不难发现芒格是从数学、经济学、计算机科学、管理学、心理学、社会学等多个领域中广泛取材，那些看似非常“偏僻”的知识同样被他拿来，当作具有普适意义的工具。

基于此，笔者杜撰了一个概念：面向模型的学习。

面向模型的学习

芒格本人非常反对一种学习方式：

你也许已经注意到，有些学生试图死记硬背，以此来应付考试。他们在学校中是失败者，在生活中也是失败者。

他对于学习的建议是：

你首先必须要去学习关键学科中的这些 big ideas，然后你将这些模型串成网格，并确保在你的余生里可以对这个网格调用自如。

在学习一门学科时，我们非常容易陷入到一种“背诵模式”：眼看着大量的术语、理念，一段段的规则、条件，我们无所适从，最终选择就是将它们背下来，应付应付考试，皆大欢喜。

我们都知道要“理解”，可是要怎么“理解”？什么才是所谓的“理解”？

对此，我的想法是：与那些理论的提出者一起，去审视他们要解决的问题，进一步学习他们为了解决问题，提出了什么样的“模型”、又是如何提出这些“模型”的，以及是如何通过这些“模型”来解决那些棘手的问题的。

这种以“模型”为关注点的学习方式，是谓“面向模型的学习”。

像是美国IBM公司奥列基博士提出的“物料需求计划”这一解决方案，把企业生产中涉及到的所有产品、零部件、原材料、中间件等在逻辑上统一视为物料，再把企业生产中需要的各种物料分为独立需求与相关需求，从而奠定了MRP发展的理论基础。

这种“将XX抽象为XX”的思考方式，是大量学科的基础，像是在软件领域中：

文件是对I/O的抽象； 虚拟存储器是对物理存储器的抽象；进程是对一个正在运行的程序的抽象；Andorid 把一个移动应用程序抽象成Activity , Intent, Service,Provider等等。

理论的细节不是重点，关键在于站在那些理论创造者的视角，去思考问题本身、思考要创造什么样的模型、又怎样使用这些模型来解决问题——如芒格所强调的，学习时要关注那些“big ideas”。

而这些“模型”与创造“模型”的方式与能力是极具普适性的，是可以迁移到其他领域的——这才是我们学习的目的，不是成为复读机，而是成为creator、solver。