赋予开发人员操作责任大大提高了
来自客户和技术的服务质量< br的观点。传统模型是将软件带到分隔开发和操作的墙，然后将其扔在
上，然后将其遗忘。不在亚马逊。构建它，然后运行它。
这使开发人员可以接触到其软件的日常操作。它还使他们与
客户进行日常联系。客户反馈循环对于提高服务质量至关重要。
我特别考虑了一组开发人员，这些开发人员是：
被聘为开发人员，很少/根本没有提及与操作相关的任务。
传统上，操作团队需要“丢掉代码”。工作时间表，并且对“传呼机职责”，参加灾难恢复，撰写事后调查等想法怀有敌意，尤其是在正常工作时间以外。 （注意：为此，我只考虑很少的故障；我不建议在工作组的工作时间之外增加下班后的客户支持。）
目前不负责编写/支持对他们的应用程序的监视或警报。
假设有一个团队正在快速开发新的云微服务，其配置文件的状况越来越差，因为将这些服务交给操作团队并不理想，因为他们无法跟上他们对深入了解的了解。有效管理和监视它们所需的服务。 “创建，运行它”对于该团队来说会更好，因为可以将任务委派给每个负责的团队成员。因此，该团队将开始参与设计服务的基础结构，监视/警报工具，并（很少）响应中断事件。
我对方法特别感兴趣，并以实际示例为后盾。如何在其他工作场所成功实现此目标，以及在实现此目标时是否要遵循任何规范步骤？任何可以支持答案的文章链接将非常有用。
#1 楼
我认为最简单的方法是更改其性能目标，以便它们基于可靠性以及交付代码。卖掉它是因为公司不能没有这两者而成功，那么为什么只将开发商视为一个？让他们达到业绩目标的最佳方法就是参与运营。这很难，您不能指望他们从一开始就加入。它们也需要按价值出售。评论
我同意这一点，重要的是要使人们想做到这一点，而不仅仅是告诉他们去做。
–凯尔·斯汀坎普（Kyle Steenkamp）
17年12月14日在12:05
#2 楼
当涉及到影响企业文化时，最好的方法可能是通过众所周知的“煮青蛙”方法。您必须将这些任务缓慢地介绍给开发人员，因为我知道我自己（作为开发人员）会讨厌一次承担所有这些新职责。首先，首先介绍一个或两个仅在正常工作时间执行的新任务。他们需要学习如何进行devop，这可能是（到目前为止）纯代码开发人员的学习过程，并且可能需要一些监督。由于您提到他们习惯9-5，因此他们也可能对改变工作与生活的平衡抱有敌意。此时，将数据记录在新流程上，以备后用（让他们编写此代码，数据总是有用的）。因此第一个，第二个和第四个要点都差不多完成了），将您介绍的第一个任务作为候选对象带到标准工作时间之外执行。您可能会对此感到反感，甚至可能会看到一些减员，这取决于您推动这种方法的力度以及根深蒂固的五口工作文化。为了对此进行防御，希望您的数据支持这样的想法，即超出标准工时的工作将很少发生，仅在极端情况下才会发生，并且将极大地使业务和客户受益。如果您的数据不支持此功能，那么最好准备好应对这种选择的后果。
即使有了数据，让开发人员编写监视/更改代码（使他们成为devop，但仍然主要是dev）并保留备用ops团队作为一线支持（如其他一些建议），可能仍然更容易。就像我说的那样，进行小更改对于避免反弹很重要。在标准时间以外集成开发人员的工作将具有挑战性，因为他们可能会知道如果不喜欢，他们可以找其他地方找工作，因为开发人员的市场目前很旺盛，尤其是如果他们已经具有开发技能。买者自负！
评论
但是，不是因为您可以在任何时候部署/发布而不是在传统的星期六23:00（下午11点）部署/发布，都不需要在非工作时间做事的重要功能之一吗？
– Juha Untinen
18-09-25在5:22
#3 楼
特别是从DevOps之外看，如果您正在谈论大型（ish）企业环境，那么SAFe方法论是鼓励这种行为的相当不错的方法。 ：项目从发行火车开始。目的（以及对资助者的期望）是长期的。我已经说了多年了，没有一个“组建一个团队三个月，然后就让他们失望”的业务。
我几乎总是看到火车以100％的项目/变更团队的身份进行第一次增加，而第二次则以一定比例分配时间来进行工作。 3rd增量管理意识到他们将要遇到问题，因此开始增加团队来尝试处理Run溢出问题，以使他们现在经验丰富的开发人员和工程师有时间继续满足新的要求。
能够继续交付项目成果而不会陷入繁琐的维护工作的团队，并不能立即期望加入培训的新团队只是100％的支持团队，而是承担相当一部分的变更工作将被处理，然后您最终将拥有拥有他们正在默认构建的产品的交付团队，而现在他们已经成为一个运行团队，则无需立即将它们全部付诸实践，而是可以慢慢融入他们的生活日常活动。
该模型显然存在一些弱点的地方是企业的定价。通常，我希望变更资源的价格要比运行资源的价格高得多，通常与主要供应商的运行合同是固定价格，其目的是使他们的钱用于不断改进，从而节省成本。
话虽如此，考虑将变更团队作为发布培训的一部分而站起来只是简单地进行持续改进并不是一件容易的事。如果他们可以建立或做某事，可以提高他们专注于新项目交付的能力，而不必担心“一切照旧”的工作，则应将持有资金的人根据所获的利益积压并确定优先级。释放火车。
评论
好吧，好吧，好吧，@ Tensibai现在正遭受一些TLA（三字母缩写）的困扰，“我”是偶然的（想我）知道的。。。还有BTW（grrrr，另一个），如果您遭受了ESL（grrrr，另一个），并且在SCM（ggrrrr，另一个）培训班中发音BAU，那么更好地注意听众不会将其翻译为“ bouw” （相同的声音...），因为在英语中会像“ build”。
– Pierre.Vriens♦
17年3月18日在15:10
对此感到抱歉，我常常忘记当我在一家公司使用一些不常见的缩写词（所有人都一直使用）的情况时，会感到多么沮丧，或者这在该行业起步时令人讨厌，并且不得不与左右左右吐槽TLA的人打交道我似乎陷入了同样的陷阱。我已经更新了答案，删除了所有的缩写词：）
– hvindin
17 Mar 19 '17 at 0:37
好吧，更好的是，您甚至已经废弃了@Tensibai的评论……PS 1：我相信您可以接受我刚刚应用于答案的错字更正……PS 2：什么是SAF？我敢打赌，它不是像“安全访问工具”那样的东西，不是在大型机环境中使用的东西，不是一种可以与RACF，ACF2或Top-Secret集成的API ...
– Pierre.Vriens♦
17 Mar 20 '17在10:56
如果您有兴趣，我已经添加了到Scaled Agile Frameworks网站的链接。就我个人而言，我有点不喜欢这种方法，但是我无法想到一种更好的方法，一旦团队/项目/规模超过一定规模，就可以使团队表现出负责任的态度。
– hvindin
17 Mar 20 '17在13:44
#4 楼
恕我直言，恕不直言。首先-听起来像是一种惩罚；）没有一个人甚至很小的开发团队都无法合理地长期支持软件开发过程（即生产中！）中使用的工具或工具集。时间。到那儿去，做到这一点:)
随着工具（客户）客户群的增长，支持职责也趋于扩大。如果专门承担这些职责，则开发团队最终可能会主要提供支持，而在开发过程中几乎没有/几乎没有时间。有效的死胡同-在这样的环境中有多少开发人员想要坚持下去？开发人员团队成员的支持职责。
第一线支持团队当然会退回到开发人员团队（同样是团队，而不是单人！）来解决他们无法直接解决的问题。是的，一开始可能很困难，但是情况会变得更好。它应该是一种协作-这是DevOps的一部分。
评论
抱歉，我认为我们在“运行它”的范围上存在分歧。 :)我并不是要给人以他们将执行支持职责的印象；我们有大量的员工，特别关注生产体系结构的实施，应监控的内容的设计以及如何，如何扩展，那。
–安东尼·内斯（Anthony Neace）
17 Mar 11 '17 at 18:42
知道了是的-完全不匹配。我可能会删除此答案。
–丹·科尼莱斯库（Dan Cornilescu）
17年3月11日19:19
没问题，我认为它可以留下。其他正在搜索类似问题的人可能与您具有相同的思路，这可能与他们有关。再次抱歉，我应该在问题正文中更具体一些！
–安东尼·内斯（Anthony Neace）
17年3月11日在20:01
#5 楼
这最终取决于公司的规模和结构。您的公司实际上可以分为三个阶段：启动阶段（少于150名工程师）。当然，开发人员需要运行自己的软件。每个人都在创业公司这样做。您可能甚至没有团队的开始，但是即使您这样做，规模也很小，并且进展速度是如此之快，以至于没有办法将足够的知识传递给另一个团队以使其成功运行。获得成功。
中型企业（超过150名工程师，但只有一个运营团队）。在这个阶段，公司的客户流失率开始变得过高，构建软件的工程师不一定会同时运行它。您已经不认识每个人，并且很难有效沟通每个人的运作情况。它将开始变得混乱。在此阶段，您想转向Google模式，每个团队都必须操作他们的软件，但不一定要操作它。他们将在一开始就对其进行操作，但是构建软件的很大一部分是将其运行成本降低到一定程度，在这种情况下，负载应足够小，以使运营团队可以签署运行要求。
拥有多个业务部门的大型企业（每个部门都有自己的运营团队）：在这一阶段，您可以回到亚马逊模型，在该模型中，每个团队都必须开发和运营自己的服务。每个业务部门的规模都必须足够小，以使每个人都可以彼此了解，因此，大约有150名工程师，您基本上都是一家初创公司。亚马逊的每项AWS服务或多或少地独立运作，并且都为它们服务。没有“一刀切”的解决方案。
#6 楼
我对此的看法（如果我面临这样的诫命，或者您会称呼它），将类似于“What else would you expect?!?!”。因为，偶然地：没有它，我什至无法生活，并且
我喜欢吃自己的（狗）食物。 />让我进一步解释一下...
我的业务/爱好/热情是scm，尤其是在大型机环境中。无论我走到哪里（微调产品以适应客户需求），我所强加的第一个要求（在我的合同中）都是对我们实现的系统进行的任何调优都是通过相同的系统进行的。通过这样做（正确，最多可能需要几个小时，例如半天），我们从中获得了这些好处（列表不完整）：确实使系统正常运行。如果有任何问题，我只查询系统（并教客户如何在没有我帮助的情况下查询系统）。
如果我在X个月/年内接到电话（要升级到新版本，），我想知道（记住）“我”以前做过的事情（我唯一信任的是系统告诉我的内容，又提醒我）。
我只需要询问一次客户在他们的网站上做特定的事情（很难记住命名约定），或者说服他们授予“系统”所需的权限（不是我的权限……）。系统...正在生产中。您很可能会自己遇到错误，逻辑错误或缺少功能（以及没有的功能）。那些都是非常积极地让他们尽快解决的问题，例如提高生产力。
...如果您愿意，我还可以添加其他十几个原因...
但是，在您自己在家尝试之前，请注意避免以下陷阱：
您希望每个人都参加聚会（使用系统），因为只有1个“例外”（又名公司的经理/所有者？）可能会破坏聚会（您认为您可以信任自己的系统，但是后来有人做了些事情无需询问/使用系统）。这些情况可能会花费您几天的时间来发现...
新用户可能会抱怨，使用此（新）系统，需要花费更多的时间才能完成工作（与以前使用的相比）。在任何有意义的地方，他们都会以此为由来迟到完成工作。到那时，您最好由高层管理人员负责，因为否则您的项目/系统可能会受到指责。
请确保您确实了解自己的系统以及如何配置它以满足您的需求。作为一个示例（以我为例）：您想要配置系统，以便使用操作环境交付到实验环境，而不是相反...我已经看到过去发生的事情...使用（滥用）测试系统以交付到高度安全的环境。
评论
这也可能值得在SE职场问到