这些DevOps误解，你中招了吗？

大家或多或少已经对DevOps有一定了解了，今天我们一起来审视一下关于DevOps常见的误解。这有助于对DevOps这个现象建立清晰的边界，并使得我们可以继续推进更多的具体工作。

DevOps是敏捷的一部分

现代软件开发的拥趸有时候声称, DevOps无非就是敏捷那些想法的延续——这是一种受限的世界观，其核心基于一个事实，即敏捷开发能够与客户建立更好的关系以理解其软件产品需求，并足够快速地发布软件产品。

“做些什么才能够让发布的产品对客户有用以及具体如何实施”是一个长期存在的问题，现在有了进一步的解决方案:DevOps！针对这个令人尴尬的问题，有人从 DevOps中找到了答案。

举例来说，我们看看流行的SAFe(规模化敏捷框架)模型，这个模型的设计目标是帮助敏捷开发在中型到大规模的组织中落地。

我们研究的DevOps出现在SAFe模型的右部、接近中间的位置，位列在Program层级中。从字体判断, DevOps的重要性大致相当于Backlog、Kanban与 Business Owner。SAFe中具体描述如下图所示。

SAFe企业实施DevOps以打破职能筒仓，赋能各列版本发布火车(ART)及解决方案火车，以持续地向最终用户交付新的特性。随着时间的推移，开发与运维之间的割裂程度会显著降低…目标很简单：更频繁地交付价值。

这是一个非常受限的对DevOps的看法，至少有三个理由。

• 首先，尽管在很大程度上基于敏捷，DevOps把“敏捷开发”的想法延展到了整体的敏捷IT交付、整个组织、整个流程以及整个价值链
• 其次，相对于敏捷而言，从 DevOps中获得回 ，通常需要更大的公司文化变革。
• 第三， DevOps的目标集，并不仅限于加速交付——还包括减少技术债务和消除脆弱性

DevOps是工具和自动化

另一个观点与自动化这个词有关。对现代IT部门有帮助的软件工具的数量，近年来翻了几番，常用的工具都有几百种。很多供应商都试图让你确信它们“就是”DevOps，或者它们将提供给你最好的DevOps工具。

供应商的市场压力非常之大。像CA、HP和微软这样的大公司，已经开始带着它们高大上的营收目标和相应的营销预算投身其中。

很多人注意到一个似曾相识的场景，即20年前管理IT服务的软件的历史：那时的软件供应商也说，ISM就是一套软件，而你所需要做的所有事情，就是安装它，然后让流程自行发生。仅有少数供应商意识到并且认真讨论软件以外的一些东西。

DevOps确实依赖于某种自动化工具的可用性与有效性。但严格来说，这些工具的最小集，可以缩小到一个用来存储所有源代码和IT基础设施配置数据的版本控制系统及一个软件交付流水线自动化系统。提及的所有其他工具当然也可以作为补充，尝试。

虽然有些软件解决方案被广泛采纳，但是没有也不可能有一个放之四海而皆准的DevOps必选软件列表。DevOps的具体实施是可以独立于工具软件的。

DevOps是一个新的职业

我们要说的下一个误解，常见诸于一些招聘机构与求职 站。它们把DevOps描绘为一个全能战士，会编码，会测试，会部署环境，还会管理基础设施。也就是说，他/她能够有效地执行软件开发人员和支持工程师的所有工作，但只领一份薪水。

另一个常见的场景是，将大家熟悉的系统管理员这个古老职业，替换为更时髦的“DevOps工程师”。看看下面的职位空缺，从其描述中就可以断定,它们与DevOps一点关系也没有。

一家初创软件公司正在寻找一位远程工作的DevOps/系统管理员
——某职位搜索 页

第三个例子是DevOps大师，需要他/她来公司“实施”所有的DevOps“动作”。这有些类似于敏捷教练或Scrum Master。

当然了，所有这些都是严重的误解。 DevOps是IT部门从根本上发生深远的变革，这不可能通过招聘一些DevOps工程师或者邀请几个DevOps大师就得以实现。具备实施软件交付流水线的能力，也不能保证取得成功。实施DevOps的实践，也不太会节省成本。

点击此处即可免费领取DevOps资料~

翻译：林伟丹，姚冬

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8667 人正在系统学习中