没有 DevOps 团队

观看完本文后，你将能够定义 DevOps，识别对 DevOps 的误解，并了解团队使用 DevOps 的最佳方法。
“DevOps” 这个术语经常被误解。例如，这是我最近在注册一场网络研讨会时看到的一个下拉列表。它询问我的工作职责，并提供了 “DevOps / 技术运维” 或 “软件开发人员 / 工程师” 这些选项。我是一名践行 DevOps 的软件工程师。这些职位名称并没有体现出 DevOps 的真正含义，坦率地说，这个组织应该更清楚这一点。显然，他们没有注意到 DevOps 中的 “D - E - V” 这几个字母，它们代表 “开发（development）”。这里有个提示，如果你不进行开发工作，那么你就不是在践行 DevOps，而只是在做运维工作。显然他们并不明白这一点。
在软件开发中，开发（Dev）和运维（Ops）这两方面都存在。对他们来说，DevOps / 技术运维是运维人员做的事情。但 DevOps 并非仅仅是运维人员的工作。
对于 DevOps 有不同的理解视角。一开始是传统的开发和运维模式，两者之间存在着沟通壁垒。许多组织，就像我例子中的这个网络研讨会组织，认为 DevOps 是运维人员做的事情，并且认为 DevOps 是运维的一个子集。有些组织认为 DevOps 是开发人员做的事情。但大多数组织认为 DevOps 是一个独立于开发和运维之间的团队，其作用是让开发和运维双方都满意。我稍后会详细讲讲这一点。
但这些观点都不正确。DevOps 是整个组织都应秉持的一种理念。在初创企业中，你会经常看到这种情况。DevOps 是他们的企业文化。它意味着开发和运维以相同的理念协同工作，最好是在同一个团队中，有着相同的目标和衡量标准。
杰兹・汉布尔（Jez Humble）写道：“DevOps 运动旨在解决由职能部门壁垒造成的机能障碍。因此，在开发和运维之间再创建一个职能部门显然是一种糟糕（且具有讽刺意味）的解决问题的方式。”
记住，并不存在所谓的 DevOps 团队。这是一种反模式，它带来的问题比解决的问题更多。你看，DevOps 理念的核心就在于认识到部门壁垒式的工作方式行不通。
你可能见过安德鲁・克莱・谢弗（Andrew Clay Shafer）所创作并使之广为人知的 “沟通壁垒” 示意图。它描绘了开发和运维截然相反的目标。开发工作的衡量标准是他们能向生产环境推送多少新功能。而运维工作的衡量标准则是生产环境的稳定性。一种稳定生产环境的方法就是不做任何改变，比如不添加新功能。
如果你创建一个独立的 DevOps 团队，那你只是又制造了一个新的部门壁垒，进一步将开发和运维分隔开来。从这个角度看，这毫无意义。你不会为了实现 DevOps 就去创建一个团队，就如同你不会为了实现敏捷开发而专门创建一个团队一样。没有人会组建一个敏捷团队，然后宣称因为有了这个团队，他们的组织就突然变得敏捷了。不是这样的，组织必须接受敏捷理念，才能变得敏捷。DevOps 也是同样的道理。
实际上，DevOps 不是一个职位名称。它不是某一个人或者某一个团队的工作。它是一种组织层面的文化变革。它是开发工程师和运维工程师在整个软件开发生命周期中协同工作的实践，最好是在同一个团队中，遵循精益和敏捷原则，从而能够稳定且持续地交付高质量的软件。它始于学习以不同的方式开展工作，并接纳跨职能团队，将开放、透明和信任作为基本原则。
如果这听起来与你的组织情况不符，那么你很可能并没有在践行 DevOps。
在本文中，你了解到 DevOps 是整个组织都应秉持的一种理念。DevOps 解决了部门壁垒式团队所带来的问题。DevOps 是开发工程师和运维工程师在整个软件开发生命周期中协同工作的实践，遵循精益和敏捷原则，从而能够交付高质量的成果。