From e6d001dca6c178aaaca427de4efce4332ce57421 Mon Sep 17 00:00:00 2001 From: zhousiyu325 Date: Wed, 31 May 2017 08:46:01 +0800 Subject: [PATCH 1/5] =?UTF-8?q?=E7=BF=BB=E8=AF=9120170516=20What's=20the?= =?UTF-8?q?=20point=20of=20DevOps.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- sources/tech/20170516 What's the point of DevOps.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sources/tech/20170516 What's the point of DevOps.md b/sources/tech/20170516 What's the point of DevOps.md index 357955f3f0..75a4a3ccd3 100644 --- a/sources/tech/20170516 What's the point of DevOps.md +++ b/sources/tech/20170516 What's the point of DevOps.md @@ -1,3 +1,4 @@ +翻译中 zhousiyu325 What's the point of DevOps? ============================================================ From 91e23ef2d8d183b085e0a4ebf45a9846a5d3d187 Mon Sep 17 00:00:00 2001 From: zhousiyu325 Date: Mon, 5 Jun 2017 10:46:00 +0800 Subject: [PATCH 2/5] 20170516 What's the point of DevOps.md --- .../20170516 What's the point of DevOps.md | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 translated/tech/20170516 What's the point of DevOps.md diff --git a/translated/tech/20170516 What's the point of DevOps.md b/translated/tech/20170516 What's the point of DevOps.md new file mode 100644 index 0000000000..7531f53a02 --- /dev/null +++ b/translated/tech/20170516 What's the point of DevOps.md @@ -0,0 +1,56 @@ +DevOps 的意义 +======================================== + +### 真正的组织文化变革有助于你弥合你原先认为无法跨过的鸿沟 + +![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?") +>图片来源 : opensource.com + +回想你最近一次尝试改掉一个个人习惯，你可能遇到过这样的情形，你需要改变你思考的方式并且让不习惯成为你身体的一部分。这很艰难，你只是试着改变 _你自己的_ 思维方式。 + +所以你可能会努力让自己处于新的环境。新的环境实际上可帮助我们养成 _新的_ 习惯，它反过又会促成新的思维方式。 + +那就是能否成功改变的所在：看起来是那么回事，实际上它就是那么回事 +。你需要知道 _为什么_ 你正在改变和你正准备去 _哪儿_ （而不是仅仅知道你要怎么做），因为改变本身往往是短暂和短视的。 + +现在思考你的 IT 组织需要做出的改变。也许你正在考虑采用像 DevOps 这样的东西。这个我们称之为 “DevOps” 的东西有三个组件：人、流程和工具。人和流程是 _任何_ 组织的基础。因此，采用 DevOps 需要对大多数组织的核心进行根本性的改变，而不仅仅是学习新的工具。 + +开放式组织资源： + +* [下载开放式组织领导手册][1] + +* [下载开放式组织现场指南][2] + +* [什么是开放式组织？][3] + +* [什么是开放式决策][4] + +和其他改变一样，它也是短视的。如果您将注意力集中在改变作为单点解决方案——例如，“获得更好的工具进行报警”——你可能想出一个狭隘的问题。这种思维方式或许可以提供一套拥有更多铃声和口哨并且可以有一种可以更好地处理随叫随到的方式的的工具，但是它不能解决这样的实际问题：警报不能到达正确的团队，或者故障得不到解决，因为实际上没有人知道如何修复服务。 + +新的工具（或者至少一个新工具的想法）创造了一个时刻来谈论困扰你的团队对监控的评价的潜在问题。新工具让你能够做出更大的改变——信仰和做法的改变——它们作为你组织的基础而显得更加重要。 + +创造更深层次的变革需要一种可以全新地改变观念的方法。要找到这种方法，我们首先需要更好的理解变革的驱动力。 + +### 清除栅栏 + +> "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 + +为了了解对 DevOps 的需求——它试图将传统意义上分开的开发部门和运维部门进行重新组合——我们首先必须明白这个分开是如何产生的。一旦我们"知道了它的用处"，然后我们就会知道将它们分开是为了什么，并且在必要的时候可以取消分开。 + +今天我们没有一个单一的管理理论，但是我们可以将大多数现代管理理论的起源追溯到弗雷德里克·温斯洛·泰勒。泰勒是一名机械工程师，他创建了一个衡量钢厂工人效率的系统。泰勒认为，他可以对工厂的劳动者应用科学分析，不仅为了改进个人任务，还为了证明有一个可以发现的用来执行 _任何_ 任务最佳方法。 + +我们可以很容易地画一个以 Taylor 为起源的历史树。基于泰勒早在18世纪80年代后期的研究而出现的时间运动研究和其他质量改进计划跨越20世纪20年代一直到今天，我们可以从中看到六西格玛、精益，等等一些。自上而下、指导式管理，再加上研究过程的有条理的方法，今天主宰主流商业文化。它主要侧重于把效率作为工人成功的测量标准。 + +>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. + +如果 Taylor 是我们的历史树的根，那么我们主干上的下一个主叉将是 20 世纪 20 年代通用汽车公司的 Alfred P. Sloan。通用汽车公司创造的斯隆结构不仅持续强劲到 21 世纪初，而且在未来五十年的大部分时间里，都将成为该公司的主要模式。 + +1920 年，通用公司正经历一场管理危机，或者说是缺乏管理的危机。Sloan 向董事会写了一份为通用汽车的多个部门提出了一个新的结构《组织研究》。这一新结构的核心概念是“集中管理下放业务”。与雪佛兰，凯迪拉克和别克等品牌相关的各个部门将独立运作，同时为中央管理层提供推动战略和控制财务的手段。 + +在 Sloan 的建议下（以及后来就任CEO的指导），通用汽车在美国汽车工业中占据了主导地位。Sloan 的计划把一个处于灾难边缘公司创造成了一个非常成功的公司。从中间来看，自治单位是黑盒子，激励和目标被设置在顶层，而团队在底层推动。 + +泰勒思想的“最佳实践” ——标准、可互换和可重复的行为——仍然在今天的管理理念中占有一席之地，与斯隆公司结构的层次模式相结合，主导了僵化的部门分裂和孤岛以实现最大的控制。 + +我们可以指出几份管理研究来证明这一点，但商业文化不是通过阅读书籍而创造和传播的。组织文化是 *真实的* 人在 *实际的* 情形下执行推动文化规范的 *具体的* 行为的产物。这就是为何类似 Taylor 和 Sloan 的主张这样的事情变得固化而不可动摇的原因。 + +技术部门投资就是一个例子。以下是这个周期是如何循环的：投资者只投资于他们认为可以实现 *他们的* 特定成功观点的公司。这个成功的模式并不一定源于公司本身（和它的特定的目标）；它来自董事会对一家成功的公司 *应该* 如何看待的想法。许多投资者来自在经营企业的尝试和苦难中幸存下来的公司，因此他们对什么会使一个公司成功有 *不同的* 蓝图。他们为那些能够被教导模仿他们的成功模式的公司提供资金所以希望获得资金的公司学会模仿。 这样，初创公司孵化器就是一种重现理想的结构和文化的直接的方式。 From 79d85c7ee72dcba0b6b6b06b9fdc2a40a77d770d Mon Sep 17 00:00:00 2001 From: zhousiyu325 Date: Tue, 6 Jun 2017 21:22:21 +0800 Subject: [PATCH 3/5] =?UTF-8?q?=E7=BF=BB=E8=AF=91=E5=AE=8C20170516=20What'?= =?UTF-8?q?s=20the=20point=20of=20DevOps.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../20170516 What's the point of DevOps.md | 137 ------------------ .../20170516 What's the point of DevOps.md | 73 ++++++++++ 2 files changed, 73 insertions(+), 137 deletions(-) delete mode 100644 sources/tech/20170516 What's the point of DevOps.md diff --git a/sources/tech/20170516 What's the point of DevOps.md b/sources/tech/20170516 What's the point of DevOps.md deleted file mode 100644 index 75a4a3ccd3..0000000000 --- a/sources/tech/20170516 What's the point of DevOps.md +++ /dev/null @@ -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 diff --git a/translated/tech/20170516 What's the point of DevOps.md b/translated/tech/20170516 What's the point of DevOps.md index 7531f53a02..8766155f52 100644 --- a/translated/tech/20170516 What's the point of DevOps.md +++ b/translated/tech/20170516 What's the point of DevOps.md @@ -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 From b5b2637dbede56e4d818b640e35fc82548997176 Mon Sep 17 00:00:00 2001 From: zhousiyu325 Date: Thu, 8 Jun 2017 10:09:30 +0800 Subject: [PATCH 4/5] finising 20170516 What's the point of DevOps.md --- translated/tech/20170516 What's the point of DevOps.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/translated/tech/20170516 What's the point of DevOps.md b/translated/tech/20170516 What's the point of DevOps.md index 8766155f52..09cf043dad 100644 --- a/translated/tech/20170516 What's the point of DevOps.md +++ b/translated/tech/20170516 What's the point of DevOps.md @@ -33,7 +33,7 @@ DevOps 的意义 ### 清除栅栏 -> "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 +> 就改革而言，它不同于腐化。有一条明显且简单的原则，这个原则可能被称为悖论。 在这种情况下，存在某种制度或法律; 让我们说，为了简单起见，在一条路上架设了一个栅栏或门。 现代化的改革者们来到这儿，并说：“我看不到它的用处，让我们把它清除掉。”聪明的改革者会很好地回答：“如果你看不到它的用处，我肯定不会让你清除它，回去想想，然后你可以回来 告诉我你看到它的用处，我会允许你摧毁它."—G.K Chesterton, 1929 为了了解对 DevOps 的需求——它试图将传统意义上分开的开发部门和运维部门进行重新组合——我们首先必须明白这个分开是如何产生的。一旦我们"知道了它的用处"，然后我们就会知道将它们分开是为了什么，并且在必要的时候可以取消分开。 @@ -41,7 +41,7 @@ DevOps 的意义 我们可以很容易地画一个以 Taylor 为起源的历史树。基于泰勒早在18世纪80年代后期的研究而出现的时间运动研究和其他质量改进计划跨越20世纪20年代一直到今天，我们可以从中看到六西格玛、精益，等等一些。自上而下、指导式管理，再加上研究过程的有条理的方法，今天主宰主流商业文化。它主要侧重于把效率作为工人成功的测量标准。 ->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. +> “开发”和“运维”的分开不是因为人的原因，不同的技能，或者放在新员工头上的一顶魔术帽，它是 Taylor 和 Sloan 的理论的副产品。 如果 Taylor 是我们的历史树的根，那么我们主干上的下一个主叉将是 20 世纪 20 年代通用汽车公司的 Alfred P. Sloan。通用汽车公司创造的斯隆结构不仅持续强劲到 21 世纪初，而且在未来五十年的大部分时间里，都将成为该公司的主要模式。 @@ -71,7 +71,7 @@ DevOps 的意义 ### 抵抗并不是没用的 -> "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 +> "Bert Lance 认为如果他能让政府采纳一条简单的格言“如果东西还没损坏，那就别去修理它”，他就可以为山姆拯救三十亿。他解释说：“这是政府的麻烦：'修复没有损坏的东西，而不是修复已经损坏了的东西。'” — Nation's Business, 1977.5 通常，改革是组织针对所出现的错误所做的应对。 在这个意义上说，如果紧张局势（即使逆境）是变革的正常催化剂，那么 *抵抗* 变化就是成功的指标。但是过分强调成功的道路会使组织变得僵硬、衰竭和独断。 重视有效结果的政策导航是这种不断增长的僵局的症状。重视有效结果的政策导航是这种不断增长的僵局的症状。 @@ -79,13 +79,13 @@ DevOps 的意义 正如“软件吃掉世界”，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 +> "如果外界的变化率超过了内部的变化率，那末日就不远了."—Jack Welch, 2004 一位同事曾经告诉我他可以只用 [Information Technology Infrastructure Library][9] 框架里面的词汇向一位项目经理解释 DevOps。 From 2c6be637c84485df41351875871716ba0c1c3994 Mon Sep 17 00:00:00 2001 From: zhousiyu325 Date: Sat, 10 Jun 2017 10:54:37 +0800 Subject: [PATCH 5/5] translate 20170520 How to master the art of Git.md --- sources/tech/20170520 How to master the art of Git.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sources/tech/20170520 How to master the art of Git.md b/sources/tech/20170520 How to master the art of Git.md index b3f32a5c6d..e6f0ca45ff 100644 --- a/sources/tech/20170520 How to master the art of Git.md +++ b/sources/tech/20170520 How to master the art of Git.md @@ -1,3 +1,4 @@ +translated by zhousiyu325 How to master the art of Git ============================================================