我如何说服团队中的开发人员接受“您构建，运行”？

我如何说服团队中的开发人员拥抱“您构建，运行”？这样，我就牢记沃纳·沃格斯的这句话：

从客户和技术的角度来看，赋予开发人员操作职责可以极大地提高服务质量。传统的模型是将您的软件带到隔离开发和操作的墙壁上，将其抛弃然后忘却它。不在亚马逊。您构建它，然后运行它。这使开发人员可以接触到其软件的日常操作。它还使他们与客户进行日常联系。客户反馈回路对于提高服务质量至关重要。

我特别想到了一组开发人员：

• 被雇用为开发人员角色，很少/根本没有提及与操作相关的任务。
• 传统上，向操作团队“扔掉代码”。
• 传统上，工作时间表是9-5，特别是在正常工作时间之外，对“传呼机职责”，参加灾难恢复，撰写验尸等想法充满敌意。（注意：为此，我只考虑很少的停机；我不建议我们在下班后为该团队的工作量增加客户支持。）
• 当前不负责编写/支持对其应用程序的监视或警报。

假设有一个团队正在快速开发新的云微服务，其配置文件的状况越来越差，因为将这些服务交给运维团队并不理想，因为他们无法跟上对运维的深入了解。有效管理和监视它们所需的服务。“创建，运行它”对于该团队来说会更好，因为可以将任务委派给每个负责的团队成员。因此，该团队将开始参与设计基础架构，为服务提供监视/警报工具，以及（很少）响应中断事件。

我对方法学特别感兴趣，并以实际示例为后盾。如何在其他工作场所成功实现此目标，以及在实现此目标时是否要遵循任何规范步骤？任何可以支持答案的文章链接都将非常有帮助。

我认为最简单的方法是更改​​其性能目标，以便它们基于可靠性以及交付代码。卖掉它是因为公司不能没有这两者而成功，那么为什么只将开发者视为一个？他们达到绩效目标的最佳方法是参与运营。

最终，您需要说服他们，这是公司成功并因此成功的最佳途径。很难，您不能指望他们从一开始就加入。它们也需要按价值出售。

当涉及到影响企业文化时，最好的方法可能是通过众所周知的“煮青蛙”方法。您必须将这些任务缓慢地介绍给开发人员，因为我知道我自己（作为开发人员）会讨厌一次承担所有这些新职责。

首先，首先介绍一个或两个仅在正常工作时间执行的新任务。他们需要学习如何进行devop，这可能是（到目前为止）纯代码开发人员的学习过程，并且可能需要一些监督。由于您提到他们习惯于9-5，因此他们也可能对改变工作与生活的平衡抱有敌意。此时，将数据记录在新流程上以备后用（如果他们编写了此代码，则数据总是有用的）。

稍后，当您要用尽新的开发任务（因此，第一，第二和第四项目要点几乎已完成）时，将您介绍的第一个任务作为候选者带到标准工作时间之外执行。您可能会对此感到强烈反感，甚至可能会看到一些减员，这取决于您推动这种方法的力度以及根深蒂固的五口工作文化。为了防止这种情况，希望您的数据支持这样的想法，即超出标准时间的工作将很少发生，仅在极端情况下发生，并且将极大地使业务和客户受益。如果您的数据不支持此功能，那么您最好准备好应对这种选择的后果。

即使有了数据，让开发人员编写监视/更改代码（因此他们成为开发人员，但仍主要是开发人员）并保留备用操作人员团队作为一线支持可能仍然更容易（如其他人所建议的那样）。就像我说的那样，进行小更改对于避免反弹很重要。在标准时间以外集成开发人员的工作将具有挑战性，因为他们可能会知道，如果他们不喜欢，他们可以找别的地方找工作，因为开发人员的市场目前很强劲，尤其是如果他们已经具有开发技能。买者自负！

特别是从DevOps之外看，如果您正在谈论大型（ish）企业环境，那么SAFe方法具有鼓励这种行为的相当不错的方法。

从本质上讲，它可以归结为几个关键阶段：

• 项目从发布火车开始。目的（以及对资助者的期望）是长期的。我已经说了好多年了，这与“组建一个团队三个月然后让他们失望”无关。

• 在项目的整个过程中，发行培训将不可避免地吸引更多的人，因为更多的新项目要求都是基于新实现的商机以及持续的维护风格工作而产生的。

• 我几乎总是看到火车以100％的项目/变更团队的身份进行第一次增加，而第二次增加则分配了一部分时间来运行工作。第3次增量管理意识到他们将要遇到问题，因此开始增加团队来尝试处理Run溢出问题，以使他们现在经验丰富的开发人员和工程师有时间继续满足新的要求。

• 如果实现了适当的平衡，则项目团队能够继续交付项目成果而不会陷入繁琐的维护工作，而立即加入培训的新团队不会立即成为100％的支持团队，而是承担起将要处理的变更工作中的相当一部分，然后您最终将要拥有交付团队，这些交付团队拥有默认情况下正在构建的产品，既然他们是一个运行团队，则无需立即全力以赴，相反，它只是慢慢融入他们的日常活动中。

该模型显然存在一些弱点的地方是企业的定价。通常，我希望更改资源比运行资源要花更多的钱，通常与主要供应商的运行合同是固定价格，其目的是使他们的钱用于不断改进，从而节省成本。

话虽如此，将变更团队作为发布培训的一部分而站起来只是简单地提供持续的改进并不难。如果他们可以建立或做某件事，可以提高他们专注于新项目交付的能力，而不必担心“一切照旧”的工作，则应将持有资金的人根据所获的利益积压并确定优先级。发布火车。

恕我直言，You build it, you run it不应从字面上看。开始-听起来几乎像是一种惩罚;）

没有一个人甚至很小的开发团队都能长期合理地支持在软件开发过程（即生产中！）中使用的工具或工具集。去过也做过 ：）

随着工具（客户）客户群的增长，支持职责也趋于扩大。如果专门承担这些职责，则开发团队最终可能会主要提供支持，而在开发过程中几乎没有/几乎没有时间。实际上是一个死胡同-在这样的环境中有多少开发人员想要坚持下去？

拥有一支专业的第一线支持团队对防止开发团队成员长期遭受支持工作所带来的挫败感，压力和其他影响至关重要。

一线支持团队当然会退回到开发人员团队（再次是团队，而不是单人！），因为他们无法直接解决问题。是的，一开始可能很困难，但是情况会变得更好。它应该是一种协作-这是DevOps的一部分。

这最终取决于公司的规模和结构。您的公司实际上可以分为三个阶段：

1. 启动阶段（150名以下的工程师）。当然，开发人员需要运行自己的软件。每个人都在创业公司这样做。您甚至可能没有运营团队开始，但是即使您这样做，它也很小，而且进展速度如此之快，以至于没有办法将足够的知识传递给另一个团队以使其成功运行，足以使他们迅速成功的。

2. 中型企业（超过150名工程师，但只有一个运营团队）。在这个阶段，公司的客户流失率开始变得过高，构建软件的工程师并不一定会继续运行它。您已经不认识每个人，并且很难有效地沟通以使每个人都能正常工作。它将开始变得混乱。在此阶段，您想转向Google模式，每个团队都必须操作他们的软件，但不一定要操作它。他们将在一开始就对其进行操作，但是构建软件的很大一部分是将其运行成本降低到一定程度，在这种情况下，负载应足够小，以至于运营团队可以签署运行要求。只有这样，它才算完成。

3. 具有多个业务部门的大型企业（每个部门都有自己的运营团队）：在此阶段，您可以返回到亚马逊模型，在该模型中，每个团队都必须开发和运营自己的服务。每个业务部门的规模都必须足够小，以使每个人都可以彼此了解，因此，大约有150名工程师，而每个人基本上都是一家初创公司。亚马逊让每个AWS服务或多或少地独立运作，并且为它们服务。

您必须弄清楚公司处于哪个阶段和/或进入哪个阶段并采取相应的行动。没有“一刀切”的解决方案。

我对此的看法（如果我面临这样的诫命，或者您会称呼它），将类似于“ What else would you expect?!?!”。因为，偶然地：

• 没有它，我什至无法生活，
• 我喜欢吃我自己的（狗）食物。

让我进一步解释一下...

我的业务/爱好/热情是scm，更具体地说是在大型机环境中。无论我走到哪里（微调产品以满足客户的需求），我（在我的合同中）强加的第一个要求就是，对我们实现的系统进行的任何调整都是通过同一系统进行的。通过这样做（确实需要花费几个小时，例如最多半天），我们从中获得了这些好处（列表不完整）：

• 我几乎没有记录我为使系统正常运行所做的任何事情。如果有任何问题，我只查询系统（并教客户如何在没有我帮助的情况下查询系统）。
• 如果我在X个月/年内接到电话（要升级到新版本？），我想知道（记住）“我”以前在做什么（而我唯一可以信任的就是系统告诉我的内容，又名让我想起）。
• 我只需要向客户询问一次有关如何在其站点中执行特定操作的操作（很难记住命名约定），或者说服他们向“系统”授予所需的权限（而不是对我...）。
• 您正在continuously对自己的系统进行质量检查…正在生产中。您很可能会自己遇到错误，逻辑错误或缺少功能（以及没有的功能）。这些都非常积极地促使他们尽快解决……例如，提高生产力。
• ...如果您愿意，我还可以添加其他一些原因...

但是，在您自己在家尝试此操作之前，请注意一些陷阱，以避免：

• 您希望每个人都参加聚会（使用系统），因为只有1个“例外”（又名公司的经理/所有者？）可能会破坏聚会（您认为您可以信任自己的系统，但是后来有人做了些事情无需询问/使用系统）。这些情况可能会让您花费数日才能发现...
• 新用户可能会抱怨说，通过使用此（新）系统，与完成以前的工作相比，他们需要更长的时间才能完成工作。在任何有意义的地方，他们都会以此为由来迟到完成工作。到那时，您最好由高层管理人员为您服务，否则您的项目/系统可能会受到指责。
• 确保您确实了解自己的系统，以及如何配置它以满足您的需求。作为一个示例（以我的情况为例）：您想要配置系统，以便使用操作环境将其交付到实验环境，而不是相反...我已经看到过去发生的情况...使用（滥用）测试系统来交付高度安全的环境。