问题描述
想知道如何说服团队中的开发人员接受“你构建它，你运行它”的理念。他引用了Werner Vogels的一句话：“让开发人员承担运营责任极大地提高了服务的质量，无论是从客户还是技术的角度来看。传统模式是将软件交给开发和运营之间的墙壁，然后忘记它。但在亚马逊不是这样。你构建它，你运行它。这使得开发人员与他们的软件的日常运营接触。这也使他们与客户日常接触。这种客户反馈循环对于提高服务质量至关重要。”用户特别关注的是如何在其他工作场所成功实施这一理念，以及在实施过程中是否有一些标准步骤。他希望能够提供一些实际案例和相关链接来支持回答。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1：改变绩效目标
最简单的方法是改变开发人员的绩效目标，使其不仅仅基于交付代码，还要基于可靠性。将其作为公司的成功所必需，为什么只有开发人员在一个方面被衡量？让他们明白这对公司的成功以及他们个人的成功都是最好的方式。当然，你不能指望他们一开始就完全接受这一理念，他们也需要被说服这一价值。
方案2：逐步引入
在影响企业文化方面，最好的方法可能是通过“煮青蛙”的方法。你必须逐步向开发人员引入这些任务，因为我知道作为开发人员，我会对一下子承担这么多新的责任感到不满。首先，只引入一两个新任务，只在正常工作时间内执行。他们需要学习如何进行DevOps，这可能是一个相当大的学习过程，可能需要一些监督。他们对于改变工作生活平衡的想法可能也会产生敌意，因为你提到他们习惯了9-5的工作时间。此时，记录有关新流程的数据以备后用（让他们编写这些代码，数据总是有用的）。随着你逐渐用尽新的DevOps任务（因此第一、第二和第四个要点几乎完成），将首次引入的任务作为在标准工作时间之外执行的候选任务。你可能会遇到一些反对意见，甚至可能会看到一些人员流失，这取决于你对此的强烈推动程度以及工作结束时间的文化程度。为了防止这种情况发生，希望你的数据支持这样一个观点：超出标准工作时间的工作将是罕见的，只在极端情况下发生，并且将极大地使企业和客户受益。如果你的数据不支持这一点，那么你最好准备好应对这个选择的后果。即使有了数据，让开发人员编写监控/警报代码（使他们成为开发人员，但仍然主要是开发人员），并将备用运维团队作为前线支持（正如其他人建议的那样）可能仍然更容易。正如我所说，小的变化对于避免反对意见非常重要。将开发人员超出标准工作时间的工作整合到他们的日常活动中将是具有挑战性的，因为他们可能知道如果他们不喜欢这种情况，他们可以在其他地方找到工作，因为目前开发人员的市场非常强劲，尤其是如果他们已经具备DevOps技能。买方自负！
方案3：根据公司规模和结构选择合适的模式
不同的组织有不同的组织结构、需求和文化。根据公司所处的阶段选择合适的模式。以下是三个可能的阶段：
1. 初创阶段（少于150名工程师）：在初创阶段，开发人员需要运行他们自己的软件。在初创公司中，每个人都这样做。你可能甚至没有运维团队，但即使有，它也很小，进展速度非常快，没有办法将所需的知识迅速传递给其他团队，以便他们能够成功运营。
2. 中型企业（超过150名工程师，但只有一个运维团队）：在这个阶段，公司的变动开始变得太大，开发软件的工程师不一定会留下来运行它。你已经不认识每个人了，很难有效地沟通，以便每个人都参与运维工作。这将变成混乱。在这个阶段，你可以采用Google的模式，每个团队都必须将他们的软件操作化，但不一定要运行它。他们会在开始时运行它，但构建软件的一个重要部分是将其运行成本降低到一个程度，使得运维团队可以负责运行它。只有这样，它才被认为是完成的。
3. 大型企业，拥有多个业务单元（每个单元都有自己的运维团队）：在这个阶段，你可以回到亚马逊的模式，每个团队都必须开发和运行自己的服务。每个业务单元必须足够小，以便每个人都互相了解，因此在大约150名工程师以下，你将每个团队都视为一个初创公司来运营。亚马逊将每个AWS服务都运行得相对独立，这对他们来说是有效的。
你必须弄清楚你的公司处于哪个阶段，或者正在进入哪个阶段，并相应地采取行动。没有“一刀切”的解决方案。
方案4：关注团队合作和互相支持
不同的组织有不同的组织结构、需求和文化。有些开发人员认为运营问题不是他们的问题。然而，一个良好的开发文化是开发人员关心系统的顺利运行，他们也关心需要支持他们的运维同事。我们开发人员过去常常携带寻呼机以防运营人员无法解决问题。虽然团队有明确的责任，但由于开发和运营系统的复杂性，存在一条模糊的界线。如果有些员工不理解这一点，那么在某些情况下可能会很困难。我并不是说开发人员应该一直支持运维工作。如果这种情况发生得太频繁，那么肯定存在问题需要解决。要灵活一些，试着互相照顾。