DevOps Essentials

DevOps基础

介绍(Introduction)

The emergence of DevOps has marked a seismic shift in the software world in recent years. The allure is the opportunity it offers to organizations to increase their levels of productivity by orders of magnitude and outpace their competitors to win in the marketplace.

近年来，DevOps的出现标志着软件界发生了巨变。 诱人之处在于，它为组织提供了将生产力水平提高几个数量级并超过竞争对手以赢得市场的机会。

However, DevOps draws from a wide array of areas of research and represents their convergence into a broad set of philosophies, practices, and tools. With such a vast body of knowledge to consider, it’s hard to know where to begin when attempting to adopt it.

但是，DevOps来自广泛的研究领域，代表着它们融合到广泛的哲学，实践和工具中。 考虑到如此广泛的知识，尝试采用它时很难知道从哪里开始。

Fortunately, we can look to DevOps thought leaders to point us in the right direction. First introduced in The Phoenix Project and The DevOps Handbook is the concept of The Three Ways. It captures the conceptual underpinnings of the entire movement. This model is a powerful tool that identifies the characteristics of DevOps maturity and describes the path that your organization can follow to get there.

幸运的是，我们可以依靠DevOps的思想领袖为我们指出正确的方向。 首次在Phoenix项目中引入 和 DevOps手册是“三种方式”的概念。 它 抓住了整个运动的概念基础。 该模型是一个功能强大的工具，可以识别DevOps成熟度的特征，并描述您的组织可以遵循的发展路径。

We’ll be leveraging The Three Ways in this article by examining some practical actions your organization can take while pursuing DevOps maturity. It can help when the purported benefits of DevOps seem elusive. This feeling burdens organizations that struggle with the underlying principles of DevOps.

我们将通过研究组织在追求DevOps成熟时可以采取的一些实际行动来利用本文中的“三种方式” 。 当声称的DevOps好处似乎难以捉摸时，它可以提供帮助。 这种感觉使那些在DevOps的基本原则方面苦苦挣扎的组织感到负担。

We’ll discuss in more detail, within the context of The Three Ways to provide the insight necessary to fight past barriers to adoption. As with any cultural transformation, the adoption of DevOps requires a shift in mindset and values embodied by specific practices and approaches. This guide is a collection of ideas to get started or to strategize about potential next steps. It can be used by any technology professional at any level of your organization to accelerate or even begin its DevOps journey.

我们将在“三种方式”的背景下进行更详细的讨论，以提供必要的见识，以克服过去的采用障碍。 与任何文化变革一样，DevOps的采用要求转变思维方式和特定实践和方法所体现的价值。 本指南收集了一些想法，可用于入门或为可能的后续步骤制定策略。 组织中任何级别的任何技术专业人员都可以使用它来加速甚至开始其DevOps之旅。

三种方式 (The Three Ways)

第一种方式(The First Way)

The First Way is about accelerating the pace of delivery through your value stream. It can encompass the work of an individual contributor, a team, or even an entire organization. It describes how the business defines value-creating functionality for the development organization. Development builds the software that captures the value and passes it to operations to deliver it as a service to the customer.

第一种方法是通过您的价值流加快交付速度。 它可以涵盖单个贡献者，团队甚至整个组织的工作。 它描述了企业如何定义开发组织的创造价值的功能。 开发人员构建了捕获价值的软件，并将其传递给运营部门，以将其作为服务交付给客户。

The arrow only points from left to right, suggesting that there is never a backward flow. The implication is that known defects never get passed downstream, never negatively impacting the whole system with local optimization, and always pursuing greater throughput by continuously unlocking a greater understanding of the system to improve it.

箭头仅从左到右指向，表示永远不会向后流动。 这意味着已知的缺陷永远不会传递到下游，也不会通过局部优化对整个系统造成负面影响，并且始终通过不断解锁对系统的更多了解来改进系统，从而始终追求更大的吞吐量。

第二种方式 (The Second Way)

In The Second Way, your organization will establish a feedback loop that amplifies signals of quality and efficiency and enables the practice of continually making improvements by addressing any uncovered issues. You create a virtuous cycle of refinement, which allows a better understanding of customer needs and faster detection of problems, ideally moving to the predictive phase to prevent the issues from occurring in the first place.

在第二种方式中，您的组织将建立一个反馈循环，以放大质量和效率信号，并通过解决所有未发现的问题来实现不断改进的实践。 您创建了一个完善的良性循环，从而可以更好地了解客户需求并更快地发现问题，理想情况下可以进入预测阶段，从而防止问题首先发生。

Now you can begin the work of shortening the feedback cycle, which paves the way to add even more sensing mechanisms to detect weaker signals. By “sensing mechanisms,” we mean ways to inform developers or operations of issues occurring in production. “Weaker signals” refers to different characteristics of the running software that provides insight into the quality, stability, or other essential aspects of the system.

现在，您可以开始缩短反馈周期的工作，这为添加更多的感应机制以检测较弱的信号铺平了道路。 所谓“传感机制”，是指将生产中发生的问题通知开发人员或操作的方法。 “较弱的信号”指的是正在运行的软件的不同特征，可以洞悉系统的质量，稳定性或其他重要方面。

The Second Way helps your organization be proactive by reacting to predictive indicators of problems and addressing them before problems occur. Most of the detection mechanisms can be automated, which eliminates waste and helps your entire organization move faster without fear of breaking something.

第二种方法是对问题的预测指标做出React，并在问题发生之前解决它们，从而帮助您的组织积极主动。 大多数检测机制可以实现自动化，从而消除浪费，并帮助您的整个组织更快地行动，而不必担心会发生故障。

第三条道路(The Third Way)

As your organization leverages the apparatus created in The First and Second Ways, The Third Way revolves around the idea of enabling rapid experimentation for an even more in-depth understanding of customer needs. Since the apparatus is all-around promoting a fast flow, prevention of issues, and recovery from problems, organizations can take more chances in The Third Way and can conduct bold experiments right in production.

当您的组织利用在“第一方法”和“第二方法”中创建的设备时， “第三方法”围绕实现快速试验以更深入地了解客户需求的想法展开。 由于该设备全方位地促进了快速流程，问题的预防和问题的恢复，因此组织可以在“第三条道路”中把握更多机会，并可以在生产中进行大胆的实验。

The cultural impacts of these concepts are apparent in several practices. Teams able to begin their journey on The Third Way regularly allocate time for improving daily work. They may also intentionally introduce faults into the system to test their ability to respond and recover to improve the system and their skills. Organizations will also reward bold experimentation for fostering innovation, nurturing learning, and embedding courageous behaviour into their cultural DNA.

这些概念的文化影响在几种实践中显而易见。 能够以“第三条道路”开始旅程的团队会定期分配时间来改善日常工作。 他们还可能有意将故障引入系统中，以测试其响应和恢复能力，以改善系统和技能。 组织还将奖励大胆尝试以鼓励创新，培养学习并将勇敢的行为嵌入其文化DNA中。

约束理论(The Theory of Constraints)

To better understand The Three Ways, we must understand the Theory of Constraints (ToC).

为了更好地理解“三种方式” ，我们必须了解“约束理论” (ToC)。

Introduced in The Goal by Dr. Eliyahu Goldratt, the ToC revolves around the idea that at any given point in time, an organization has a single bottleneck that limits that organization from improving the throughput of its value-delivery workflow. Until the blockage gets removed, the organization will not be able to improve its throughput.

在目标中介绍 通过 Eliyahu Goldratt博士，ToC围绕这样一个思想：组织在任何给定的时间点都有一个瓶颈，限制了该组织提高其价值交付工作流程的吞吐量。 在消除障碍之前，组织将无法提高吞吐量。

In other words, when looking at an organization’s workflow from end-to-end, there is one critical point of friction or waste that is preventing the achievement of greater efficiency. The organization must focus on removing that problem point. As you do so, another bottleneck in the system will emerge, and then you must repeat the process.

换句话说，从端到端查看组织的工作流时，存在一个摩擦或浪费的关键点，阻碍了更高效率的实现。 组织必须专注于消除该问题点。 这样做时，系统中将出现另一个瓶颈，然后您必须重复该过程。

The ToC provides steps to transition the organization from being limited to exploiting that constraint:

ToC提供了将组织从受限转变为利用该约束的步骤：

1. Identify the constraint.
   确定约束。
2. Exploit the constraint, meaning to apply whatever tools or knowledge is available to improve the performance of the constraint.
   利用约束，意味着应用任何可用的工具或知识来改善约束的性能。
3. Subordinate and synchronize to the constraint, meaning to focus all supporting activities to ensure that they are improving the constraint.
   服从并同步到约束，这意味着要集中所有支持活动以确保它们正在改善约束。
4. Elevate the performance of the constraint, meaning to take any further, potentially radical actions to ensure that the constraint is no longer a bottleneck.
   提升约束的性能，这意味着采取任何进一步的，潜在的激进措施以确保约束不再是瓶颈。
5. Repeat from Step 1 because now the constraint has moved somewhere else.
   从步骤1开始重复，因为现在约束已移至其他位置。

The ToC has led to revolutionary transformations in manufacturing and technology. The ideas behind it are timeless and applicable to any organization that delivers value to customers.

ToC导致了制造和技术领域的革命性转变。 它背后的想法是永恒的，适用于为客户带来价值的任何组织。

三种方式的应用 (Applying The Three Ways)

Armed with a general understanding of these concepts, let’s look at ways to leverage them.

有了对这些概念的一般理解，让我们看一下如何利用它们。

使用价值流图识别瓶颈 (Use Value Stream Mapping to Identify Bottlenecks)

One of the best pieces of advice from The Phoenix Project is to start with value stream maps (VSMs). Using VSMs, you can gain situational awareness of how value flows through your organization and begin to optimize the flow. This practice sets you on the path to address The First Way.

The Phoenix Project最好的建议之一就是从价值流图(VSM)开始。 使用VSM，您可以了解价值如何在组织中流动的情况，并开始优化流动。 这种做法将使您走上解决“第一条道路”的道路。

VSMs can take many forms. There are multi-day sessions that involve representatives from the entire organization, and smaller Agile value stream mapping sessions that are hours long and focus on part of the value stream. While it’s true that the ToC tells us that we should be looking at the entire flow to identify the organizational bottleneck, your group might need to settle for smaller sessions in order to get started.

VSM可以采用多种形式。 有数天的会议，包括来自整个组织的代表，还有较小的敏捷价值流映射会议，这些会议长达数小时，并专注于部分价值流。 ToC确实告诉我们，我们应该在整个流程中进行查找以识别组织瓶颈，但是您的小组可能需要适应较小的会话才能开始。

The following example-VSM shows a fictitious value stream. The vital information that it displays:

以下示例-VSM显示了一个虚拟的价值流。 它显示的重要信息：

• The steps in the process.
  过程中的步骤。
• The various people or systems that are responsible for each step.
  负责每个步骤的各种人员或系统。

• The cycle time for each step, meaning the time that it takes after the work has started.

  每个步骤的周期时间，即工作开始后花费的时间。

• The lead time for each step, meaning the time that it takes the instant the work in the previous step has been completed.

  前置时间每一步，这意味着它需要即时在上一步工作的时间已经完成。

Using the information gathered in the VSM, your group can identify the bottleneck and begin the work to remove it. VSMs should be revisited on a regular basis since the bottleneck will move around.

使用VSM中收集的信息，您的小组可以确定瓶颈并开始进行工作以消除瓶颈。 由于瓶颈会四处移动，因此应定期重新检查VSM。

练习持续整合 (Practice Continuous Integration)

Continuous Integration (CI) is the practice of automating the merging of code into a central code repository branch. As CI has evolved, it’s become expected that merging occurs with high frequency — often many times per day. As one of the most straightforward practices to adopt and the many benefits it bestows, CI is part of The First Way.

持续集成(CI)是一种将代码自动合并到中央代码存储库分支的实践。 随着CI的发展，可以预期合并频繁发生-每天通常多次。 作为最直接的实践之一及其带来的许多好处，CI是The First Way的一部分。

The main benefit of doing this is that it introduces automation to the code development flow. It also reduces the potential friction that emerges with code branches that get worked on for extended periods. Finally, it provides a centralized environment where automated tests can be guaranteed to run instead of having developers run automated tests locally where environmental or local code differences may yield different testing outcomes.

这样做的主要好处是将自动化引入了代码开发流程。 它还减少了长时间处理代码分支时出现的潜在摩擦。 最后，它提供了一个集中的环境，可以保证自动测试可以运行，而不是让开发人员在本地运行自动测试，因为环境或本地代码的差异可能会产生不同的测试结果。

CI is a prerequisite of many of the practices we’ll discuss shortly. It’s also a well-established practice that most modern software teams already employ.

CI是我们稍后将讨论的许多实践的前提。 这也是大多数现代软件团队已经采用的公认惯例。

对等代码评论 (Peer Code Reviews)

Another well-established practice in software is Peer Code Reviews. DevOps highlights this as one of the most important techniques a software team can adopt because it ensures that another set of eyes is on the code before making its way into production. This approach establishes quality as a high-priority concern by building in a rigorous inspection.

在软件中另一种公认的做法是对等代码审查。 DevOps强调这是软件团队可以采用的最重要的技术之一，因为它可以确保在将代码投入生产之前，另一组人关注代码。 通过进行严格的检查，此方法将质量作为优先考虑的事项。

In addition to creating a focus on quality, it can also be leveraged to spread knowledge around the team, enforce agreed-upon standards like coding style agreements, reinforce the team’s process, and be used as a training mechanism.

除了着重质量外，还可以利用它在团队中传播知识，执行已达成共识的标准(例如编码样式协议)，加强团队的流程并用作培训机制。

Of course, a Peer Code Review is only useful if teams are taking them seriously. Often, time-pressures, a lack of understanding of standards, and other forces prompt developers to approve code with only a cursory glance to keep code moving through the value stream quickly. This behaviour circumvents the process and introduces the risk of defects making their way downstream. It is a failure to recognize the purpose of Peer Code Reviews.

当然，只有在团队认真对待的情况下，对等代码审查才有用。 通常，时间压力，对标准的缺乏理解以及其他因素促使开发人员只用粗略的浏览即可批准代码，以使代码快速在价值流中移动。 这种行为规避了过程，并引入了将缺陷带到下游的风险。 无法识别对等代码审查的目的。

To combat this, teams can review code as a group to establish a higher bar for the quality of the reviews themselves and communicate levels of acceptable quality.

为了解决这个问题，团队可以将代码作为一个小组进行审查，以建立更高的审查质量标准，并传达可接受质量的水平。

What we want to avoid is “rubber-stamping” our reviews, meaning that reviewers only give a superficial look at the code before approving it. This sort of behaviour results in a missed opportunity to leverage the most critical quality-control activity we have at our disposal — this is where we conduct checks that can’t be automated. It’s the difference between the level of inspection that humans can provide versus automation. Mature DevOps teams understand this and conduct thorough Peer Code Reviews.

我们要避免的是对审查进行“橡皮戳”，这意味着审查者在批准代码之前只对代码进行了肤浅的了解。 这种行为会导致错失利用我们掌握的最关键的质量控制活动的机会-这是我们进行无法自动化的检查的地方。 这是人类可以提供的检查水平与自动化之间的差异。 成熟的DevOps团队了解这一点并进行了彻底的对等代码审查。

练习连续交付 (Practice Continuous Delivery)

Continuous Delivery (CD) is the well-known practice of getting changes into customer’s hands quickly and safely through the automation of deployments. Naturally, there is much more to it than that. The point we want to make here is that CD is pretty much a must-have for The Three Ways.

连续交付(CD)是通过部署自动化快速安全地将更改交付客户手中的众所周知的做法。 自然，还有更多的东西。 我们在这里要说明的是，CD几乎是“三种方式”的必备条件。

In addition to the benefits to throughput when considering The First Way, having a CD pipeline in place facilitates both of the other Ways. For The Second Way, your CD pipeline is the system that you can add more sensing mechanisms to amplify ever weaker signals and ever faster feedback.

除了在考虑“第一种方式”时提高吞吐量的好处之外，拥有CD管道还可以促进其他两种方式。 对于“第二种方式” ，您的CD流水线就是一个系统，您可以添加更多的感应机制来放大越来越弱的信号和越来越快的反馈。

For The Third Way, the CD pipeline is where you’ll put your Feature Flags to release your rapid experiments as you approach DevOps maturity.

对于“第三种方式” ，CD管道是您放置功能标志的位置，可在您接近DevOps成熟度时发布快速实验。

For teams to successfully adopt CD, it’s essential to follow the principles at the heart of the philosophy behind it:

为了使团队成功采用CD，必须遵循其背后哲学的核心原则：

• Build quality in — detect and fix mistakes in ever-faster feedback loops because the further downstream they make it, the more waste they generate.

  建立质量-在更快的反馈循环中发现并修复错误，因为它们在下游产生的距离越远，产生的浪费就越多。

• Work in small batches — delivering smaller work units fosters agility, shortens feedback cycles, simplifies the detection and addressing of problems, and improves efficiency. Delivering smaller collections of work streamlines the process.

  小批量工作-交付较小的工作单位可提高敏捷性，缩短反馈周期，简化问题的发现和解决并提高效率。 交付较小的作品集可以简化流程。

• Automate repetitive tasks, let people solve problems — let computers do the mind-numbing, repetitive, uncreative work that humans tend to be bad at, and instead let them be proactive, creative problem-solvers. This approach makes work more rewarding and engaging and increases efficiency by orders of magnitude. It’s a win-win practice.

  使重复性任务自动化，让人们解决问题-让计算机完成人类往往不愿做的令人麻木的，重复性的，非创造性的工作，而让他们成为积极主动的创新型问题解决者。 这种方法使工作更有意义和更投入，并且效率提高了几个数量级。 这是双赢的做法。

• Relentlessly pursue continuous improvement — improve all aspects of work part of the work itself. Every team member should be working to improve things, whether they are significant capabilities that will super-charge productivity, micro-optimizations that make things slightly better, or simple habits that help keep entropy at bay.

  坚持不懈地追求持续改进-改进工作本身的各个方面。 每个团队成员都应该努力改善事物，无论它们是提高生产力的重要能力，使事物略微改善的微优化，还是有助于防止熵变的简单习惯。

• Everyone is responsible — every team member should have an active hand in ensuring the quality, correctness, and stability of their product, as well as the mechanisms that they leverage to deliver it.

  每个人都有责任-每个团队成员都应该积极主动地确保产品的质量，正确性和稳定性，以及他们用来提供产品的机制。

For a more nuanced understanding and advice on adoption, the original book Continous Delivery by Jez Humble and David Farley is an excellent place to start. Jez Humble also has a great collection of resources on adoption at continuousdelivery.com.

要获得关于采纳的更细微的理解和建议，Jez Humble和David Farley撰写的原始书Continous Delivery是一个很好的起点。 Jez Humble在Continuousdelivery.com上也有大量关于采用的资源。

追求快速自动化测试 (Pursue Fast Automated Testing)

You can’t have a CD pipeline without automated testing, or else all you’ll be delivering is a product with inferior quality very quickly. When you do have tests, make sure they’re fast, or they will become a bottleneck, and your delivery speed will suffer.

没有自动化测试，就无法拥有CD流水线，否则，您交付的只是质量很快的产品。 当您进行测试时，请确保测试速​​度很快，否则将成为瓶颈，并且可能会影响您的交付速度。

A prevalent model describing the relationship between various types of tests is The Test Pyramid.

描述各种测试类型之间关系的流行模型是“测试金字塔” 。

Even though UI Tests exercise more parts of the system and thus provide more value, they are also traditionally slower and harder to maintain. Unit and integration tests tend to run faster, even though they test less of the holistic system. By relying on mixed types of testing, you can maximize speed while still getting value out of tests.

尽管UI测试占用了系统的更多部分并因此提供了更多价值，但从传统上讲，它们也较慢且难以维护。 尽管单元和集成测试对整体系统的测试较少，但它们往往运行得更快。 通过依靠混合类型的测试，您可以最大化速度，同时仍可从测试中获得价值。

Considering the bottom of the Test Pyramid, unit tests (and especially when you write unit tests using TDD) can cover much ground and are generally the fastest tests to run because they run purely at the code level. The reason that the bottom of the Test Pyramid is wider than the top is that unit tests tend to be easier to write, run, and maintain. Even though they do not test as much, they still cover a wide array of cases eliminating the need to run slower tests from further up the Test Pyramid.

考虑到“测试金字塔”的底部，单元测试(尤其是当您使用TDD编写单元测试时)可以覆盖很多领域，并且通常是运行速度最快的测试，因为它们仅在代码级别运行。 测试金字塔的底部比顶部更宽的原因是单元测试往往更易于编写，运行和维护。 尽管它们没有进行太多测试，但它们仍然涵盖了很多情况，从而消除了从测试金字塔的上方继续进行较慢的测试的需要。

Additionally, a relatively unheralded effect of unit tests is that they tend to improve code modularity and other characteristics associated with more maintainable codebases. These lead to even further reduction of waste and a better throughput of changes.

另外，单元测试的相对未曾预料的效果是它们倾向于改善代码模块化和与更多可维护代码库相关的其他特性。 这些甚至可以进一步减少浪费，提高变更的吞吐量。

In the context of The Three Ways, fast, automated testing is a critical part of The First Way. It’s something that must be continuously maintained lest bottlenecks form or outages occur, and adversely impacts throughput. Quality gets reinforced in an environment where changes are ideally delivered rapidly.

在“三种方式”的背景下，快速，自动化的测试是“第一方式”的关键部分。 必须持续保持这种状态，以免出现瓶颈或中断，并严重影响吞吐量。 在理想的情况下，可以快速交付变化的环境可以提高质量。

采取持续改进的心态 (Adopt a Continuous Improvement Mindset)

At the heart of DevOps is the Lean concept that continuous improvement is how you can maximize your throughput and stave off the effects of entropy, which leads to regression or friction in your workflow. We can adopt this by continuously reviewing the entirety of our system, look for bottlenecks, and fix them.

DevOps的核心是精益概念，即持续改进是您如何最大程度地提高吞吐量并避免熵的影响，这会导致工作流中的回归或摩擦。 我们可以通过不断检查系统的整体，寻找瓶颈并加以修复来采用此方法。

The Plan-Do-Check-Act cycle is a tried and true methodology to ensure the adoption of a continuous improvement practice. PDCA has heavily influenced Agile methods, so they all have the concept of regular improvement cycles built-in. A few examples are:

计划-执行-检查-执行周期是一种经过实践检验的真实方法，可以确保采用持续改进的做法。 PDCA在很大程度上影响了敏捷方法，因此它们都有内置的定期改进周期的概念。 一些示例是：

• Sprint Retrospectives in the Scrum Agile framework.

  Scrum敏捷框架中的Sprint回顾。

• The Lean notion of the Andon cord where you stop the line to swarm problems to find a solution. Learning is shared immediately across the group.
  安东线的精益概念，您可以在此处停住线以聚集问题以找到解决方案。 立即在小组中共享学习。
• The Service Delivery Review in Kanban, where there is a regular discussion of how the workflow can be improved.
  看板中的服务交付审核，其中定期讨论如何改进工作流。

No matter the specific practice you adopt, the vital part is to ensure that teams do not skip these improvement activities. They are just as important as delivery. Thus, regular reflection on how the work went and thinking of ways to improve it is a critical aspect of The Three Ways.

无论您采用哪种具体实践，至关重要的部分都是确保团队不要跳过这些改进活动。 它们与交付同样重要。 因此，定期反思工作的进行方式并思考改进工作的方式是“三种方式”的关键方面。

实践测试驱动的开发 (Practice Test-Driven Development)

As I’ve written in a previous article, there is a natural affinity between TDD and DevOps. Please refer to that article if you would like to understand more about the benefits and adoption challenges of TDD.

正如我在上一篇文章中所写，TDD和DevOps之间有着天然的亲和力。 如果您想了解更多有关TDD的好处和采用挑战的信息，请参考该文章。

To summarize, TDD is one of the best ways to prevent tech debt from accumulating because it helps prevent it from entering the system in the first place. Expertise with TDD can also speed up delivery because it eliminates waste from the process. So there is a natural fit for TDD as we seek to maximize our throughput in The First Way.

总而言之，TDD是防止技术债务累积的最佳方法之一，因为它有助于防止技术债务首先进入系统。 TDD的专业知识还可以消除流程中的浪费，因此也可以加快交付速度。 因此，当我们试图以“第一方式”最大化吞吐量时，TDD就很自然了。

使用监视和警报 (Use Monitoring and Alerting)

These sensing mechanisms have been at the heart of DevOps, SRE, and ops for a long time. These are how you realize The Second Way. The main take-away is that, just as with every other DevOps practice, these tools should not be regarded as a project-based activity; the work in maintaining and improving them is never done.

这些传感机制一直是DevOps，SRE和ops的核心。 这些就是您实现第二种方式的方式。 主要收获是，就像其他所有DevOps实践一样，这些工具不应被视为基于项目的活动。 维护和改进它们的工作从未完成。

Another concept in play here is working towards being proactive in preventing problems from occurring in the first place, rather than continually reacting to situations. Monitoring and alerting is a baseline requirement of shifting to a proactive mindset.

这里正在发挥作用的另一个概念是致力于主动预防问题的发生，而不是对情况不断做出React。 监视和警报是转变为主动思维的基本要求。

The final concept we should consider related to The Second Way is identifying and amplifying different signals. Detect outliers and use them in active prevention. Consider other metrics that can offer more in-depth insight through varied perspectives. Perform analysis of monitoring data to understand the nature of problems.

我们应该考虑的与第二种方式有关的最终概念是识别和放大不同的信号。 检测异常值并将其用于主动预防。 考虑其他可以通过不同角度提供更深入洞见的指标。 执行监视数据分析以了解问题的性质。

预留20％的技术债务削减时间 (Set Aside 20% Tech Debt Reduction Time)

If technical debt is the great destroyer of projects, products, and even companies, then the next logical question is: how do we prevent it? By addressing it, of course.

如果技术债务是项目，产品乃至公司的巨大破坏者，那么下一个逻辑问题是：我们如何防止它？ 通过解决，当然。

The number need not be 20%, although DevOps thought leaders recommend that specific amount because it’s tough to address existing debt and prevent it without investing that amount of time proactively. This equates to one day per week per developer. What’s important is to get started on this immediately. Operationally, what this usually looks like is that technical teams are given a set amount of time to take on work that is entirely unrelated to feature-work. The idea is that developers are closest to the symptoms of tech debt and can spot it with the least effort, and so giving them the freedom to address it helps reduce technical debt.

这个数字不必是20％，尽管DevOps认为领导者建议使用该特定数额，因为要解决现有债务并防止其在不积极投入大量时间的情况下很难解决。 这相当于每个开发人员每周有一天。 重要的是立即开始操作。 在操作上，通常看起来是技术团队有一定的时间来进行与要素工作完全无关的工作。 这个想法是，开发人员最接近技术债务的症状，并且可以以最小的努力发现它，因此给予他们解决问题的自由可以减少技术债务。

This can be adopted in many different ways. Some ideas are:

这可以以许多不同的方式来采用。 一些想法是：

• Allocating a set portion of buffer time in the amount of work that teams take on and reserving those for tech debt
  在团队承担的工作量中分配一定的缓冲时间，并为技术债保留
• Blocking off parts of developers’ calendars regularly to free them up to take care of this work
  定期屏蔽部分开发者的日历，以腾出时间来完成这项工作
• Employ hack days specifically targeted to solve tech debt through innovation
  利用专门针对通过创新解决技术债务的黑客活动日
• Regular tech debt sprints (e.g., every fourth sprint)
  常规技术债务冲刺(例如，每四个冲刺)

The point is to build the habit of regularly reducing technical debt. It can’t accumulate to the point where the development workflow is halted, and the influx of defects kills the ability to move forward.

关键是要养成定期减少技术债务的习惯。 它无法累积到开发工作流程停止的地步，而缺陷的涌入扼杀了前进的能力。

This practice fits best with The First Way in that it’s all about improving the workflow and reducing waste. However, it often tends to be a characteristic of The Third Way in that mature DevOps organizations seem to be at the point where they can practice it.

这种做法最适合“第一种方式” ，因为它全部与改善工作流程和减少浪费有关。 但是，它往往是“第三种方式”的特征，因为成熟的DevOps组织似乎处于可以实践的地步。

练习基于主干的开发 (Practice Trunk-Based Development)

When attempting to get a continuous integration workflow in place, which is necessary for a continuous delivery workflow, you must adopt trunk-based development. The reason for this is that long-lived feature branches are seductively easy to create, but inevitably cause problems when they have to be merged into the trunk. Also, code drift is inevitable with multiple, long-lived feature branches. You have to resist this urge and look to other mechanisms to support CI / CD workflows. We’ll discuss feature flags shortly as a discrete item, but in addition to those, you can use branching by abstraction where you commit production code without key pieces that cause the code to run in production.

在尝试建立持续集成工作流程所需的持续集成工作流程时，必须采用基于主干的开发。 其原因是，长期存在的特征分支易于创建，但是在必须将其合并到主干中时不可避免地会引起问题。 而且，使用多个长期存在的功能分支不可避免地会发生代码漂移。 您必须抵制这种冲动，并寻求其他机制来支持CI / CD工作流。 我们将在短期内将功能标志作为离散项进行讨论，但除此之外，您还可以通过抽象使用分支，在这种情况下，您提交生产代码时不会产生导致代码在生产中运行的关键部分。

In a trunk-based development workflow, the only branches your team should have are short-lived feature branches, such as Git Pull Requests. Vincent Driessen’s git-flow is a famous example of non-trunk-based development. So we would want to avoid this and instead consider the GitHub flow. Vincent says as much in his “Note of reflection” in the link above.

在基于主干的开发工作流程中，团队应该唯一拥有的分支是短暂的功能分支，例如Git Pull Requests。 Vincent Driessen的git-flow是非基于主体的开发的著名示例。 因此，我们希望避免这种情况，而是考虑GitHub流。 文森特在上面的链接中的“反思笔记”中说了很多。

Employing this strategy plays well with The First Way and the concept of small batch sizes. Instead of large, coupled batches of code, we work in small batches of fully-functioning production code that expose us to less risk of regression, merge conflicts, and other waste in our workflow. This is an excellent way to improve throughput, but it requires the discipline to resist the urge to make the short-sighted trade-off of creating multiple long-lived branches.

采用这种策略与“第一种方式”以及小批量的概念很好地结合在一起。 我们使用大量功能齐全的生产代码，而不是使用大量的耦合代码，从而使我们在工作流程中面临的回归，合并冲突和其他浪费的风险较小。 这是提高吞吐量的绝妙方法，但是它要求纪律抵制在创建多个长期存在的分支机构方面进行短视权衡的冲动。

支持功能标志 (Support Feature Flags)

Feature flags are one of the riskiest practices mentioned in The Three Ways. This is because they introduce administration overhead and complexity with development and testing. There is also the cautionary tale of Knight Capital’s $460 million repurposed feature flag mistake. This doesn’t make feature flags inherently evil, but it does underscore the need for explicit management policies around feature flags.

功能标记是“三种方式”中提到的最危险的做法之一。 这是因为它们引入了管理开销以及开发和测试的复杂性。 还有一个警告性的故事：骑士资本(Knight Capital)4.6亿美元的改版功能标志错误。 这不会使功能标志天生就邪恶，但是它确实强调了围绕功能标志的显式管理策略的需求。

However, this level of risk doesn’t make them any less critical because you can’t achieve maturity with continuous delivery or The Three Ways without them. The implication is that if you want to be a DevOps organization, you must become competent at them.

但是，这种风险水平并不会降低它们的重要性，因为连续交付或没有它们的“三种方式”都无法实现成熟。 含义是，如果您想成为DevOps组织，则必须具备胜任能力。

There are several easy workarounds to feature flag management. The first is to avoid the temptation to create your own system. There are several feature flag management tools out there — some are even free. This approach beats managing hard-coded files, which is what most people start with for some reason.

有几种简单的变通办法来实现标志管理。 首先是避免创建自己的系统的诱惑。 有几种功能标记管理工具-有些甚至是免费的。 这种方法优于管理硬编码的文件，这是大多数人出于某种原因而开始的工作。

Another practice to adopt is to make sure that a feature flag isn’t needed to delete it. You don’t want to be the next Knight Capital.

采取的另一种做法是确保不需要删除功能标记。 您不想成为下一个骑士之都。

Minimizing the number of feature flags is also essential. Feature flags naturally introduce complexity to your software. We want to reduce complexity, so avoiding long-lived, global feature flags is a good practice to follow.

最小化功能标志的数量也很重要。 功能标记自然会给您的软件带来复杂性。 我们希望降低复杂性，因此避免使用长期存在的全局特征标记是一个好的做法。

This implies that there should be some centralized administration. Ideally, each team can manage its own flags. If many groups share code across a highly-coupled system like a monolith, this incurs more coordination overhead, as well as risk.

这意味着应该进行一些集中管理。 理想情况下，每个团队都可以管理自己的标志。 如果许多小组在像巨石这样的高度耦合的系统上共享代码，则将招致更多的协调开销和风险。

The gist is that feature flags are not for every team. Still, similar to other practices in this list, are a critical aspect of The Three Ways and align to a continuum of competencies and values that lead towards DevOps maturity vis-à-vis The Third Way.

要点是，功能标志并不适用于每个团队。 尽管如此，与该清单中的其他实践类似，这是“三种方式”的关键方面，并与导致“ DevOps”相对于“第三种方式”成熟的能力和价值观的连续性保持一致。

在生产中执行快速，短暂的实验 (Perform Rapid, Short-Lived Experiments in Production)

The Third Way is all about taking advantage of the speed and safety by achieving the first two Ways to enable rapid experimentation. This phase is where all of that work pays off, and this is how you bake innovation into your team’s daily work. It opens a whole new set of possibilities.

第三种方法是通过实现前两种方法来实现快速实验，从而充分利用速度和安全性。 在此阶段，所有工作都将获得回报，这就是您如何在团队的日常工作中激发创新的方式。 它带来了全新的可能性。

The reason that we list this practice as part of The Third Way is the mechanisms specified in the previous Ways are needed to perform experiments.

之所以将这种做法列为“第三种方式”的一部分，是因为先前的方式中指定的机制需要进行实验。

1. You must be able to deploy experiments quickly, so a CD pipeline is needed.
   您必须能够快速部署实验，因此需要CD管道。
2. You have to turn on and off experiments to avoid exposing your entire user base to an experimental feature, so feature flags are needed.
   您必须打开和关闭实验以避免将整个用户群暴露于实验功能，因此需要功能标志。
3. Your developers need time to execute their experiments, so they must not be inundated with bugs, feature requests, or technical debt. The pace of development must support this.
   您的开发人员需要时间来执行他们的实验，因此他们一定不会被错误，功能要求或技术债务所淹没。 发展的步伐必须支持这一点。
4. There needs to be a good relationship with the people coming up with experiments — whether they are other technical folks, user experience researchers, or business people.
   与进行实验的人员之间应该保持良好的关系-无论他们是其他技术人员，用户体验研究人员还是商人。

At a practical level, we carry out experiments using mechanisms like A / B testing. This practice helps teams craft better user experiences and finds ways to improve the product and business results. It is possibly the most reliable indicator of DevOps maturity.

在实际水平上，我们使用A / B测试之类的机制进行实验。 这种做法有助于团队创造更好的用户体验，并找到改善产品和业务成果的方法。 它可能是DevOps成熟度的最可靠指标。

何时采用惯例 (When to Adopt Practices)

The following chart is intended to provide insight into the relationships between the various practices. It also emphasizes the alignment of purpose to each of The Three Ways. It’s interesting to see that there’s a rough order to the timing of adoption. It’s also clear that your organization can get started on adoption immediately.

下表旨在深入了解各种实践之间的关系。 它还强调了目标与“三种方式”的一致性。 有趣的是，采用的时间很短。 同样很明显，您的组织可以立即开始采用。

Of course, the chart is not meant to be taken literally. You should adopt whatever makes sense for your organization at a given time, and it will not look the same for every organization.

当然，该图表并非按字面意思绘制。 您应该在给定的时间采用对您的组织有意义的任何方法，并且对于每个组织来说看起来都不尽相同。

结论(Conclusion)

DevOps is very broad and requires the alignment of many different proverbial stars in your organization to succeed. So it’s challenging to adopt. To overcome such an overwhelming set of challenges, sometimes you need an idea of where to start. Hopefully, I’ve managed to convey the value of using The Three Ways to establish the context for a few new goals for your organization and provided clarity on the sorts of activities your organization can take to meet those goals.

DevOps的范围很广，需要组织中许多不同的明星共同努力才能成功。 因此采用它具有挑战性。 为了克服如此众多的挑战，有时您需要从何处着手。 希望我已经传达了使用“三种方式”为您的组织的一些新目标建立背景的价值，并提供了组织为实现这些目标可以采取的各种活动的明确说明。

In case it’s not apparent, there are as many philosophical and cultural changes that need to be in place to support a successful DevOps adoption. The best thing to do is to create a culture where there is space for these concepts and to start trying them out. The list here is by no means exhaustive, but every idea is something that should be in place in a successful, mature DevOps organization.

如果不清楚，则需要进行许多哲学和文化上的改变以支持成功采用DevOps。 最好的办法是创建一种文化，为这些概念留出空间，并开始尝试它们。 这里的列表绝不是详尽无遗的，但是每个想法都是成功，成熟的DevOps组织中应该有的。

Best of luck with your DevOps journey!

祝您在DevOps旅途中万事如意！

进一步阅读 (Further Reading)

The best way to understand The Three Ways is to read all of the books by the authors that invented it. In order: The Phoenix Project, Beyond The Phoenix Project, The DevOps Handbook, Accelerate, and The Unicorn Project are all wonderfully-engaging and relevant reads for any professional in the technology industry.

理解“三种方式”的最好方法是阅读发明它的作者的所有书籍。 为了：凤凰项目，超越了凤凰计划，该手册的DevOps ，加速，并 独角兽计划 对于技术行业的任何专业人士而言，都是精彩而有趣的相关读物。

Gene Kim, one of the DevOps luminaries and author of the books mentioned above, has a great blog post that summarizes The Three Ways if you want to hear the description of the concept from one of the minds that conceived it.

Gene Kim是DevOps的杰出人物之一，也是上述书籍的作者，他在一篇不错的博客文章中总结了“三种方式”，如果您想从一个构想的人那里听到这一概念的描述。

This Atlassian article on peer code reviews does a great job of highlighting the benefits. Please read it to acquire a deeper understanding of the process and its advantages.

Atlassian上有关对等代码审查的文章在强调收益方面做得很好。 请阅读它，以更深入地了解该过程及其优势。

The Lean Production blog provides a great write-up that captures the essence of the ToC, albeit from a project management viewpoint. Andrew Fuqua has written a great article on applying the ToC to Agile software development that’s worth a read.

精益生产博客提供了很棒的文章，尽管从项目管理的角度来看，也抓住了ToC的本质。 Andrew Fuqua写了一篇很棒的文章，介绍了将ToC应用于敏捷软件开发，值得一读。

This Pete Hodgson article is probably the best feature flag article around.

皮特·霍奇森(Pete Hodgson)的这篇文章可能是周围最好的功能标志文章。

SRE is an intense topic, and the area of DevOps concerns called Site Reliability Engineering (SRE) has strong foundations in this area. Check out the SRE Book to learn more. Also, The DevOps Handbook provides a great breakdown of some of the ways of applying these concepts.

SRE是一个激烈的话题，DevOps关注的领域称为站点可靠性工程(SRE)在此领域具有坚实的基础。 查阅SRE书以了解更多信息。 此外， 《 DevOps手册》对应用这些概念的某些方法进行了详细介绍。

免责声明 (Disclaimer)

I’m an employee of IBM. The views expressed in this blog are mine and don’t necessarily reflect the positions, strategies, or opinions of the company.

我是IBM的员工。 本博客中表达的观点是我的观点，不一定反映公司的立场，策略或观点。