document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-03-03 01:10:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

翻译完20170516 What's the point of DevOps.md

Browse Source
This commit is contained in:
zhousiyu325 2017-06-06 21:22:21 +08:00
parent 91e23ef2d8
commit 79d85c7ee7
2 changed files with 73 additions and 137 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

137
sources/tech/20170516 What's the point of DevOps.md
View File

@ -1,137 +0,0 @@
翻译中 zhousiyu325
What's the point of DevOps?
============================================================
### True organizational culture change helps you bridge the gaps you thought were uncrossable.
![What's the point of DevOps?](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/BUSINESS_creativity.png?itok=x2HTRKVW "What's the point of DevOps?")
>Image by : opensource.com
Think about the last time you tried to change a personal habit. You likely hit a point where you needed to alter the way you think and make the habit less a part of your identity. This is difficult—and you're only trying to change  _your own_  ways of thinking.
So you may have tried to put yourself in new situations. New situations can actually help us create  _new_  habits, which in turn lead to new ways of thinking.
That's the thing about successful change: It's as much about  _outlook_  as  _outcome_ . You need to know  _why_  you're changing and  _where_  you're headed (not just how you're going to do it), because change for its own sake is often short-lived and short-sighted.
Now think about the changes your IT organization needs to make. Perhaps you're thinking about adopting something like DevOps. This thing we call "DevOps" has three components: people, process, and tools. People and process are the basis for  _any_  organization. Adopting DevOps, therefore, requires making fundamental changes to the core of most organizations—not just learning new tools.
Open Organization resources
* [Download the Open Organization Leaders Manual][1]
* [Download the Open Organization Field Guide][2]
* [What is an Open Organization?][3]
* [What is an Open Decision?][4]
And like any change, it can be short-sighted. If you're focused on the change as a point solution—"Get a better tool to do alerting," for example—you'll likely come up with a narrow vision of the problem. This mode of thinking may furnish a tool with more bells and whistles and a better way of handling on-call rotations. But it can't fix the fact that alerts aren't going to the right team, or that those failures remain failures since no one actually knows how to fix the service.
The new tool (or at least the idea of a new tool) creates a moment to have a conversation about the underlying issues that plague your team's views on monitoring. The new tool allows you to make bigger changes—changes to your beliefs and practices—which, as the foundation of your organization, are even more important.
Creating deeper change requires new approaches to the notion of change altogether. And to discover those approaches, we need to better understand the drive for change in the first place.
### Clearing the fences
> "In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."—G.K Chesterton, 1929
To understand the need for DevOps, which tries to recombine the traditionally "split" entities of "development" and "operations," we must first understand how the split came about. Once we "know the use of it," then we can see the split for what it really is—and dismantle it if necessary.
Today we have no single theory of management, but we can trace the origins of most modern management theory to Frederick Winslow Taylor. Taylor was a mechanical engineer who created a system for measuring the efficiency of workers at a steel mill. Taylor believed he could apply scientific analysis to the laborers in the mill, not only to improve individual tasks, but also to prove that there was a discoverable best method for performing  _any_  task.
We can easily draw a historical tree with Taylor at the root. From Taylor's early efforts in the late 1880s emerged the time-motion study and other quality-improvement programs that span the 1920s all the way to today, where we see Six Sigma, Lean, and the like. Top-down, directive-style management, coupled with a methodical approach to studying process, dominates mainstream business culture today. It's primarily focused on efficiency as the primary measure of worker success.
>The "Dev" and "Ops" split is not the result of personality, diverging skills, or a magic hat placed on the heads of new employees; it's a byproduct of Taylorism and Sloanianism.
If Taylor is our root of our historical tree, then our next major fork in the trunk would be Alfred P. Sloan of General Motors in the 1920s. The structure Sloan created at GM would not only hold strong there until the 2000s, but also prove to be the major model of the corporation for much of the next 50 years.
In 1920, GM was experiencing a crisis of management—or rather a crisis from the lack thereof. Sloan wrote his "Organizational Study" for the board, proposing a new structure for the multitudes of GM divisions. This new structure centered on the concept of "decentralized operations with centralized control." The individual divisions, associated now with brands like Chevrolet, Cadillac, and Buick, would operate independently while providing central management the means to drive strategy and control finances.
Under Sloan's recommendations (and later guidance as CEO), GM rose to a dominant position in the US auto industry. Sloan's plan created a highly successful corporation from one on the brink of disaster. From the central view, the autonomous units are black boxes. Incentives and goals get set at the top levels, and the teams at the bottom drive to deliver.
The Taylorian idea of "best practices"—standard, interchangeable, and repeatable behaviors—still holds a place in today's management ideals, where it gets coupled with the hierarchical model of the Sloan corporate structure, which advocates rigid departmental splits and silos for maximum control.
We can point to several management studies that demonstrate this. But business culture isn't created and propagated only through reading books. Organizational culture is the product of  _real_  people in  _actual_  situations performing  _concrete_  behaviors that propel cultural norms through time. That's how things like Taylorism and and Sloanianism get solidified and come to appear immovable.
Technology sector funding is a case in point. Here's how the cycle works: Investors only invest in those companies they believe could achieve  _their_  particular view of success.  This model for success doesn't necessarily originate from the company itself (and its particular goals); it comes from a board's ideas of what a successful company  _should_  look like. Many investors come from companies that have survived the trials and tribulations of running a business, and as a result they have  _different_  blueprints for what makes a successful company. They fund companies that can be taught to mimic their models for success. So companies wishing to acquire funding learn to mimic. In this way, the start-up incubator is a  _direct_  way of reproducing a supposedly  _ideal_  structure and culture.
The "Dev" and "Ops" split is not the result of personality, diverging skills, or a magic hat placed on the heads of new employees; it's a byproduct of Taylorism and Sloanianism. Clear and impermeable boundaries between responsibilities and personnel is a management function coupled with a focus on worker efficiency. The management split could have easily landed on product or project boundaries instead of skills, but the history of business management theory through today tells us that skills-based grouping is the "best" way to be efficient.
Unfortunately, those boundaries create tensions, and those tensions are a direct result of opposing goals set by different management chains with different objectives. For example:
Agility ⟷ Stability
Drawing new users ⟷ Existing users' experience
Application getting features ⟷ Application available to use
Beating the competition ⟷ Protecting revenue
Fixing problems that come up ⟷ Preventing problems before they happen
Today, we can see growing recognition among organizations' top leaders that the existing business culture (and by extension the set of tensions it produces) is a serious problem. In a 2016 Gartner report, 57 percent of respondents said that culture change was one of the major challenges to the business through 2020\. The rise of new methods like Agile and DevOps as a means of affecting organizational changes reflects that recognition. The rise of "[shadow IT][7]" is the flip side of the coin; recent estimates peg nearly 30 percent of IT spend outside the control of the IT organization.
These are only some of the "culture concerns" that business are having. The need to change is clear, but the path ahead is still governed by the decisions of yesterday.
### Resistance isn't futile
> "Bert Lance believes he can save Uncle Sam billions if he can get the government to adopt a simple motto: 'If it ain't broke, don't fix it.' He explains: 'That's the trouble with government: Fixing things that aren't broken and not fixing things that are broken.'" — Nation's Business, May 1977
Typically, change is an organizational response to something gone wrong. In this sense, then, if tension (even adversity) is the normal catalyst for change, then the  _resistance_  to change is an indicator of success. But overemphasis on successful paths can make organizations inflexible, hidebound, and dogmatic. Valuing policy navigation over effective results is a symptom of this growing rigidity.
Success in traditional IT departments has thickened the walls of the IT silo. Other departments are now "customers," not co-workers. Attempts to shift IT  _away_  from being a cost-center create a new operating model that disconnects IT from the rest of the business' goals. This in turn creates resistance that limits agility, increases friction, and decreases responsiveness. Collaboration gets shelved in favor of "expert direction." The result is an isolationist view of IT can only do more harm than good.
And yet as "software eats the world," IT becomes more and more central to the overall success of the organization. Forward-thinking IT organizations recognize this and are already making deliberate changes to their playbooks, rather than treating change as something to fear.
>Change isn't just about rebuilding the organization; it's also about new ways to cross historically uncrossable gaps.
For instance, Facebook consulted with [anthropologist Robin Dunbar][8] on its approach to social groups, but realized the impact this had on internal groups (not just external users of the site) as the company grew. Zappos' culture has garnered so much praise that the organization created a department focused on training others in their views on core values and corporate culture. And of course, this book is a companion to  _The Open Organization_ , a book that shows how open principles applied to management—transparency, participation, and community—can reinvent the organization for our fast-paced, connected era.
### Resolving to change
> "If the rate of change on the outside exceeds the rate of change on the inside, the end is near."—Jack Welch, 2004
A colleague once told me he could explain DevOps to a project manager using only the vocabulary of the [Information Technology Infrastructure Library][9] framework.
While these frameworks  _appear_  to be opposed, they actually both center on risk and change management. They simply present different processes and tools for such management. This point is important to note when to talking about DevOps outside IT. Instead of emphasizing process breakdowns and failures, show how smaller changes introduce  _less_  risk, and so on. This is a powerful way to highlight the benefits changing a team's culture: Focusing on the  _new_  capabilities instead of the  _old_  problems is an effective agent for change, especially when you adopt someone else's frame of reference.
Change isn't just about  _rebuilding_  the organization; it's also about new ways to cross historically uncrossable gaps—resolving those tensions I mapped earlier by refusing to position things like "agility" and "stability" as mutually exclusive forces. Setting up cross-silo teams focused on  _outcomes_  over  _functions_  is one of the strategies in play. Bringing different teams, each of whose work relies on the others, together around a single project or goal is one of the most common approaches. Eliminating friction between these teams and improving communications yields massive improvements—even while holding to the iron silo structures of management (silos don't need to be demolished if they can be mastered). In these cases,  _resistance_  to change isn't an indicator of success; an embrace of change is.
These aren't "best practices." They're simply a way for you to examine your own fences. Every organization has unique fences created by the people within it. And once you "know the use of it," you can decide whether it needs dismantling or mastering.
_This article is part of Opensource.com's forthcoming guide to open organizations and IT culture. [Register to be notified][5] when it's released._
--------------------------------------------------------------------------------
作者简介：
Matt Micene - Matt Micene is an evangelist for Linux and containers at Red Hat. He has over 15 years of experience in information technology, ranging from architecture and system design to data center design. He has a deep understanding of key technologies, such as containers, cloud computing and virtualization. His current focus is evangelizing Red Hat Enterprise Linux, and how the OS relates to the new age of compute environments.
------------------------------------------
via: https://opensource.com/open-organization/17/5/what-is-the-point-of-DevOps
作者：[Matt Micene ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [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

73
translated/tech/20170516 What's the point of DevOps.md
View File

@ -54,3 +54,76 @@ DevOps 的意义
我们可以指出几份管理研究来证明这一点，但商业文化不是通过阅读书籍而创造和传播的。组织文化是 *真实的* 人在 *实际的* 情形下执行推动文化规范的 *具体的* 行为的产物。这就是为何类似 Taylor 和 Sloan 的主张这样的事情变得固化而不可动摇的原因。
技术部门投资就是一个例子。以下是这个周期是如何循环的：投资者只投资于他们认为可以实现 *他们的* 特定成功观点的公司。这个成功的模式并不一定源于公司本身（和它的特定的目标）；它来自董事会对一家成功的公司 *应该* 如何看待的想法。许多投资者来自在经营企业的尝试和苦难中幸存下来的公司，因此他们对什么会使一个公司成功有 *不同的* 蓝图。他们为那些能够被教导模仿他们的成功模式的公司提供资金所以希望获得资金的公司学会模仿。 这样，初创公司孵化器就是一种重现理想的结构和文化的直接的方式。
开发和运维的分开是不是因为人原因，不同的技能，或者放在新员工头上的一顶魔术帽；它是 Taylor 和 Sloan 的理论的副产品。责任与人员之间的透明和不可渗透的界线是一个管理功能，同时也注重员工的工作效率。管理上的分开可以很容易的落在产品或者项目界线上，而不是技能上，但是通过今天的业务管理理论的历史告诉我们，基于技能的分组是“最好”的高效方式。
不幸的是，那些界线造成了紧张局势，这些紧张局势是由不同的管理链出于不同的目标设定的相反目标的直接结果。例如：
* 敏捷 ⟷ 稳定
* 吸引新用户 ⟷ 现有用户的体验
* 让应用程序增加新功能 ⟷ 让应用程序可以使用
* 打败竞争对手 ⟷ 保护收入
* 修复出现的问题 ⟷ 在问题出现之前就进行预防
今天，我们可以看到组织的高层领导人越来越认识到，现有的商业文化（并扩大了它所产生的紧张局势）是一个严重的问题。在2016年的 Gartner 报告中，57％的受访者表示，文化变革是2020年之前企业面临的主要挑战之一。像作为一种影响组织变革的的手段的敏捷和DevOps这样的新方法的兴起反映了这一认识。"[shadow IT][7]" 的出现是硬币的反面；最近的估计有将近30％的 IT 支出在IT组织的控制之外。
这些只是企业正在面临的一些“文化担忧”。改变的必要性是明确的，但前进的道路仍然受到昨天的决定的约束。
### 抵抗并不是没用的
> "Bert Lance believes he can save Uncle Sam billions if he can get the government to adopt a simple motto: 'If it ain't broke, don't fix it.' He explains: 'That's the trouble with government: Fixing things that aren't broken and not fixing things that are broken.'" — Nation's Business, May 1977
通常，改革是组织针对所出现的错误所做的应对。 在这个意义上说，如果紧张局势（即使逆境）是变革的正常催化剂，那么 *抵抗* 变化就是成功的指标。但是过分强调成功的道路会使组织变得僵硬、衰竭和独断。 重视有效结果的政策导航是这种不断增长的僵局的症状。重视有效结果的政策导航是这种不断增长的僵局的症状。
传统IT部门的成功加剧了 IT 仓库的墙壁。其他部门现在变成了"顾客"，而不是同事。试图将 IT 从成本中心转移出来创建一个新的操作模式，它可以将 IT 与其他业务目标断开。这反过来又会对敏捷性造成限制，增加摩擦，降低反应能力。合作被搁置而支持“专家方向”。结果是一个孤立主义的观点，IT 只能带来更多的伤害而不是好处。
正如“软件吃掉世界”，IT 越来越成为组织整体成功的核心。具有前瞻性的IT组织认识到这一点，并且已经对其战略规划进行了有意义的改变，而不是将改变视为恐惧。
>Change isn't just about rebuilding the organization; it's also about new ways to cross historically uncrossable gaps.
例如，Facebook与人类学家罗宾·邓巴（Robin Dunbar）就社会团体的方法进行了磋商，而且意识到这一点对公司成长的内部团体（不仅仅是网站的外部用户）的影响。扎波斯的文化得到了很多的赞誉，该组织创立了一个部门，专注于培养他人对于核心价值观和企业文化的看法。当然，这本书是 _The Open Organization_ 的姊妹篇， 一本描述被应用于管理的开放原则——透明度、参与度和社区——可以如何为我们快节奏的有连系的时代重塑组织。
### 决心改变
> "If the rate of change on the outside exceeds the rate of change on the inside, the end is near."—Jack Welch, 2004
一位同事曾经告诉我他可以只用 [Information Technology Infrastructure Library][9] 框架里面的词汇向一位项目经理解释 DevOps。
虽然这些框架 *似乎* 是反对的，但实际上它们都集中在风险和变革管理上。他们简单地介绍了这种管理的不同流程和工具。在 IT 圈子外面谈论 DevOps 时，这一点需要注意。不要强调流程故障和故障，而是显示更小的变化引起的风险 *更小* 等等。这是强调改变团队文化的有益方式：专注于 *新的* 功能而不是老问题是改变的有效代理，特别是当您采用别人的参考框架时。
改革不仅仅只是 *重构* 组织；它也是关于跨越历史上不可跨越的鸿沟的新途径——通过拒绝把像“敏捷”和“稳定”这样的东西作为互相排斥的力量来解决我之前提到的那些紧张局势。建立注重 *结果* 胜过 *功能* 的跨部门团队是一个有效的策略。把不同的团队——其中每个人的工作依赖于其他人——聚集起来围绕一个项目或目标是最常见的方法之一。消除这些团队之间的摩擦和改善沟通能够产生巨大的改进——即使在坚持铁仓管理结构时（如果可以掌握，则不需要拆除筒仓）。在这些情况下，*抵抗* 改革不是成功的一个指标；而拥抱改革是一个指标。
这些也不是“最佳实例”，它们只是一种检查你自己的栅栏的方式。每个组织都会有独特的由他们内部人员创造的栅栏。一旦你“知道了它的用途”，你就可以决定它是需要拆解还是掌握。
** 本文是 Opensource.com 即将推出的关于开放组织和IT文化指南的一部分。[你可以在这注册以便当它发布时收到通知][5]
--------------------------------------------------------------------------------
作者简介：
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)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [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