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

Question

我如何说服我的团队中的开发人员接受“您构建它，您运行它”？由此，我想到了这是沃纳·沃格斯的话：

从客户和技术的角度来看，赋予开发人员操作职责极大地提高了服务质量。传统的模型是将您的软件带到将开发和操作分离开来的墙壁上，然后抛出它，然后忘记它。在亚马逊可不是。你建造它，你运行它。这使开发人员接触到日常操作他们的软件。它也使他们与客户进行日常接触。这个客户反馈循环对于提高服务质量至关重要。

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

• 被聘为开发人员，很少或根本没有提到与操作相关的任务。
• 传统上，“将代码抛出墙”给行动小组。
• 传统上有9-5个工作计划，并且积极反对“寻呼机职责”的想法，参与灾难恢复，写死后等，特别是在正常的工作时间之外。(注意:对于这一点，我只想到很少会中断；我并不是建议我们在这个团队的工作量中增加课后客户支持。)
• 目前不负责编写/支持、监视或提醒其应用程序。

假设有一个团队正在快速开发新的云微服务，其配置文件越来越多，以至于将这些服务交给ops团队并不是最优的，因为他们在获得有效管理和监视这些服务所需的深入知识方面跟不上进度。“您构建它，您运行它”将更好地为这个团队工作，因为任务可以委托给每个负责的团队成员。因此，这个团队将开始参与基础设施的设计、服务的监视/报警工具的设计，以及(非常罕见的)对中断事件的响应。

我特别感兴趣的方法，支持现实世界的例子。这是如何在其他工作场所成功实现的，以及在实现时是否需要遵循任何规范步骤？任何可以支持答案的编写的链接都是非常有用的。

Answer 1

我认为最简单的方法是改变他们的性能目标，这样他们就可以建立在可靠性和交付代码的基础上。销售它，因为公司不可能成功，没有两者，所以为什么开发商应该只衡量一个？那么，他们实现绩效目标的最佳方式就是参与运营。

最终，你需要说服他们，这是公司成功的最佳方式，因此也是他们成功的最好方式。这很难，你不能指望他们从一开始就在船上。它们也需要按价值出售。

Answer 2

当涉及到影响商业文化时，最好的方法可能是通过众所周知的“煮青蛙”的方法。您必须缓慢地向开发人员介绍这些任务，因为我自己(作为一个开发人员)自己也不愿意同时承担所有这些新的责任。

首先，首先介绍一个或两个新的任务，只能在正常的办公时间内执行。他们需要学习如何做devop，这可能是一个(到目前为止)只使用代码开发的学习过程，并且可能需要一些监督。他们可能也会对改变工作-生活平衡的想法充满敌意，因为你提到他们习惯了9-5。此时，记录新进程的数据以供以后使用(让他们编写这段代码，数据总是有用的)。

稍后，当您没有需要介绍的新任务时(因此第一个、第二个和第四个要点几乎完成了)，将您介绍的第一个任务作为候选人在标准工作时间之外执行。你可能会在这一点上看到一些反弹，甚至你可能会看到一些消耗，这取决于你对此的推动力度，以及五人工作文化根深蒂固的程度。为了防止这种情况，希望您的数据支持这样的观点:超过标准时间的工作将是罕见的，只会在极端情况下发生，并将极大地造福于业务和客户。如果您的数据不支持这一点，那么您最好准备好应对这种选择的后果。

即使有了数据，让开发人员编写监视/警报代码(因此他们变成了_dev_ops，但仍然主要是开发人员)并保持备用ops团队作为第一线支持(正如其他一些人所建议的那样)可能更容易。就像我说的，小的变化对于避免反弹是很重要的。将devs的工作整合到标准时间之外将是一项挑战，因为他们可能知道，如果他们不喜欢的话，他们可以去别处找工作，因为现在devs的市场非常强大，尤其是如果他们已经具备了开发人员的技能。注意，清空者！

Answer 3

国际水文学组织的You build it, you run it不应被视为字面意思。首先，这听起来几乎像是一种惩罚;)

没有一个人，甚至是小型开发团队能够合理地支持在软件开发过程中使用的工具或工具集(即在生产中！)有很长一段时间。去过那里，做过:)

随着工具(集合)客户群的增长，支持职责往往会扩大。如果完全承担这些职责，开发团队最终可能会做大部分支持工作，几乎没有/没有时间进行开发了。实际上，一个死胡同--有多少开发人员愿意在这样的环境中停留？

拥有专业的第一线支持团队对于防止长期暴露于支持职责对开发人员团队成员的挫折感、压力和其他影响至关重要。

当然，第一线支持团队会倒退到开发团队(同样，团队，而不是单人！)对于不能直接涵盖的问题。是的，一开始可能很困难，但事情会好起来的。这应该是一种协作--这是DevOps的一部分。