讨论：当前运维团队在软件开发中的角色
在过去的几年中，随着云计算和开发加运维现象的出现，出现了对传统的运维团队的角色的讨论，因为在当前的软件开发团队中经常会看到他们的身影。InfoQ将会深入地探究此次讨论，以更好地理解其中所涉及到的各个不同的方面，以及各种方法之间的平衡。
本次讨论的核心是这样的重大问题：
谁应该负责对生产环境中的应用程序进行管理、监控和运维？
在开始关于此次争论的讨论之前，我们先是邀请了New Relic公司（基于SaaS的应用程序性能管理工具的提供商）的工程主管Bjorn Freeman-Benson和InfoQ运维社区的首席编辑Carlos Armas。然而，这只是讨论的开始，随着讨论的进行和展开，InfoQ会将最近的讨论更新到本文中，并且还可以通过关注#roleofops标签来关注Twitter上的讨论。我们希望你也参加到本次讨论中，所以请选择发布带有#roldofops标签的推特信息，或者向[email protected]发送邮件来说明你的看法，也可以在本文的评论中留下你的声音。
Bjorn Freeman-Benson: 关于改变运维的角色这个主题，已经有了大量的言论、网志以及幻灯片。在大量的交流中，人们提出了将开发和运维变得更加紧密的要求。他们称之为开发加运维或者其它术语。尽管我在New Relic公司的同事和我在总体上都持赞同的意见，但是我们认为公司应该考虑采用更具有决定性的步骤，以达到更有效的运维管理——也就是，考虑让每个开发团队都负责他们自己的应用程序的部署和性能问题。
让我们考虑一下，为什么这并非像它听起来那样不同寻常或者极端。
首先，对于应用程序，谁能比创建它的团队更了解它呢？这使得在将应用程序部署到数据中心或者云中的时候，应用程序开发团队需要与业务应用的所有者商讨，然后对应用程序进行设计、架构和编码，选择、测试并集成应用程序的各个组件（应用程序服务器、操作系统、数据库、集成中间件等等），创建原型，执行功能测试，可能还要进行负载和可扩展性的测试，向业务人员演示应用程序的功能，最终为生产环境准备就绪。几周甚至几个月来日积月累的知识怎么可能一下子就传授给运维团队呢？
开发团队应该做出重要的部署选择吗？——增加或者扩展硬件服务器，是否对服务器采用虚拟化，哪种CPU和内存是最佳的等等。开发团队应该决定他们所需要的最佳的性能监控和日志记录吗？开发团队应该监控、处理警告、把握性能和有效的时间，并且在应用程序崩溃的时候处理来自于业务部门歇斯底里的电话吗？（为什么运维人员会处理这些有趣的事儿？）我知道这种方法会有用的——在New Relic公司中，我们自己就使用它来管理世界上的最忙碌的SaaS应用程序之一。很讽刺的是，我们的SaaS应用程序耗费了将近4000个开发团队来管理他们的生产环境中的应用程序。
Carlos Armas: 这样的想法很具有吸引力，因为设计和构建系统的团队最适合对其进行运维、监控和扩展。由这个逻辑递推，我主张开发团队应该负责处理公司的账务，因为软件开发者都很擅长处理数字，或者由于他们对环境很关心，因此应该在工作之后清理办公室并将垃圾箱倒到外边的回收处。这样做就忽略了几百年来的重要实践：分工。事实上，开发团队比其他人更加了解应用程序，但这并不能成为要他们负责对发布到生产之后的代码进行运维和维护的原因。
我假定自己是公司所有者的角色，并给出三个原因，说明为什么我不想这样的事情发生在我的公司中：
1）财务上的：软件开发者的平均工资总是要比运维支持工程师的高。作为公司的所有者，为什么我想要让我最昂贵的团队做运维任务呢，那种任务可以由其它团队完成，那样更节省资金，更有效。在任何敏捷团队中，任何好的Scrum教练都会告诉我们，他们的主要任务之一就是移除障碍，并让隐藏的工作可见，从而开发团队能够更有效地开发代码。为什么我想要将更多的障碍和额外的工作强加给开发团队，从而降低他们的效率呢？
2）质量：我相信检查和平衡，因为没有人是完美的。当团队负责应用程序完整的生命周期时，客户最终要吞下这个苦果：很差的用户体验。当开发代码的团队同时也负责决定其质量是否符合发布标准的时候，那么发布不完善代码的风险就会大大提高。拥有完整的生命周期使得人们自满，并会滋生“我们总是可以在生产环境中修改它”的错误想法。
作为公司所有者，我更喜欢对系统进行检查和平衡，从而我们可以更好地服务客户，并因此得到他们的回报：
- 我不希望开发团队负责QA（质量保证）工作，而是由QA团队来负责代码的质量。
- 我不希望QA团队来发布程序并运维生产环境中的应用程序，应该由运维团队来负责彻底地测试应用程序，从而问题可以在早期发现，在它被客户使用之间就被退回给开发团队修改。
- 我不希望运维团队承担限制我们向客户发布新功能的频率的角色，他们应该负责应用程序的可用性和性能，并负责发布和维护代码，还要反馈缺陷和不足，不论是在检查还是测试过程中发现的。
实质上，我希望质量是大家分享的责任，各个团队对于非常特定的区域和责任相互负责。我希望团队之间的关系是一种积极的矛盾，从而为持续的质量改进提供动力，并且在头脑中将客户作为唯一的目标。
3）机会的浪费：如果软件开发团队忙于运维工作，那么谁会开发新的特性并改善应用程序呢？谁来修复软件的缺陷呢？开发者会和生产团队会仅仅因为一个页面跳出来，警告他们Amazon EC2的一个实例出错，而被滞留在下一代软件的设计过程中吗？
Bjorn Freeman-Benson: 其次，当应用程序被部署在云中时，运维的真正任务是什么呢？越来越多的网络应用程序被部署在公有或者私有的云架构中。在New Relic公司中，超过40%的客户将应用程序部署在云中，并且我们期望这个比例在2010年末会很大。就算大部分公司都比较小，没有大公司需要处理的遗留数据中心或者数据整合的麻烦。但是，每天我们还是会与新的客户签约，他们可能是带有传统数据中心的大型组织，而客户的应用程序被部署在Amazon或者其它公有云中。
那么，在这些情况下，运维团队应该扮演什么样的角色呢？他们不会负责云的硬件、网络、电话。他们不会对架构监控做出选择。在云中唯一属于他们公司的就是应用程序的代码本身。其它所有的一切都是由云架构提供商负责的。因此，坦率地说，当我的应用程序被部署在云中，谁会需要运维团队呢？开发团队必须负责基于云的应用程序能够成功执行。除了他们，谁也做不到这一点。
Carlos Armas: 很有趣的是，看起来似乎人们期望云中的系统能够自我管理，那是错误的认识。让我们退回几年来说明这个问题，并讨论一下托管服务。
我们当前所知的托管服务是从托管提供商意识到他们可能会为客户提供硬件和带宽之外的服务开始的，并且在他们的服务组合中包含了系统管理和对应用程序的管理。结果显示那是很棘手的业务，很难保证交付时的一致性和良好的质量。只有少数提供商做到了这点，但是付出了很大的代价。
从上面的观点中，云计算将系统管理和应用程序管理任务推回给了客户。（我们不想在此定义云计算，那肯定会导致另一个讨论:)）
那么运维团队在云中应该做什么呢？首先是系统管理。然后是应用程序的部署、监控、发布扩展和响应。我们仍然需要24x7的电话支持，因为系统位于云中。系统管理（针对Unix、Linux、Windows等等）是开发者无法做好的事情，因为他们并非是该领域中的专家，就像系统管理员不是好的软件开发者或者好的市场人员和沟通执行者一样。
然而，随着（并且如果）云计算变得越来越普遍，运维团队的组成也逐渐产生了变化。你之前提到了硬件、电信和网络。显然对这些能力的需求会从云客户的公司转移到云提供商。客户还是要保留系统管理员角色，并且会和之前一样需要（甚至更加重要），因为提供商不再为你管理虚拟服务器的操作系统。（记住，作为公司所有者，我想要软件工程师开发代码，Scrum教练防止他们做隐藏的工作，同时还要排除他们工作进程中的障碍）
我们还可以认为，在这样的场景下，运维团队不再存在，而运维工程师变成了软件开发团队或者其它团队的一部分。那是有可能的，事实上当前在小型团队中正是这样。然而，我不认为我们在这里是在关注组织结构图，而应该关注在合并的托管技术环境中运维和开发的角色。
本质上，我的观点是，软件开发团队不应该负责运维任务，并非是因为他们不能，而是因为那在财务上、组织上和商业智慧上是不合理的。
此外，当提到云的时候，你说：“看起来似乎人们期望云中的系统能够自我管理，那是错误的。”是的，很明显云架构不会自我管理。但是我们所说的是与云相关的系统管理工作是由云提供商完成的。因此我说如果我们在将应用程序部署在云中的公司中做IT工作，为什么还需要系统管理员呢？我们应该让开发者来做大部分应用程序管理工作，这样就不需要再建立云团队了。如果一个公司使用的是云平台——RightScale、Heroku、Stax、Gigaspaces、EngineYard等等——中的一种，那么大部分的与系统管理相关的工作都是由平台自动完成，而不是由系统管理员人工完成的。
让我给出另一个观点，来说明为什么开发者应该对生产环境中的应用程序负责。谁能够比编写代码的团队更好地找到性能问题的根本原因呢？假设运维团队得到了应用程序的性能出现了问题的警告，可能来自于性能检测工具，或者来自于不可避免的业务人员的电话，他们在其中大发雷霆。典型的运维人员能做什么呢？如果他们极度幸运，那么可能会将产生问题的原因隔离到一些出现问题的架构中。坦率说那种情况十分少见。通常运维人员所使用的各种架构监控工具会显示一切“绿灯”。往往问题都在于应用程序之中。谁能比开发团队更知道在虚拟机中发生了什么呢？大多数运维人员都不是开发者，他们不会读代码，也不能跟踪原因隐藏在程序中的问题。为什么需要运维团队作为中间人来接受警告，然后他只是将问题转交给开发团队？还是让开发人员来接受警告并更快地着手解决问题吧！如果问题在于他们的代码之中，那么他们就应该是修改该问题的不二人选。这样做额外的作用就是让开发者对于他们发布到生产环境中的代码更尽心，因为知道他们需要对结果负责。
以下内容增加于4月19日
Carlos Armas:
是的，我当时是在开玩笑，:)
我发现使用幽默更便于沟通和理解。我越是阅读你的评论，越是觉得似乎我们的观点并非是像旁观者乍一看所感觉的那样针锋相对。
我同意开发者能够学习并执行很多运维任务，这是肯定的。但是请记住，我还是希望他们能够专注于代码，将该项工作放在第一位，正如我坐在公司所有者的位置而谋其事一样。我在下面陈述你所作出的非常重要的观点时，会再回头来看这个观点。
在此有一个很不固定，并且正在发展的概念：云计算。如果你让我给它下定义，我可能会逃之夭夭。（我可不想作为现代云计算的布道者来吸引眼球）
可以说云计算是个宽泛的概念，它关注的是需要最少或者可能根本不需要运维专业支持的服务(Heroku，以及其它等等）。它还涉及到像Amazon的EC2、Rackspace的RackspaceCloud、Opsource's的OpsourceCloud等服务，其中涉及到大量运维工作，这依赖于所要支持的应用程序的种类。
所以这件事的问题在于，“具体情况具体分析”。
我对你的观点的根本原因进行了分析，在提出我的反对观点之前，让我先强调一下你的一些我观点：
- 这样做额外的作用是，当开发者将代码发布生产的时候会更尽心，因为他们知道需要对后果负责。
- 为什么要让运维团队作为中间人来得到警告，然后不管怎样，只是将问题转交给开发团队？
如我所见，如果开发者开始做运维的工作，那么：
- 开发者会更尽心，因为他们需要对将代码发布生产所带来的后果负责。
- 这会解决中间人综合症（运维人员）所导致的问题，他们无法修正导致失败的错误
基于实战的经验，我要对上面的观点表示反对：
- 为什么是那样呢，在很多公司中（显然数量巨大）运维人员被认为（表现为）是妨碍改变的因素，并且向工作流程中添加延迟，以致于几乎不可能保持敏捷并向生产环境发布代码。
- 为什么运维团队始终是开发团队的阻碍呢？
- 为什么开发团队要应付严格的公司政策，最终购买云计算服务呢（因为运维团队无法在第一时间提供服务）？
- 为什么运维团队会因为漏掉了SLA目标而受到惩罚？前提是错误不是与有缺陷的架构或者过程相关，而是与错误的代码相关的。
- 为什么运维人员无法从云服务的快速、灵活的部署能力中获益呢？难道是70年代的计算实践中的“守护者”精神依然存在吗？
对我来说有些事情已经很清楚了：冲突是切实存在的，但是如果不熟悉信息技术实践的历史，那么就很难梳理出为什么我们因此而受苦的原因。我有一条未经测试并且非常单纯的理论：变更对于运维是有害的，而软件开发就是变更。因此存在最重要的矛盾，这需要聪明地处理。
新从公司所有者的角度来阐述，因为我要花费资金来试图提供管理冲突的过程（是聪明的吗？）。我要使用敏捷的用户故事方式来说明，作为公司所有者，我想要：
- 软件工程师不负责公司的财务工作（你没看到他们过来吧？:)）
- 运维工程师主要专注于24/7服务的可用性。
- 软件工程师主要专注于服务的改善。
- 在开发和运维之间存在“零壁”规则。
- 运维工程师是敏捷团队的核心成员。
- 软件工程师经常会在第三级扩展的待命任务中轮换
- 这很痛苦，但会有教训
- 开发和运维团队都会对应用程序的可用性和延迟负责
- 在此我想坦率地说：丢失的目标，对于任何团队都无益，我不关心谁打破了它。必然的结果是：财务上的问题，会有教训。
- 运维工程师需要学习服务应用程序层的核心、本质的部分。
- 现在他们已经可以为设置趋势监控提供帮助，并且能够预测构建场景中的错误。
本质上，我还是想让我的软件开发团队编写代码，构建新的特性来吸引客户的眼球，而不能被其它任何事情来分散精力（包括云计算）。我还是想让运维团队（或者是拥有多名工程师的团队，或者是兼职的远程系统管理员）来调整系统，并能够对构建客户想要的东西的团队做出最快地响应。我还想让运维团队学习应用程序层的关键知识，那样他们就能够不定期地找到针对架构的缺陷（作为唇齿相依的关系，不再对变更抱怨）。
以下内容增加于4月20日
Bjorn Freeman-Benson: Carlos，多谢你明确了立场。简要地说，我同意大多数你关于开发者如何认识运维人员的说法（变更阻碍者），并且我想要增加对运维人员如何对开发者的认识（一群疯狂的牛仔）。我看到，关于我们的讨论，有很多读者发表了有意思的评论。我已经在线下得到了一些关于影响的反馈（感谢@markimbriaco和@randybias），我的立场很明确，强烈地反对运维功能。我并非故意如此，并且希望我没有将运维人员描述为完全不必要或者没有能力。我并不认为没有公司需要运维功能，很显然并非如此。
我的立场和观点都集中于应用程序，以及对它们负责的人。毕竟，如果不是为了应用程序的开发和运维，IT还有存在的价值吗？
让我用这次发布的内容来澄清我的观点，并对Carlos上面的一些评论做出回应。
首先，我所听到和读到的来自于运维人员的讨论（其中很不错的一条评论就在本文下面，由John Willis发表）告诉我们，没有人知道，运维的角色已经产生了很大的转变，这比运维人员本身还要大。Carlos，你的评论也显示出这一点。他们能够认识到，数据中心和应用程序比起几年前已经有了很大的改变。数据中心过去会是各种技术的大杂烩——一台大型机、一些AS-400机器、一些RS-6000机器、一些DEC的小型机以及一些“那些web家伙”使用的Wintel服务器，再加上一大堆存储设备，他们需要不时地对其进行维护和反馈。现在仍然还有这样的数据中心，对于支持它们的运维团队，我想可能没有什么变化。然而，现在数据中心里面拥有1000台Linux/Tomcat的刀片服务器已经不是什么稀奇的事儿了，所有这些刀片服务器都彼此相同。另外，几乎所有应用程序都基于Web技术（Java, .Net, Ruby, PHP）也不是什么稀奇的事儿，并且在那些数据中心中没有什么需要学习的管理工具，也没有需要支持的专利系统。云计算将这种现象发展到了极致。因此在越来越多的情况下，运维团队的角色由于标准化和便利性而越来越简化。我们的观点是，我描绘的情况正在成为标准而不是不常见的情况。
即便是在高度标准化的数据中心（我的有1000台刀片服务器的例子中）情况下，仍然还有运维的任务。有大量需要专业知识的工作——数据库管理、容量规划、数据备份和恢复、灾难恢复规划、电力管理、通信管理等等。执行这些任务的人是为整个数据中心在服务（或者是为雇用他们的云提供商）。
我的观点的关键在于，对应用程序的管理职责应该主要归属于应用程序开发团队，而不是运维团队。另外，Carlos（这可能会让你感到惊奇），我完全同意你下面的观点：
我有一条未经测试并且非常单纯的理论：变更对于运维是有害的，而软件开发就是变更。因此存在最重要的矛盾，这需要聪明地处理。
我的观点是，开发者和架构师能够比运维团队更好地为部署、监控、以及突发事件管理决策做准备，因为他们拥有与应用程序架构和语言最紧密相关的知识。在应用程序管理的情况下，运维和开发团队之间职责的划分没有那么有效。谁应该为应用程序的成功对公司负责也不是很清楚。最终，通过把应用程序的进展管理直接放到开发人员的工作描述中，应用程序的质量会得到改善。我们不再允许开发者向运维团队发布代码质量低的应用程序，然后对后来的烂摊子放手不管。
我喜欢你针对“公司所有者想要的是什么”的敏捷故事方法，但是在对其作出评论之前，我想听听来自于读者的评论。
以下内容增加于4月21日
Carlos Armas: 尽管我非常愿意相信运维团队的任务正在变得简单（这也是我所期望的），但实际的情况却恰恰相反。
据我所知，在过去的15年间，人们误解了运维任务，并逐渐将其最小化了。不必感到奇怪，因为这很大程度上都是运维团队的错。
这开始于大型机时代，当时MIS（信息系统经理）担任的还是“计算教堂中的神父”的职责。在“机器时代”，玻璃墙后的评判者使用仪式、保密和分离的原则进行运维工作。这对于监视很有好处，也有利于在公司竞争范围中对挑战进行控制。
那样的时光已经一去不复还了。正如我所见，工作中最简单的部分已经逐渐地消失了。我们不再通过分离/bin和/usr/bin目录来对硬盘进行加速和减速，或者使用12GB内存的Sun E4500，让它占据数据中心最重要的位置。我忘记了是什么时候我最后一次使用剥皮钳来做电缆（谢天谢地！）。我也不再记得曾经是什么时候不得不编译一些程序，因为apt或者yum会给我稍微旧一些的、无法处理的版本。
我认为运维的物理任务很早以前就从我们的工作描述中消失了，而被放到初始化/支持任务中。另一方面，我们的工作变得越来越复杂。多服务器的同构数据中心（甚至是虚拟的、“云”的）带来了不同的、更高级别的让人头疼的工作和复杂度。随着kickstart，puppet，以及其它相关的自动部署机制一起，所谓的“原子任务”也随之而来了。在单一服务器中的简单拼写错误/etc/sudoers很容易修正——但现在在我们的系统中存在自动的乘法/加速效应，那会让错误在几秒到几分钟内扩展到成千上万台服务器中。
每天我们面临的挑战也发生了变化，从“为什么编译失败？”变为“怎样我才能骗过傀儡模块，它将应用程序Y部署到120台服务器上来安装发布X，但是在完成之前无法发布X+1，所以最终我没有在生产实例中发布alpha测试质量的代码”。我很喜欢现在的情况，因为“现实世界中的约束”不会成为云提供商的环境中的障碍。协商、斡旋、统筹、分离和配置工作都应该提前做好。那就是过程。这个趋势为云计算铺平了道路，并且肯定会很受欢迎。而我的工作肯定不会变得更简单，尽管我使用自动化的方式来帮助我更好地铺平了道路。
我们可以这样认为：它变得更加复杂，但现在我拥有更好的能为我们提供帮助的工具。并且，作为通向下一个目的的途径，我非常感谢创建这样的自动化工具的开发者们，那也是我想要它们一直为新的想法做开发，而不是管理部署后的应用程序的原因所在。
我同意你关于开发人员和架构师的观点，他们正在准备更好地做出部署/监控/突发事件的管理决定。毫无疑问，在我的意识中，开发者和架构师比任何人都更了解它们所创建的应用程序。
对于谁应该为公司对应用程序的成功负责这个问题，我仍然持这样的观点（可能是过时的），应用程序是服务生态圈中的一部分，没有支持它的架构基础就无法生存——即便是在云环境中，架构也需要管理，我更希望在该领域非常专业的人来执行那些任务。我想可能是看问题的角度的问题，我们更可能在此通过同意的方式来表达反对。
现在，让我们回顾一下开发者在他们的工作描述中增加对应用程序在生产环境中的管理的责任，正如你所提到的：我喜欢！非常喜欢。“放轻松一些，年轻人”。将你的开发者轮换到运维团队的岗位，从而他们能够得到交付一致的、24/7 SLA支持的用户体验相关的需求和挑战的第一手经验，同时给他们灌输应用程序级别的知识。这和新雇佣的开发者一样的。作为对等（反击），我会将我的运维工程师轮换为你的SCRUM团队，并且体验第一手的“排除障碍”的工作，由于延迟和红色条所带来的挫折等等。这对于消除团队之间的（人为的）壁垒非常有益，那样就不会再有“我们 vs 他们”。
上述的内容会确保我让开发者做的是我需要他们做的（作为公司所有者）：创建新的功能，同时有助于传递知识，从而能够在生产环境中更有效地支持应用程序。
以下内容增加于4月27日
Bjorn Freeman-Benson: 这是非常有趣的一周。很抱歉我已经有好几天没有发表内容了。我在我们的SaaS工具上部署了很棒的新特性，并且开始了下一轮的开发。现在我们在应用程序性能监视工具中包含了对生产环境的概要分析。我们至少每周都会推出一些新特性，并在一周之内做几次ad-hoc的补丁。这让我们一直都很忙。我还要说，在New Relic，我们仍然拥有非常棒的系统管理员，他叫Bayar Carlin。我知道，通过我的评论，你可能会认为我们没有任何运维人员。但是，我们确实有一名。他也是应对我们的员工的需求的内部IT部门。在以后的内容中我会更多地谈到Bayard。
在查看来自于读者的一些评论的过程中，我看到了很多非常好的评论，想在这里强调并做出回应。在下次发布的内容中，我会总结从所有这些反馈和Carlos的观点中所学到的东西。
首先，David Sims评论道：“让我们的开发者深入参与到技术支持中真的很好，因为这让他们产出了更好的产品。然而，正如Carlos所指出的，作为小公司的所有者，我知道让开发者来回答问题并非是对资源最有效的利用，有技能的支持工程师同样可以处理。”我对两位的意见都表示同意。我已经看到让开发者参与到生产环境的会让产品质量得到稳步地改善。我们也同意David的意见，他说对于开发团队，当还有新的代码要写的时候，花费时间做运维的工作是一种挑战。然而，如果David的意思是运维工作并不具备足够高的价值，那么我就要表示反对。我不会为运维团队所做的工作分配比开发团队做的工作少的价值，只是之间有所不同。
其次，Geva Perry关于云计算造成的影响以及对运维的角色的影响的分析的思考非常有价值，可能某天我们会在新的文章中对其进行扩展。在New Relic中的一些应用程序位于云中，而另一些位于传统的托管环境中。然而，我们有大量的客户，部署在各种各样的云环境中，我们听到其中的某些客户谈到，他们在新的部署环境中遇到了很多新的、不同的需求。
第三，我对John Allspaw的评论同时持同意和反对的意见。我不同意他所说的（云中的）自动化不会明显减少运维人员的数量。我认为这是不可避免的趋势。我同意在大多数大型的公司中，仍然还会与运维团队，并且我们可以用他们学会协作的程度，而不是抹杀他人的成绩的程度来衡量成功。
第四，我喜欢Sellers Smith的意见，“健康的运维环境的标志”。我认为他处于正确的轨道上。我还是喜欢将应用程序和服务等级中更多的责任成功地迁移给开发者，从而在开发人员和运维人员之间没有过多的传递，而有更多在思想来创建应用程序和应用程序平台。想一下在工业工程和客户产品中的对可维护性的设计的运动，你就会明白我所想要表达的意思。
下次发布时我会总结我所学到的，并继续征求你们的意见。
以下是最近与本次讨论相关的Twitter评论，你可以在此查看：
searching twitter...
上面的Twitter工具是免费的、开源的、基于Javascript的库，你可以在此找到：http://tweet.seaofclouds.com.
查看英文原文：Debate: What is the Role of an Operations Team in Software Development Today? [Updated Apr 27th]