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