如何开始DevOps转换

如果您不了解什么是DevOps，那么这里是一个简短的备忘单。 DevOps是一组实践，可减少工程师的恐惧并减少软件生产中的失败次数。 通常，它们还缩短了产品上市的时间 -从构思到将最终产品交付给客户的时间，使您可以快速进行业务实验 。

如何开始DevOps转换？ 简而言之：我们从中选择将要启动流程的服务，确定与该服务相关的人员，构建“价值流图”，创建一个临时团队，该团队将首次处理转换并将其设置为任务。 我们会根据需要重复多次循环。


Express42的工程师Andrei Alexandrov的报告的解码版中详细说明了DevOps转换计划，其中包括示例和说明，该报告建议发芽DevOps，以加快此过程，因为它已经建立了耙图。 如果您认为您不需要进行转换，或者您的特定性导致不适合使用DevOps做法，请将该报告用作查找和消除限制的说明。

如果您担心DevOps转换的问题，那么您有一家大公司，则需要逐步将此过程扩展到整个结构。 只要需要改造团队或消除某种限制，就可以重复以下算法。

服务选择

我们已经概述了一个计划，从第一步开始-选择服务。 第一个标准是生存期 ：有旧服务-旧服务和新服务。 您可以从这些以及其他开始。

选择年轻的服务是合乎逻辑的 。 这是新鲜的，没有一个完善的团队合作流程。 在他周围没有技术债务的山，也不需要一直修理。 我们可以和他做任何我们想做的事。

在旧服务的情况下， 总是存在难以更改的事实，因此存在一些问题。 已经有了一些严格的限制，但是也许准备好推高一切的人正在做这件事-他们很累，想做点别的事情，因为那很痛。

使用旧服务为您的公司开创了强大的先例 -您可以更改某些内容。 如果您更改一项新服务，它每小时可以生产100次，并且一切正常，那么您公司中的人员可以说：

-这是一项新服务！ 那里的一切都很简单，尝试用我们的皮条客做点事。

当您与某个人一起进行（例如邀请外部顾问时）将旧版服务转换为转换是有意义的。 坦白地说，转换将错开一切可能的东西 。 您正在试验，不知道将要到哪里来，将使用什么技术以及为什么要使用它们，在过程中将在哪里出现什么陷阱。 因此，更容易进行新的更改。

如果您自己做所有事情，但公司能力不强，我们将提供一项新服务。 如果您知道外部顾问并且有资金，请选择旧的。

有些服务只是用户界面，例如，简单的网站或移动应用程序。 但是本着计费的精神，有些严肃的事情。 如果计费出现问题，将很难理解。 在这里我们也有选择。

我们要么使用关键服务 ，要么因为它而已受苦，它会产生限制，或者我们使用接口 。 这是第二选择标准。 同样，有可能吸引经验丰富的顾问-我们的工作很艰难。

但是即使在这种情况下，我也不建议您这样做，因为尽管不了解该如何使用以及如何进行转换，但是紧要关头并动摇它并不是一个好主意。 因此，在这种情况下，我们更喜欢使用故障不是很严重的接口。

接下来，考虑service命令 。 与那些从事这项服务的人一样，我们将不得不不断地工作并与他们保持密切联系。

团队中的人员有条件地分为两类： 保守派 -他们生活在旧世界中，或者对DevOps完全一无所知，而创新者则采用了所有流行做法。 后者并不总是理解该主题，但是至少他们已经准备好了。

一方面，保守派是有经验的人：他们已经在公司工作了很长时间，他们完全了解公司，但是他们不仅仅了解实践。 另一方面，有些创新者听说过一些东西，但很可能不久前他们就在公司工作。 与他们中的哪个更好一起工作？

无论如何，您都必须与保守主义者互动，因为这是他们的服务。 我们必须与他们沟通，找出服务的细节，用这种方法可以做什么以及有什么不同。 我们依靠他们的建议。 当然，他们将不得不委托某些东西，因为他们更了解自己的服务。 因此，与我们最终联系的团队很重要。

选择创新团队是合乎逻辑的，因为保守派可以放猪。

在实践中，保守的人经常会拥有丰富的经验，但对如何生活却一无所知。 他们只是担心，在转换和更改服务后，他们会因为不必要而被解雇。 有时，仅仅是由于对正在发生的事情缺乏了解，他们破坏了工作。

我有一个案例，团队中的一个人修理了任何东西，因为据称它比我们现在正在做的更为关键。 我们确定了任务：今天要实现这一目标-不，世界另一端着火了，我们将要修复它。 与这样的人一起工作很难。

保守派团队的人经常阻塞任务，或者推迟执行任务。 而且，如果John Willis救了您，您犯了一个错误，并把KPI挂在了已完成任务的数量上，并且由于某些原因，其中一些未包含在KPI中，那么它们将什么也不做。 通常，他们是正确的，因为那样他们就会失去奖金。

创新者更容易-他们更忠诚 。 他们已经听到了什么，他们想去某个地方，所以他们会提供帮助。 我们需要随时准备遭受苦难的人们：如果服务发生变化，那么创新者将把所有的麻烦和陷阱都当作先锋。 创新者想要最新，最时尚的产品，并遭受痛苦。

保守派可以稍后进行转换。 当您证明自己已经更改了一部分并且一切都很好时，他们很可能还会尝试采用新的DevOps宗教。

总结一下。 如果我们自己完成公司的所有转型，那么我们会选择：一个新服务，最好是一个简单的界面，以免遭受其崩溃的影响，并选择一个创新团队。

如果可以致电一位外部顾问，而不是新聘请一位外部顾问，则我们将采用旧服务，因此我们已经在受苦。 在不同公司从事转换已有很长时间的人们已经看到了不同的案例，并且已经了解如何正确执行转换以及总体上选择哪种方式。

谁参与其中？

通常，我们需要找到与该服务至少有关的每个人：开发人员，测试人员，管理员，安全卫士，经理以及可能的产品负责人。 尽管产品负责人不是技术人员，但他们与服务有关：做出决定，设定任务。

每个做出至少一些决定并影响该服务正在发生的事情的人都需要找到，见面和聊天。

它们对我们有什么作用？ 知道与谁谈判 。 在转换期间，当使用服务的通常原则发生变化时，无论如何它都会动摇。 当我们测试新方法时，会有一段时间的故障。 人们应该为此做好准备并同意。

然后，您必须构建“价值流图”，没有这些人，您将无法构建它，因为只有他们一起才能知道正在发生的事情的全貌。 一个人永远不知道服务所发生的一切。

他们将为团队中的人员提供建议，稍后我们将讨论为什么需要一个单独的团队。 它必须从现有部门调动人员。 与该服务相关的人员将能够推荐那些朝我们的方向思考，可以帮助我们并具有所需能力的同事。

然后，我们将来自不同部门的所有这些人员收集到一个房间中，并开始构建“价值流图”。

建立价值流图

“价值流图”是一个图表或地图，显示了到客户端的价值流 。 这是从构思创意到实施的整个过程，包括所有中间阶段以及价值最终如何到达客户的过程。

需要“价值流图”来可视化开发的所有阶段，通过当前流程中的度量来定位问题，并开始消除这些问题并设定初始目标 。 这是我们将开始真正做点事情的地方。

指标

“价值流图”文献中描述了许多不同的指标，但是对于初学者而言，我们只需要三个。

提前期-延迟/等待 -我们等待某事的时间。 例如，测试人员一直等到释放测试台并且此时无法执行任何操作。

增值时间-有用的工作时间-我们在这个阶段和那个阶段为用户创造最终价值所花费的时间。 例如，测试人员进行了测试并开始测试某些东西。 当我们真正为产品做某事时，这是有用的时间。 客户为此付费-购买优质软件。

％C / A-接受工作的百分比。 我们有一个阶段-开发，第二阶段-测试。 测试人员从开发人员那里获得了多少功能，并且有这个百分比。

这就是我们的地图。



它的外观可能会有所不同，具体取决于组织的结构，部门数和您的工作。 但是在一般情况下，地图将分为两个阶段： 构思和分析 。 此时，将需要数据，例如提前期2周和增值时间2天。

指标涵盖了所有阶段。

待办事项 -分析人员提出后要完成多少任务。

开发 -开发人员一直在等待有关任务，架子或设备的澄清的几周时间-没关系，但他们正在等待一些东西。 例如，他们实施一项功能需要4天。 ％C / A度量出现在此处。 开发人员仅从Backlog承担了80％的任务。 他们认为剩余的20％没有明确的传统知识，因此将其发送给修订。

测试 。 在LT方案中，设置为4天。 例如，测试人员正在等待测试平台发布，VA确实在进行2天的测试，并且％C / A = 40％。 -测试人员认为开发人员发送的代码或功能中只有40％足够。 由于某种原因，他们不喜欢其余的东西。

我不会详细介绍如何执行这些测量，在本文的结尾，我将推荐您可以从中了解它们的文献。

我唯一建议的是不要相信将与您一起构成《价值流图》的人们。 它们表示不同过程需要花费多少时间，但是这些估计值并不总是正确的，因此最好衡量自己。

我们遇到了一个案例，当时我们来到运营部门，询问向生产交付新功能需要多长时间。 他们回答了10分钟，我们想，为什么我们要来这家公司？ 原来，脚本的运行时间为10分钟，该运行时间将获取代码并将其交付给服务器。 但是在此之前，该版本在服务器上停留了三天之久，并且积聚了很多灰尘-在Backlog中存在需要部署的任务。 事实证明，在部署阶段之前，有一个项目只是处于等待状态的等待阶段。 如果我们不带笔记本，没有注意到吉拉（Jira）的一项任务，并且没有开始分阶段进行跟踪，那么我们会以为一切都很好，也没有问题。

因此，测量仍将必须由​​您自己进行，最好是不止一次，以使表示接近真实。 根据价值流图，您将决定从哪里开始以及首先要解决的问题。

临时队

许多决定引入DevOps的公司创建了一个团队，不仅是临时的，而且已经存在了几年。 如果转到DevOps道歉服务，该服务描述了在DevOps中构建组织结构的不同模式，那么您将了解这是一种反模式。

当DevOps团队连续存在数年后，这是一个很大的错误，因为DevOps与部门之间的沟通，速度和效率有关。

如果团队之间存在一个团队，而只是将其他事情分开做，并且存在了很长一段时间，那么就会造成额外的障碍。 现在，程序员无需直接联系管理员，而是需要首先联系DevOps部门，他将走得更远。

因此，要开始，您需要创建一个临时团队 。 根据任务的不同，它的存在期限为六个月，最长为一年，这仅是为了消除我们选择的一个限制。 然后她会死。 如果我们选择伤害很大的下一个点，并且知道我们也需要一个单独的团队，那么我们将再次创建它。 但是，这样的团队不应该“永久”地存在-他们只会打断沟通并一般承担单独的任务，而只是做某事。 这些任务可能根本与DevOps或转换无关。 我们为什么不把这项任务交给现有部门呢？

为什么需要一个临时团队

与当前流程发生冲突 。 DevOps转型不仅是我们使用的技术和工具的改变，而且是工作，思维和价值观过程的改变。 如果团队按照过去的方式工作，她将无法尝试其他方法。

这些人应遵循不同的规则：忽略公司中的所有KPI，因为他们尝试以不同的方式工作。 临时团队不会填写应用程序来获取服务器，而是直接去管理它们的部门，要求他们是第一个提供所需内容的人，因为这是优先任务，因为他们尝试过不同的生活。 团队与所有当前流程完全冲突。 为了避免现有的工作方法现在干扰他们，也不会干扰其他人，我们将这些人选为一个单独的团队来隔离他们。

在实验中避免官僚主义 。 临时团队中没有官僚机构；他们不填写工作时间报告；他们不向经理报告。 这是一个完全独立的世界，人们在其中生活和思考的方式不同，并且做的事情完全不同。 不要再打扰他们了。

在服务上不停地工作 。 在第一段中，我们选择了一些可以尝试的东西。 尝试并找到更好的工作方式是好的，但是我们也想做一些功能。 如果整个团队都在进行转换而不是进行功能转换，那么我们将开始损失收入，错误会持续很长时间-我们不需要这样做。 创建临时团队可以使您进行实验而无需停止产品工作。

不要在工作任务上浪费时间 。 这又是关于产品的。 团队花费大量时间尝试其他工具和东西。 为了使人们能够掌握这些工具，开始实施并正常使用它们，至少需要六个月的时间。 如果他们也要处理该产品-六个月的时间会大大延长。 如果人们从事某种产品，那么他们将再次使用旧的流程-我们不需要这样做。

因此，我们将来自不同部门的人员分成一个单独的团队，负责处理服务的转换。 结果，该服务有效，持续发展，同时，我们对其进行了一些实验。

临时团队仅参与DevOps转换-消除了我们发现的限制，仅此而已。

该团队由全民组成 。 这意味着我们不仅需要开发人员。 我们没有来此服务，也没有从那里接一个半队-不，我们接了来自不同部门的人员 。 几天前，我们发现了与转换服务相关的不同部门和不同员工。 其中，我们正在招聘一个团队，因为它必须具有通用性-我们将更改测试过程，开发过程和服务维护过程。 需要不同的能力。

通常，我们有条件地聘请一名开发人员，测试人员和工程师-每次都聘请一位，并与他们一起提出一种解决方案，使您的生活与众不同。

希望这些人在组织中具有权威 。 尽管您不想这样做，但您可能需要保守一点。 如果我们拥有一家大型公司，那么并不是每个人都会相信我们的冒险，例如，有人可以随心所欲地摆放方向盘，而不是突出展示架。 在这里，您将需要“权威”-具有丰富经验的受人尊敬的人，应该得到同事的良好态度。 团队中员工的权限将简化临时团队的任务和工作。 人们会认为：

-是的，这个我们都知道并喜欢的酷家伙适合在那里-显然，DevOps值得一看！

我们设定了目标

我们聚集了人员，选择了服务，查看了限制条件，确定了我们将影响的人员。 现在您需要设定一个目标，它应该在SMART上正确无误 -这就是我们热爱的一切。

具体具体的 。

可测量的 。 这是SMART的非常重要的一点。 如果您无法衡量某件事，那么您就无法更改它，也无法理解您做得好或坏的方式和方式。

可以实现的 。 根据您的具体情况进行调整。 如果您是一家历史悠久且责任重大的企业公司，并且每年发布一次产品版本，那么您将无法在六个月内每小时实现一次新产品版本的发布。 那样行不通。 因此，设定在可接受的时间内可以实现的实际目标。

相关-相关。 我们只会消除真正追求我们当前目标的限制。

限时限时 。 如果没有截止日期，团队将做任何事情：尝试15种技术而不是3种技术，撰写大量报告，进行无用的研究，在目标已经实现时立即对其实施进行测试。

我们在“价值流图”的帮助下实现目标-我们再次集结所有人员并进行抽奖。 但是直到现在，我们才根据以前的“价值流图”绘制我们想要获得的东西。



我们挑出了一个我们现在要消除的限制-这就是团队将要做的。 例如，我将期望从完成的发布发布到在生产中的部署-这是人们转向顾问的最常见限制。

基于此，我们设置了任务：我们希望就绪的发行版和开始生效之间的等待时间最多为一小时。

任务示例。

• 将交货时间测试从4天减少到1小时。
• 将测试的增值时间从2天减少到3小时。
• 将前置时间的部署时间从5小时减少到10分钟。
• 将C / A从50％增加到95％，也就是说，增加测试人员接受的功能数量，换句话说，就是提高开发人员的质量。

任务示例并非从头开始，而是基于我们在制定价值流图时所做的测量。

我们为团队设定了类似的任务，并设置了时间限制。 , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

怎么了 , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

.

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

— DevOps . - , , DevOpsConf , – QaulityConf . ++ Whale Rider — . 27 28 , .