DevOps 的意义
========================================
> 真正的组织文化变革有助于弥合你原以为无法跨过的鸿沟
回想一下你最近一次尝试改掉一个个人习惯的事情，你可能遇到过这样的情形，你需要改变你思考的方式并且改掉之前的习惯。这很艰难，你只能试着改变_你自己的_思维方式。
所以你可能会试着让自己置身于新的环境。新的环境实际上可帮助我们养成_新的_习惯，它反过来又会促成新的思维方式。
那就是能否成功改变的所在：思考的越多，得到的越多。你需要知道你在改变的原因以及你的目的所在（而不仅仅你要怎么做），因为改变本身往往是短暂和短视的。
现在想想你的 IT 组织需要做出的改变。也许你正在考虑采用像 DevOps 这样的东西。这个我们称之为 “DevOps” 的东西有三个组件：人、流程和工具。人和流程是_任何_团体组织的基础。因此，采用 DevOps 需要对大多数组织的核心进行根本性的改变，而不仅仅是学习新的工具。
如同其它的改变一样，它也是短视的。如果您将注意力集中在将改变作为单点解决方案 —— 例如，“获得更好的报警工具” —— 你可能只是管中窥豹。这种思维方式或许可以提供一套拥有更多铃声、口哨以及可以更好地处理呼叫轮询的工具，但是它不能解决这样的实际问题：警报不能送达到正确的团队，或者故障得不到解决，因为实际上没有人知道如何修复服务。
新的工具（或者至少一个新工具的想法）创造了一个讨论潜在问题的机会，可以让你的团队讨论对监控的看法。新工具让你能够做出更大的改变 —— 信仰和做法的改变 —— 它们作为你组织的基础而显得更加重要。
创造更深层次的变革需要一种可以全新地改变观念的方法。要找到这种方法，我们首先需要更好的理解变革的驱动力。
### 清除栅栏
> 就改革而言，它不同于推翻。这是一条直白且简单的原则，这个原则或许被视作悖论。在这种情况下，存在某种制度或法律；这么说吧，为了简单起见，在一条路上架设了一个栅栏或门。当今的改革者们来到这儿，并说：“我看不到它的用处，让我们把它清除掉。”更聪明的改革者会很好地回答：“如果你看不到它的用处，我肯定不会让你清除它，回去想想，然后你可以回来告诉我你知道了它的用处，我也许会允许你摧毁它。” — G.K Chesterton, 1929
为了了解对 DevOps 的需求 —— 它试图将传统意义上分开的开发部门和运维部门进行重新组合 —— 我们首先必须明白这个分开是如何产生的。一旦我们"知道了它的用处"，然后我们就会知道将它们分开是为了什么，并且在必要的时候可以取消分开。
今天我们没有一个单一的管理理论，但是大多数现代管理理论的起源可以追溯到弗雷德里克·温斯洛·泰勒。泰勒是一名机械工程师，他创建了一个衡量钢厂工人效率的系统。泰勒认为，他可以对工厂的劳动者运用科学分析的方法，不仅可以改进个人任务，也证明发现了有一个可以用来执行_任何_任务最佳方法。
我们可以很容易地画一个以泰勒为起源的历史树。从泰勒早在 18 世纪 80 年代后期的研究出现的时间运动研究和其他质量改进计划，跨越 20 世纪 20 年代一直到今天，我们可以从中看到六西格玛、精益，等等类似方法。自上而下、指导式管理，再加上研究过程的系统方法，主宰了今天主流商业文化。它主要侧重于把效率作为工人成功的测量标准。
如果泰勒是我们这颗历史树的根，那么我们主干上的下一个主叉将是 20 世纪 20 年代通用汽车公司的阿尔弗雷德·斯隆。通用汽车公司创造的斯隆结构不仅持续强劲到 21 世纪初，而且在未来五十年的大部分时间里，都将成为该公司的主要模式。
1920 年，通用公司正经历一场管理危机，或者说是缺乏管理的危机。斯隆向董事会写了一份为通用汽车的多个部门提出了一个新的结构《组织研究》。这一新结构的核心概念是“集中管理下放业务”。与雪佛兰，凯迪拉克和别克等品牌相关的各个部门将独立运作，同时为中央管理层提供推动战略和控制财务的手段。
在斯隆的建议下（以及后来就任 CEO 的指导下），通用汽车在美国汽车工业中占据了主导地位。斯隆的计划把一个处于灾难边缘公司创造成了一个非常成功的公司。从中间来看，自治单位是黑盒子，激励和目标被设置在顶层，而团队在底层推动。
泰勒思想的“最佳实践” —— 标准、可互换和可重复的行为 —— 仍然在今天的管理理念中占有一席之地，与斯隆公司结构的层次模式相结合，主导了僵化部门的分裂和孤岛化以实现最大的控制。
我们可以指出几份管理研究来证明这一点，但商业文化不是通过阅读书籍而创造和传播的。组织文化是 *真实的* 人在 *实际的* 情形下执行推动文化规范的 *具体的* 行为的产物。这就是为何类似泰勒和斯隆这样的理论变得固化而不可动摇的原因。
技术部门投资就是一个例子。以下是这个周期是如何循环的：投资者只投资于他们认为可以实现 *他们的* 特定成功观点的公司。这个成功的模式并不一定源于公司本身（和它的特定的目标）；它来自董事会对一家成功的公司 *应该* 如何看待的想法。许多投资者来自从经营企业的尝试和苦难中幸存下来的公司，因此他们对什么会使一个公司成功有 *不同的* 理念。他们为那些能够被教导模仿他们的成功模式的公司提供资金，希望获得资金的公司学会模仿。这样，初创公司孵化器就是一种重现理想的结构和文化的*直接的*方式。
“开发”和“运维”的分开不是因为人的原因，也不是因为不同的技能，或者放在新员工头上的一顶魔法分院帽；它是泰勒和斯隆的理论的副产品。责任与人员之间的清晰而不可渗透的界线是一个管理功能，同时也注重员工的工作效率。管理上的分开可以很容易的落在产品或者项目界线上，而不是技能上，但是通过今天的业务管理理论的历史告诉我们，基于技能的分组是“最好”的高效方式。
不幸的是，那些界线造成了紧张局势，这些紧张局势是由不同的管理链出于不同的目标设定的相反目标的直接结果。例如：
* 敏捷 ⟷ 稳定
* 吸引新用户 ⟷ 现有用户的体验
* 让应用程序增加新功能 ⟷ 让应用程序保持可用
* 打败竞争对手 ⟷ 维持收入
* 修复出现的问题 ⟷ 在问题出现之前就进行预防
今天，我们可以看到组织的高层领导人越来越认识到，现有的商业文化（并扩大了它所产生的紧张局势）是一个严重的问题。在 2016 年的 Gartner 报告中，57％ 的受访者表示，文化变革是 2020 年之前企业面临的主要挑战之一。像作为一种影响组织变革的手段的敏捷和 DevOps 这样的新方法的兴起反映了这一认识。“[影子 IT][7]” 的出现更是事物的另一个方面；最近的估计有将近 30％ 的 IT 支出在 IT 组织的控制之外。
这些只是企业正在面临的一些“文化担忧”。改变的必要性是明确的，但前进的道路仍然受到昨天的决定的约束。
### 抵抗并不是没用的
> Bert Lance 认为如果他能让政府采纳一条简单的格言“如果东西还没损坏，那就别去修理它”，他就可以为国家节省三十亿。他解释说：“这是政府的问题：‘修复没有损坏的东西，而不是修复已经损坏了的东西。’” — Nation's Business, 1977.5
通常，改革是组织针对所出现的错误所做的应对。在这个意义上说，如果紧张局势（即使逆境）是变革的正常催化剂，那么对变化的 *抵抗* 就是成功的指标。但是过分强调成功的道路会使组织变得僵硬、衰竭和独断。重视有效结果的政策导向是这种不断增长的僵局的症状。
传统 IT 部门的成功加剧了 IT 孤岛的壁垒。其他部门现在变成了“顾客”，而不是伙伴。试图将 IT 从成本中心转移出来创建一个新的操作模式，它可以将 IT 与其他业务目标断开。这反过来又会对敏捷性造成限制，增加摩擦，降低反应能力。合作被搁置转而偏向“专家方向”。结果是一个孤立主义的观点，IT 只能带来更多的伤害而不是好处。
正如“软件吃掉世界”，IT 越来越成为组织整体成功的核心。具有前瞻性的 IT 组织认识到这一点，并且已经对其战略规划进行了有意义的改变，而不是将改变视为恐惧。
例如，Facebook 与人类学家罗宾·邓巴就社会团体的方法进行了磋商，而且意识到这一点对公司成长的内部团体（不仅仅是该网站的外部用户）的影响。扎波斯的文化得到了很多的赞誉，该组织创立了一个部门，专注于培养他人对于核心价值观和企业文化的看法。当然，这本书是 《开放式组织》的姊妹篇，那是一本描述被应用于管理的开放原则 —— 透明度、参与度和社区 —— 可以如何为我们快节奏的互联时代重塑组织。
### 决心改变
> “如果外界的变化率超过了内部的变化率，那末日就不远了。” — Jack Welch, 2004
一位同事曾经告诉我他可以只用 “[信息技术基础设施库（ITIL）][9]” 框架里面的词汇向一位项目经理解释 DevOps。
虽然这些框架 *似乎* 是反面的，但实际上它们都集中在风险和变革管理上。它们简单地介绍了这种管理的不同流程和工具。在 IT 圈子外面谈论 DevOps 时，这一点需要注意。不要强调流程问题和故障，而是显示更小的变化引起的风险 *更小* 等等。这是强调改变团队文化的有益方式：专注于 *新的* 功能而不是老问题，是改变的有效中介，特别是当您采用别人的框架进行参考时。
改革不仅仅只是 *重构* 组织；它也是跨越历史上不可跨越的鸿沟的新途径 —— 通过拒绝把像“敏捷”和“稳定”这样的东西作为互相排斥的力量来解决我之前提到的那些紧张局势。建立注重 *结果* 胜过 *功能* 的跨部门团队是一个有效的策略。把不同的团队 —— 其中每个人的工作依赖于其他人 —— 聚集起来围绕一个项目或目标是最常见的方法之一。消除这些团队之间的摩擦和改善沟通能够产生巨大的改进 —— 即使在坚持铁仓管理结构时（如果可以掌握，则不需要拆除孤岛）。在这些情况下，对改革的 *抵抗* 不是成功的一个指标；而对改革的拥抱才是。
这些也不是“最佳实例”，它们只是一种检查你自己的栅栏的方式。每个组织都会有独特的、由他们内部人员创造的栅栏。一旦你“知道了它的用途”，你就可以决定它是需要拆解还是掌握。
** 本文是 Opensource.com 即将推出的关于开放组织和 IT 文化指南的一部分。[你可以在这注册以便当它发布时收到通知][5]**
（题图 : opensource.com）
--------------------------------------------------------------------------------
作者简介：
Matt Micene 是 Red Hat 公司的 Linux 和容器传播者。从架构和系统设计到数据中心设计，他在信息技术方面拥有超过 15 年的经验。他对关键技术（如容器，云计算和虚拟化）有深入的了解。他目前的重点是宣传红帽企业版 Linux，以及操作系统如何与计算环境的新时代相关。
------------------------------------------
via: https://opensource.com/open-organization/17/5/what-is-the-point-of-DevOps
作者：[Matt Micene][a]
译者：[zhousiyu325](https://github.com/zhousiyu325)
校对：[apemost](https://github.com/apemost)，[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/matt-micene
[1]:https://opensource.com/open-organization/resources/leaders-manual?src=too_resource_menu
[2]:https://opensource.com/open-organization/resources/field-guide?src=too_resource_menu
[3]:https://opensource.com/open-organization/resources/open-org-definition?src=too_resource_menu
[4]:https://opensource.com/open-organization/resources/open-decision-framework?src=too_resource_menu
[5]:https://opensource.com/open-organization/resources/book-series
[6]:https://opensource.com/open-organization/17/5/what-is-the-point-of-DevOps?rate=gOQvGqsEbNk_RSnoU0wP3PJ71E_XDYiYo7KS2HKFfP0
[7]:https://thenewstack.io/parity-check-dont-afraid-shadow-yet/
[8]:http://www.npr.org/2017/01/13/509358157/is-there-a-limit-to-how-many-friends-we-can-have
[9]:https://en.wikipedia.org/wiki/ITIL
[10]:https://opensource.com/user/18066/feed
[11]:https://opensource.com/open-organization/17/5/what-is-the-point-of-DevOps#comments
[12]:https://opensource.com/users/matt-micene