业界当前对DevOps团队尚无定论

DevOps

摘要： 今年六月发布的第六次年度“DevOps状态报告”（State of DevOps Report）指出，尽管组建DevOps团队的比例正在上升，但是在企业中是否应该存在DevOps团队这一问题上依然存在着分歧。有些人担心会创造更多的孤岛（Silos），或是认为DevOps是组织中的每个人都应掌握的方法。另有观点认为，DevOps团队是一种转变为新工作方式的有效途径。

作者： 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