讨论：当前运维团队在软件开发中的角色

在过去的几年中，随着云计算和开发加运维现象的出现，出现了对传统的运维团队的角色的讨论，因为在当前的软件开发团队中经常会看到他们的身影。InfoQ将会深入地探究此次讨论，以更好地理解其中所涉及到的各个不同的方面，以及各种方法之间的平衡。

本次讨论的核心是这样的重大问题：

谁应该负责对生产环境中的应用程序进行管理、监控和运维？

在开始关于此次争论的讨论之前，我们先是邀请了New Relic公司（基于SaaS的应用程序性能管理工具的提供商）的工程主管Bjorn Freeman-Benson和InfoQ运维社区的首席编辑Carlos Armas。然而，这只是讨论的开始，随着讨论的进行和展开，InfoQ会将最近的讨论更新到本文中，并且还可以通过关注#roleofops标签来关注Twitter上的讨论。我们希望你也参加到本次讨论中，所以请选择发布带有#roldofops标签的推特信息，或者向feedback@infoq.com发送邮件来说明你的看法，也可以在本文的评论中留下你的声音。 

---

Bjorn Freeman-Benson: 关于改变运维的角色这个主题，已经有了大量的言论、网志以及幻灯片。在大量的交流中，人们提出了将开发和运维变得更加紧密的要求。他们称之为开发加运维或者其它术语。尽管我在New Relic公司的同事和我在总体上都持赞同的意见，但是我们认为公司应该考虑采用更具有决定性的步骤，以达到更有效的运维管理——也就是，考虑让每个开发团队都负责他们自己的应用程序的部署和性能问题。 

让我们考虑一下，为什么这并非像它听起来那样不同寻常或者极端。

首先，对于应用程序，谁能比创建它的团队更了解它呢？这使得在将应用程序部署到数据中心或者云中的时候，应用程序开发团队需要与业务应用的所有者商讨，然后对应用程序进行设计、架构和编码，选择、测试并集成应用程序的各个组件（应用程序服务器、操作系统、数据库、集成中间件等等），创建原型，执行功能测试，可能还要进行负载和可扩展性的测试，向业务人员演示应用程序的功能，最终为生产环境准备就绪。几周甚至几个月来日积月累的知识怎么可能一下子就传授给运维团队呢？

开发团队应该做出重要的部署选择吗？——增加或者扩展硬件服务器，是否对服务器采用虚拟化，哪种CPU和内存是最佳的等等。开发团队应该决定他们所需要的最佳的性能监控和日志记录吗？开发团队应该监控、处理警告、把握性能和有效的时间，并且在应用程序崩溃的时候处理来自于业务部门歇斯底里的电话吗？（为什么运维人员会处理这些有趣的事儿？）我知道这种方法会有用的——在New Relic公司中，我们自己就使用它来管理世界上的最忙碌的SaaS应用程序之一。很讽刺的是，我们的SaaS应用程序耗费了将近4000个开发团队来管理他们的生产环境中的应用程序。

Carlos Armas: 这样的想法很具有吸引力，因为设计和构建系统的团队最适合对其进行运维、监控和扩展。由这个逻辑递推，我主张开发团队应该负责处理公司的账务，因为软件开发者都很擅长处理数字，或者由于他们对环境很关心，因此应该在工作之后清理办公室并将垃圾箱倒到外边的回收处。这样做就忽略了几百年来的重要实践：分工。事实上，开发团队比其他人更加了解应用程序，但这并不能成为要他们负责对发布到生产之后的代码进行运维和维护的原因。

我假定自己是公司所有者的角色，并给出三个原因，说明为什么我不想这样的事情发生在我的公司中：

1）财务上的：软件开发者的平均工资总是要比运维支持工程师的高。作为公司的所有者，为什么我想要让我最昂贵的团队做运维任务呢，那种任务可以由其它团队完成，那样更节省资金，更有效。在任何敏捷团队中，任何好的Scrum教练都会告诉我们，他们的主要任务之一就是移除障碍，并让隐藏的工作可见，从而开发团队能够更有效地开发代码。为什么我想要将更多的障碍和额外的工作强加给开发团队，从而降低他们的效率呢？

2）质量：我相信检查和平衡，因为没有人是完美的。当团队负责应用程序完整的生命周期时，客户最终要吞下这个苦果：很差的用户体验。当开发代码的团队同时也负责决定其质量是否符合发布标准的时候，那么发布不完善代码的风险就会大大提高。拥有完整的生命周期使得人们自满，并会滋生“我们总是可以在生产环境中修改它”的错误想法。

作为公司所有者，我更喜欢对系统进行检查和平衡，从而我们可以更好地服务客户，并因此得到他们的回报：

• 我不希望开发团队负责QA（质量保证）工作，而是由QA团队来负责代码的质量。
• 我不希望QA团队来发布程序并运维生产环境中的应用程序，应该由运维团队来负责彻底地测试应用程序，从而问题可以在