作者｜ Helen Beal
编辑｜ 盖磊
根据一份报告指出，尽管组建 DevOps 团队的比例正在上升，但是在企业中是否应该存在 DevOps 团队这一问题上依然存在着分歧。有些人担心会创造更多的“孤岛”（Silos），或是认为 DevOps 是组织中的每个人都应掌握的方法。另有观点认为，DevOps 团队是一种转变为新工作方式的有效途径。
这份报告是今年六月发布的第六次年度“DevOps 状态报告”（State of DevOps Report），报告是根据采集自 27000 份调研反馈中的实验数据而得出的。在报告中指出：
随着 DevOps 的演进和扩散，我们注意到，任职于 DevOps 团队的员工比例呈逐年递增。在 2014 年，在反馈结果的被调查者中有 16% 的人工作于 DevOps 团队。而三年后，这一数字达到了 27%。
“DevOps 状态报告”并未对 DevOps 给出一个明确的定义，但是 Matthew Skelton 和 Manuel Pais 在 devopstopologies.com 上对此话题做了深入的探讨。据现有的观察情况，可使 DevOps 工作的团队拓扑结构包括：
1 . 开发（Dev）与运维（Ops）间的协作，这是 DevOps 的“应许之地”（译者注：“Promised Land”一词源于圣经，指上帝赐给亚伯拉罕及其族人的土地）。
2 . 运维职责的完全分担。
3 . 将运维作为 IaaS。
4 . 将 DevOps 作为一种外部服务。
5 . 具有过期失效机制的 DevOps 团队。
6 .DevOps 狂热者团队。
7 .SRE 团队（Google 的模式）。
8 . 由容器驱动的协作。
9 . 运维和 DBA 间的协作。
但是在 finkit 工程总管 Anouska Streets 近期撰写的一篇文章中，提出不鼓励创立 DevOps 团队：
专门设立一个团队执行 DevOps，或是采纳了相关的工具，这并不意味着我们正在做一件正确的事情。自 CEO 以下的每名员工，都需要真正地参与到 DevOps 工作中。
“DevOps 并非某个人的工作，而是每位员工的工作”。这一理念在业界逐渐得到了广泛的认同，并与 DevOps 是否或应该体现在职位头衔上这一问题紧密关联。正如 Threat Stack 运维和支持总监 Pete Cheslock 在“DevOps 头衔毫无裨益”（DevOps in Your Job Title Is Doing You Harm）一文中所说：
事实上，DevOps 是一种文化，应该被企业中的方方面面所采纳。每个员工都需要拥抱 DevOps 文化所带来的变革，而非专属于某个人。
但是，有人依然认为 DevOps（特别是 DevOps 工程师）应适得其所。SpikeLab 的创始人 Spike Morelli 是一位 Google 的前员工，并曾任斯坦福大学技术创业 MOOC（Technology Entrepreneurship MOOC）的助教。在他看来：
DevOps 并非一种职位头衔，但是 DevOps 工程师是。其中 DevOps 用作限定词。
JumpCloud Inc 的 CEO Rajat Bhargava 对此持不同意见。他对此职位提出了多个观点：
DevOps 是一种方法，而非一种职位头衔。我们并不会将开发人员称为敏捷工程师，他们依然是开发人员，只是遵循了敏捷的方法。因此他们的职位并非是去实现敏捷，而是去创建很好的产品。
DevOps 应该***到组织中，而设立一个 DevOps 小组在某种程度上会丧失 DevOps 的意义。DevOps 应该嵌入到一个企业的架构之中，而不是作为一种开发过程中的辅助工具。如果 DevOps 没有嵌入企业中，我们如何能实践 DevOps？
因此，在 DevOps 市场中存在着矛盾。事实上越来越多的组织开始支持 DevOps 团队，与之形成鲜明对比的是一些观点认为 DevOps 团队是一件坏事。“DevOps 状态报告”的撰写人对 DevOps 的增长给出了如下的观察：
我们认为，这种增长不仅表明了人们对 DevOps 工作的认可，而且事实上 DevOps 团队代表了将整个企业从旧有的工作方式转换为新的 DevOps 过程的一种战略。
这种对 DevOps 团队的不利反应并非新近才有。“DevOps 状态报告”的撰写人之一 Jez Humble，他也是《持续交付》（Continuous Delivery）、《精益企业》（Lean Enterprise）和《DevOps 手册》（The DevOps Handbook）等书的作者，曾在 2012 年宣称“并不存在所谓的 DevOps 团队”：
……DevOps 运动意在解决由功能“孤岛”组成的组织会导致运作不畅的问题。在尝试并解决这些问题时，很明显创建另一个位于开发和运维之间的功能“孤岛”是一种不好的（令人啼笑皆非的）问题解决方式。DevOps 建议了一些替代策略，用于创建更好的功能“孤岛”间协作，或者是完全地消除功能“孤岛”并创建跨职能的团队，或者是以某种方式组合这些方法。
InfoQ 与 Humble 做了核实。时至 2017 年，他依然秉持此观点。Humble 强烈赞同 Streets 提出的观点。但是他相信现在是时候去探讨 DevOps 团队的问题：
要让开发人员对他们所创建的系统负起责任，需要开发人员可以得到来自于运维的支持，以了解如何构建可持续部署到那些横向扩展的不可靠平台上的可靠软件。他们需要自身服务于环境和部署，理解如何编写可测试并可维护的代码，并需要知道如何打包软件、实现部署中和部署后的支持工作。在此过程中，需要有人为开发人员提供支持。如果有人想将做这样事情的人称为“DevOps 团队”，那么我也不反对。
Puppet 产品营销总监 Alanna brown 的观点是：
一个专职的 DevOps 团队，通常是由一些有经验的运维人员组成，这些运维人员掌握多种技能，包括使用版本控制、编写作为架构的代码以及作持续交付。DevOps 团队通常从解决最令人痛苦的事情着手，例如自动化部署等。如果他们取得了成功，那么可以做进一步的发展，并为企业中的其它部门提供共享的服务。
尽管在报告中普遍认为 DevOps 团队是一种反模式，但是报告也指出，DevOps 团队和 IT 企业性能间存在着正向关联：
在 2014 年的《DevOps 状态报告》中给出了一个惊喜，那就是 16% 的被调查者认为自己是专职于在 DevOps 部门的。这些 DevOps 团队成员中有 90% 的人任职于那些高绩效或中等绩效的 IT 企业中。
Pivotal 的 Michael Coté在敏捷和 DevOps 团队的角色和职责上具有丰富的经验（这里需要澄清一点，Coté的观点是“DevOps 中包括了敏捷”）：
通常我们能看到两种类型的团队：一种是“业务能力团队”，工作针对那些出现问题的实际软件或服务上（即“应用”）；另一种是“敏捷运维团队”……
这里，Coté并未介绍敏捷运维团队所做的工作，但是在他看来，这是围绕这生产 PAAS 的平台工程、站点可靠性和架构的工作。
无论业界是否认同 DevOps 团队是推进企业整体 DevOps 能力的正确方法，现实中 DevOps 团队与日俱增。读者们是否认为 DevOps 团队的趋势将会继续？更重要问题的是，读者们是否认为 DevOps 团队应该继续发展下去？
查看英文原文：The Industry Just Can't Decide about DevOps Teams
