DevOps 的意义是什么？

想想您上次尝试改变个人习惯的情景。您可能遇到一个需要改变思维方式的节点，并让该习惯不再是您身份认同的一部分。这很困难——而且您只是在尝试改变您自己的思维方式。

因此，您可能尝试将自己置于新的环境中。新的环境实际上可以帮助我们养成新的习惯，进而带来新的思维方式。

这就是成功变革的关键：它与展望和结果息息相关。您需要知道您为什么要改变以及您要去向何方（而不仅仅是您打算如何做），因为为改变而改变通常是短暂且目光短浅的。

现在想想您的 IT 组织需要做出的改变。也许您正在考虑采用类似 DevOps 的东西。我们称之为“DevOps”的东西包含三个组成部分：人员、流程和工具。人员和流程是任何组织的基础。因此，采用 DevOps 需要对大多数组织的核心进行根本性变革——而不仅仅是学习新工具。

并且像任何改变一样，它可能是目光短浅的。如果您将变革视为一个点解决方案——例如“获得更好的工具来进行警报”，您可能会对问题产生狭隘的看法。这种思维模式可能会提供一个具有更多花哨功能和更好处理轮班待命方式的工具。但这无法解决警报没有发送给正确的团队，或者这些故障仍然是故障，因为实际上没有人知道如何修复服务的事实。

新工具（或至少是新工具的想法）创造了一个时刻，让人们可以讨论困扰您的团队对监控的看法的根本问题。新工具使您可以进行更大的改变——改变您的信念和实践——这作为您组织的基础，甚至更为重要。

创造更深层次的变革需要全新的变革理念。为了发现这些方法，我们需要更好地了解变革的最初驱动力。

清除栅栏

“在改革事物的问题上，与破坏事物不同，有一个简单明了的原则；一个可能被称为悖论的原则。在这种情况下，存在某种制度或法律；为了简单起见，我们假设在道路上竖立了栅栏或大门。更现代的改革者会兴高采烈地走到它面前说：“我看不出这有什么用；让我们把它清除掉。”对此，更聪明的改革者会很好地回答：“如果您看不出它的用途，我当然不会让您把它清除掉。走开并思考。然后，当您回来告诉我您确实看到了它的用途时，我可能会允许您摧毁它。”——G.K Chesterton，1929 年

要理解 DevOps 的必要性，DevOps 试图重新组合传统上“分裂”的“开发”和“运维”实体，我们必须首先理解这种分裂是如何产生的。一旦我们“知道它的用途”，我们就可以看清分裂的真面目——并在必要时将其拆除。

今天我们没有单一的管理理论，但我们可以将大多数现代管理理论的起源追溯到弗雷德里克·温斯洛·泰勒。泰勒是一位机械工程师，他创建了一个系统来衡量钢铁厂工人的效率。泰勒认为，他可以将科学分析应用于工厂的工人，不仅可以改进个人任务，还可以证明存在一种可发现的最佳方法来执行任何任务。

我们可以轻松地绘制一棵以泰勒为根的历史树。从泰勒在 1880 年代后期的早期努力中，出现了工时研究和其他质量改进计划，这些计划跨越了 1920 年代一直到今天，我们看到了六西格玛、精益生产等。自上而下、指令式的管理风格，加上对流程进行方法论研究的方法，在当今主流商业文化中占据主导地位。它主要关注效率，将其作为衡量工人成功的主要标准。

如果泰勒是我们历史树的根，那么我们树干中的下一个主要分支将是 1920 年代通用汽车公司的阿尔弗雷德·P·斯隆。斯隆在通用汽车公司创建的结构不仅在 2000 年代之前在那里保持稳固，而且还被证明是未来 50 年大部分公司的主流模式。

1920 年，通用汽车公司正经历一场管理危机——或者更确切地说，是一场因缺乏管理而引起的危机。斯隆为董事会撰写了他的“组织研究”，为通用汽车公司的众多部门提出了新的结构。这种新结构以“权力下放运营，集中控制”的概念为中心。现在与雪佛兰、凯迪拉克和别克等品牌相关的各个部门将独立运营，同时为中央管理层提供推动战略和控制财务的手段。

在斯隆的建议（以及后来的首席执行官指导下），通用汽车公司在美国汽车行业中占据了主导地位。斯隆的计划将一家濒临灾难的公司变成了一家非常成功的公司。从中心视角来看，自治单元是黑匣子。激励措施和目标在最高层设定，底层的团队努力交付。

泰勒的“最佳实践”理念——标准、可互换和可重复的行为——在今天的管理理念中仍然占有一席之地，它与斯隆公司结构的层级模型相结合，后者提倡严格的部门划分和孤岛，以实现最大程度的控制。

我们可以指出一些管理研究来证明这一点。但商业文化不仅仅是通过读书来创造和传播的。组织文化是真实的人在实际情况下执行具体行为的产物，这些行为随着时间的推移推动了文化规范。泰勒主义和斯隆主义就是这样被巩固并显得不可动摇的。

科技行业的融资就是一个例证。以下是循环运作方式：投资者只投资于他们认为可以实现他们特定成功观的公司。这种成功模式不一定源于公司本身（及其特定目标）；它来自董事会对一家成功的公司应该是什么样子的想法。许多投资者来自经历过经营企业考验和磨难的公司，因此，他们对一家成功的公司应该是什么样子有不同的蓝图。他们资助那些可以被教导模仿其成功模型的公司。因此，希望获得资金的公司学会模仿。通过这种方式，创业孵化器是复制所谓的理想结构和文化的直接方式。

“开发”和“运维”的分裂不是性格、技能分歧或戴在新员工头上的魔法帽造成的；它是泰勒主义和斯隆主义的副产品。职责和人员之间清晰且不可逾越的界限是一种管理职能，它与对工人效率的关注相结合。管理上的分裂很容易落在产品或项目边界上，而不是技能上，但今天的商业管理理论历史告诉我们，基于技能的分组是提高效率的“最佳”方式。

不幸的是，这些边界会产生紧张关系，而这些紧张关系是不同管理链条设定具有不同目标的对立目标所直接造成的。例如

今天，我们可以看到组织高层领导人越来越认识到，现有的商业文化（以及由此产生的一系列紧张关系）是一个严重的问题。在 2016 年 Gartner 报告中，57% 的受访者表示，文化变革是 2020 年之前企业面临的主要挑战之一。敏捷和 DevOps 等新方法的兴起作为影响组织变革的手段，反映了这种认识。“影子 IT”的兴起是硬币的另一面；最近的估计表明，近 30% 的 IT 支出不受 IT 组织的控制。

这些只是企业正在面临的一些“文化问题”。变革的必要性显而易见，但未来的道路仍然受昨天决策的支配。

抵制并非徒劳

“伯特·兰斯认为，如果他能让政府采纳一句简单的座右铭：‘没坏的东西，就别修’，他就能为山姆大叔节省数十亿美元。他解释说：‘这就是政府的问题：修理没坏的东西，而不修理坏了的东西。’”——《国家商业》，1977 年 5 月

通常，变革是组织对出现问题的响应。从这个意义上讲，如果紧张（甚至逆境）是变革的正常催化剂，那么对变革的抵制就是成功的指标。但过度强调成功的道路可能会使组织变得僵化、保守和教条。重视政策导航而不是有效结果是这种日益僵化的症状。

传统 IT 部门的成功加厚了 IT 孤岛的围墙。其他部门现在是“客户”，而不是同事。试图将 IT 从成本中心转变出来，创造了一种新的运营模式，将 IT 与企业其余的目标脱节。这反过来又产生了限制敏捷性、增加摩擦和降低响应能力的阻力。协作被搁置，转而支持“专家指导”。结果是对 IT 的孤立主义观点只能弊大于利。

然而，随着“软件吞噬世界”，IT 在组织的整体成功中变得越来越重要。具有前瞻性思维的 IT 组织认识到这一点，并且已经在有意识地改变他们的剧本，而不是将变革视为需要恐惧的东西。

例如，Facebook 咨询了人类学家罗宾·邓巴，了解其对社交群体的方法，但意识到这对其内部群体（而不仅仅是网站的外部用户）的影响，随着公司的发展而增长。Zappos 的文化获得了如此多的赞誉，以至于该组织创建了一个部门，专注于培训其他人在其核心价值观和企业文化方面的观点。当然，本书是《开放组织》的配套书籍，《开放组织》展示了应用于管理的开放原则——透明度、参与度和社区——如何为我们快节奏、互联互通的时代重塑组织。

决心改变

“如果外部变化的速度超过内部变化的速度，末日就不远了。”——杰克·韦尔奇，2004 年

一位同事曾经告诉我，他可以使用 信息技术基础设施库 框架的词汇向项目经理解释 DevOps。

虽然这些框架看起来是相互对立的，但它们实际上都以风险和变更管理为中心。它们只是为此类管理提供了不同的流程和工具。当在 IT 部门之外谈论 DevOps 时，这一点很重要。与其强调流程崩溃和失败，不如展示较小的变更如何引入更少的风险等等。这是一种突出改变团队文化的好处的有力方法：关注新的能力而不是旧的问题是变革的有效推动力，尤其是在您采用别人的参考框架时。

变革不仅仅是重建组织；它还关系到跨越历史上无法逾越的鸿沟的新方法——通过拒绝将“敏捷性”和“稳定性”等事物定位为互斥的力量来解决我之前映射的那些紧张关系。建立专注于结果而非职能的跨部门团队是正在实施的策略之一。将不同团队（每个团队的工作都依赖于其他团队）围绕单一项目或目标聚集在一起是最常见的方法之一。消除这些团队之间的摩擦并改善沟通可以产生巨大的改进——即使坚持管理层的铁腕孤岛结构（如果可以掌握孤岛，则无需拆除它们）。在这些情况下，对变革的抵制不是成功的指标；拥抱变革才是。

这些不是“最佳实践”。它们只是一种让您检查自己的栅栏的方法。每个组织都有由内部人员创建的独特栅栏。一旦您“知道它的用途”，您就可以决定是否需要拆除或掌握它。

本文是《开放组织 IT 文化变革指南》的一部分。