如果您不明白 DevOps 是什么，这里有一个快速备忘单。 DevOps 是一组实践， 减少工程师的恐惧 并减少软件生产中的失败次数。 一般来说，它们是相同的 缩短上市时间 — 从想法产生到最终产品交付给客户的期间，这使您能够快速执行 商业实验.
如何开始DevOps转型？ 简而言之：我们选择启动流程的服务，确定与该服务相关的人员，构建价值流图，创建一个临时团队来首次处理转型并为其设置任务。 我们重复该循环所需的次数。
详细的 DevOps 转型计划，其中包含示例和说明 - 记录中 安德烈·亚历山德罗夫 - Express42 的一名工程师，为 DevOps 萌芽提供建议，加快了这一过程，因为她已经构建了一个 rake 地图。 如果您认为不需要转型，或者您的具体情况不适合 DevOps 实践，请使用该报告作为查找和消除限制的说明。
如果你关心DevOps转型的问题，那么你有一家大公司，你需要在整个架构中逐步扩展这个过程。 只要需要变换命令或者消除某些限制，就可以重复下面的算法。
选择服务
我们已经制定了计划，让我们从第一步开始——选择服务。 第一个标准是寿命：有旧服务（遗留）和新服务。 您可以从两者开始。
选择年轻的服务是合乎逻辑的。 这是新鲜事，目前还没有一个既定的流程来处理这个问题的团队工作。 它周围没有堆积如山的技术债务，你不需要一直修复它。 我们可以用它做任何我们想做的事。
对于旧服务，存在与以下事实相关的问题： 改变总是困难的。 已经有一系列严格的限制，但也许这些限制是由那些准备铲除一切的人来处理的——他们很累，想做一些不同的事情，因为他们很痛苦。
使用旧服务开创了强有力的先例 在你的公司——你可以改变一些事情。 如果你更改一项新服务，它每小时滚动 100 次，并且一切都很好，那么你公司的人可能会说：
- 这是一项新服务！ 那里的一切都很简单，尝试用我们的残骸做点什么。
当您与某人一起进行转型时（例如，如果您邀请了外部顾问），使用旧服务进行转型是有意义的。 老实说，转型将动摇一切可能。 你正在尝试，但不知道你会在哪里结束，你将使用什么技术，以及为什么、在哪里以及过程中会出现什么陷阱。 因此，更换新的也比较容易。
如果你自己做所有事情，而公司没有足够的能力，我们会采取新的服务。 如果您认识一位外部顾问并且有资金，请选择旧的。
有些服务只是用户界面，例如简单的网站或移动应用程序。 但计费精神中有一些严肃的事情。 如果计费出现问题，将很难解决。 在这里我们也有一个选择。
我们工作要么 具有关键服务，但我们因此而受苦，它造成限制，或者我们工作 带接口。 这是第二个选择标准。 同样，吸引经验丰富的顾问也是可能的——我们会选择困难的选择。
但即使在这种情况下，我也不建议这样做，因为在了解要做什么以及要转型的方向之前，采取关键的事情并对其进行调整并不是一个好主意。 因此，在这种情况下，我们更愿意使用故障不严重的接口。
让我们进一步看一下 服务团队。 我们必须不断地与提供这项服务的人密切合作。
团队里的人分为两类： 保守派 — 生活在旧世界，或者根本不了解 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 转型不仅仅是我们使用的技术和工具的变化，而是工作、思维和价值观本身过程的变化。 如果团队按照已经习惯的方式工作，就无法尝试其他方法。
这些人必须遵守不同的规则：忽略公司中的所有关键绩效指标，因为他们试图以不同的方式工作。 临时团队不会填写申请表来获取服务器，而是直接前往管理他们的部门，要求他们首先得到他们需要的东西，因为这是一个优先事项，因为他们试图以不同的方式生活。 该团队与当前所有流程完全冲突。 为了确保现有的工作实践现在不会干扰他们，也不会干扰其他人，我们将这些人隔离到一个单独的团队中。
避免实验中的官僚主义。 临时团队没有官僚作风，他们不提交时间报告，也不向经理报告。 这是一个完全独立的世界，人们生活、思考、做事完全不同。 没必要再去打扰他们了。
不间断的服务工作。 在第一点中，我们选择了要进行实验的东西。 尝试并寻找更好的工作方法固然很好，但我们也想开发一些功能。 如果整个团队专注于转型而不是功能，那么我们将开始失去收入，错误将长期存在 - 我们不需要这个。 创建临时团队可以让您在不停止产品工作的情况下进行试验。
不要把时间浪费在工作任务上。 又是关于产品的。 团队需要花费大量时间来尝试其他工具和东西。 人们至少需要六个月的时间才能掌握这些工具，开始实施并正常使用它们。 如果他们也专注于产品，那么六个月的时间就会非常长。 如果人们在产品上工作，他们会再次使用旧的流程——我们不需要那样。
因此，我们将来自不同部门的人员分配到一个单独的团队中，以改变服务。 结果，该服务发挥了作用，继续发展，同时我们对其进行了一些实验。
临时团队仅致力于 DevOps 转型 - 消除我们发现的限制，仅此而已。
该团队由多才多艺的人组成。 这意味着我们不仅雇用了开发人员。 我们没有来到服务中心并从那里带走一半的团队 - 不，我们带走了 来自不同部门的人。 不久前，我们发现了与转型后的服务相关的不同部门和不同员工。 我们正在从他们那里招募一个团队，因为它必须是通用的——我们将改变测试流程、开发流程和服务维护流程。 需要不同的能力。
通常我们会聘请一名开发人员、一名测试人员和一名工程师，一次一名，然后与他们一起提出一个解决方案，让我们能够以不同的方式生活。
这些人在组织中拥有权威是可取的。 你可能不得不选择一位保守派，尽管你不想这样做。 如果我们有一家大公司，不是每个人都会相信我们的想法，有些人可能会在我们的轮子上放一根辐条，例如不提供展位。 这就是你需要一个“权威”的地方——一个受人尊敬、经验丰富、赢得同事良好态度的人。 员工在团队中的权威将简化临时团队的任务和工作。 人们会想：
- 是的，这个我们都认识并喜爱的酷家伙就适合那里 - 显然 DevOps 中有一些值得关注的东西！
设定目标
我们聚集了人们，选择了一项服务，查看了限制，并确定了我们将影响哪些人。 现在你需要设定一个目标并且它应该是直接的 通过智能 - 我们所爱的一切。
具体-具体.
可测量-可测量。 这是非常重要的 SMART 点。 如果你无法衡量某件事，那么你就无法改变它，也无法了解你在哪些方面做得更好或更差。
可实现-可实现。 进行调整以满足您的特定需求。 如果你是一家历史悠久、责任重大的企业公司，每年发布一个版本的产品，那么你将无法实现六个月内每小时发布一次产品的新版本。 那样的话是行不通的。 因此，设定一个可以在可接受的时间范围内实现的现实目标。
相关-相关。 我们仅删除那些真正有助于我们当前目标的限制。
Time Limited——时间有限。 如果没有最后期限，团队就会做任何他们想做的事：尝试 15 种技术而不是 3 种，写大量报告，进行无用的研究，完善他们的实施，直到目标已经实现时大放异彩。
我们使用价值流图来实现目标——我们再次收集所有人员并绘制他们。 但现在才根据之前的价值流图，画出我们想要得到的东西。
我们强调我们现在将消除的一个限制 - 这就是团队将要做的事情。 作为一个例子，我考虑了从完成的版本到在生产中部署的等待——这是人们求助于顾问的最常见的限制。
基于此，我们设定了任务：我们希望从完成发布到投入战斗之间的等待时间最多为一个小时。
任务示例。
- 将测试前置时间从 4 天缩短至 1 小时。
- 将测试的增值时间从 2 天减少到 3 小时。
- 将部署准备时间从 5 小时缩短至 10 分钟。
- 将C/A从50%提高到95%，即增加测试人员接受的功能数量，换句话说，提高开发人员的工作质量。
任务示例并非来自我们的头脑 - 它们基于我们在开发价值流图时所做的测量。
我们为我们的团队设定了类似的任务和时间限制。 根据您公司的表现，您可以设定不同的截止日期。 平均而言，如果人们第一次这样做并且还不知道使用什么技术以及如何具体解决问题，那么通常需要六个月的时间才能消除限制。
短期规划
因此，我们的团队创建了，它有一个目标，人们开始工作。 重要的一点是简短的工作计划： 冲刺一到两周不再有， 可衡量的改进 每周和 航向修正.
例如我们经常使用的方法 移动-移动当整个团队每周初聚集时，他们会在一份文件中记下每个人要做的事情。 一周后，我们记下已经做了什么、没有做什么，如果没有，那么为什么，然后我们思考下一步该做什么。
冲刺可以让你及时修正方向。
一两周的时间里，你尝试了一些东西：技术、方法、工作方式，之后你再次测量，看看这种方法是变得更好还是更糟？ 如果情况更糟，则意味着我们正朝着错误的方向前进，我们需要纠正方向：设定不同的任务，采用不同的技术，或者做其他事情。 1-2 周的短冲刺可以让您及时调整并避免错误的决定。
分享成功
团队取得了一些成功，无论大小——这并不重要，总会有一些结果。 每个人都应该知道这个结果：参与 DevOps 的人员和邻近部门的人员。 在理想的世界中，这是理想的实现 致公司全体人员.
为了什么？ 如果我们要改造的不只是公司的一部分，消除的不仅仅是一个限制，而是所有的一切，让公司变得灵活，代码快速到达客户，没有任何问题，我们需要每个人都忠于这个想法DevOps 的。 您将无法将该方法应用于坚决反对它的服务和团队。
为了表现出忠诚度，我们必须告诉每个人我们尝试过——我们有结果，也尝试一下吧！ 这将增加对我们所做的事情的兴趣和忠诚度，人们现在就会开始尝试做某事。 正如实践所示，当我们告诉你我们尝试了什么以及我们取得了什么成就时，其他团队开始询问我们是如何做的以及做了什么。 他们查看实现、代码、文档，提出问题并尝试改变自己的某些东西。
谈论你所做的事情很重要。 通过这种方式，您将说服那些想以旧方式做所有事情的保守派加入您的阵营，并将他们转变为创新者。
在总
选择服务，作为起点 - 我们将在公司中开始变革的地方。 我们识别与服务有关的每个人 和他们一起 构建价值流图，我们测量并查看限制在哪里以及有什么。
创建一个新的临时团队，这将解决问题。 基于测量和价值流图 我们绘制了一张新地图，在其中突出显示了我们将解决的限制。 基于这个限制 设定任务，团队将处理该问题。 任务应该是 必然是聪明的 - 具体的、可衡量的、与当前任务相关且时间有限的。
重复该过程，直到我们将所有服务完全转变为所需的形式并消除所有限制。
奖金。 有用的材料
对于那些决定自己进行 DevOps 的人。
凤凰计划
原标题是《凤凰计划：一本关于它、DevOps 和帮助您的企业获胜的小说》。 这是一本关于 DevOps 的小说——讲述一名员工如何成为一个总是火热的部门负责人的故事。 新老板被赋予了任务：
“你有几年的时间来把一切做好，这样我们才能最终快速有效地向客户交付我们的产品。”
“凤凰计划” 一本关于 DevOps 如何让生活变得更好的小说”是一本适合所有管理者的书，因为这些人对公司发生的事情做出决策。 如果您是一名工程师或程序员，并且希望在您的公司中开始变革和转型，请购买一本书并将其交给管理层。 这本小说解释了一切，读起来又快又容易。
开发运营指南
书上比较复杂。 该书几年前以英文版出版，标题为“DevOps 手册如何在技术组织中创建世界一流的敏捷性、可靠性和安全性”，但现在已经有俄语版。 这是真的 手册-实用指南：如何进行测量、什么是价值流图以及为什么需要它、去哪里、按什么顺序。 这本书适合那些想自己做所有事情的人。 最重要的是，它包含其他公司的经验示例。
例如，它讲述了一家公司如何构建价值流图，并意识到其局限性不在于产品，而在于收银员从商店步行到下一个办公室来使用该产品。 他们没有用程序解决问题，而是简单地为销售人员购买了平板电脑，现在没有人去任何地方，所有操作都在他们的工作场所进行。 结论：价值流图不仅可以扩展到软件，还可以扩展到组织中的所有流程。
加快
完整标题：“加速：精益软件和 DevOps 的科学：构建和扩展高性能技术组织。” 这是下一个级别——硬核。 这本书去年出版，到目前为止只有英文版，而且是关于研究的。 作者——Nicole Forsgren、Jez Humble 和 Gene Kim——多年来一直在不同的公司使用不同的实践，并研究哪些实践会影响什么以及如何影响。
第二章关于测量，提到了价值流图、我提到的指标等等，还详细描述了测量过程。 作者使用问卷和自我跟踪任务进行测量。 它详细描述了哪些指标可以正确测量，哪些指标不应该测量，以及测量中的人为错误。 如果您在测量时遇到困难，请参阅《加速》一书的第二章。 如果你的团队只是有很多实践，但不清楚现在应用哪些实践、以后应用哪些实践、哪些真正有效、哪些无效——请阅读本书，本书会解释一切。
转型是 DevOps 和管理交叉点的一个问题。 在开发、运营和测试交叉点的同一领域中的某个地方，我们尝试讨论的主题 ，需要同样的集成来创建优质产品 - 主题 。 节庆管理 提出了 - 这意味着每个人都在寻求转型的想法。 27月28-XNUMX日加入我们，我们将整合、转型。
来源： habr.com
