DevOps 的意义是什么？

想想您上次尝试改变个人习惯的情景。您可能到了需要改变思维方式，并减少习惯成为您身份一部分的程度。这很困难——而且您只是在尝试改变您自己的思维方式。

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

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

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

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

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

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

清除栅栏

“在改革事物（与破坏事物不同）方面，有一个简单明了的原则；一个可能被称为悖论的原则。在这种情况下，存在某种制度或法律；为了简单起见，我们假设在道路上竖立了栅栏或门。更现代的改革家兴高采烈地走到栅栏或门前说：“我看不出这有什么用；让我们把它清除掉。”而更聪明的改革家最好回答说：“如果您看不出它的用途，我当然不会让您清除它。走开去思考。然后，当您可以回来告诉我您确实看到了它的用途时，我可能会允许您摧毁它。”——G.K. 切斯特顿，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 文化变革指南》的一部分。