DevOps不是什么

对于接受和拥护DevOps多年的人来说，DevOps的逐渐流行就如同大学出来找到第一份工作一样让人兴奋。好吧，或许并没有这么兴奋，但还是非常酷的：-） 越来越多不同规模的公司开始拥抱DevOps，甚至接纳DevOps实践作为他们的基本策略……

一方面，这对任何团队来说都是一种促进（影响），要么开始DevOps之旅，要么提升当前DevOps的成熟度。另一方面，当它成为一项工作，随着DevOps词的滥用、误用，它原有的草根意味将消失殆尽。

DevOps体现一种新协作文化：包含诸多有关持续软件部署方法，这些方法强调持续反馈、协作和优化。DevOps要改变基本文化、引入诸多的实践，刚刚起步的团队该如何适从？

因此，我更想强调DevOps不是什么，而不是DevOps是什么。

1.DevOps不是简单开发与运维团队的整合

我们所有人都认为这是DevOps术语的来源。“让我们把开发与运维团队整合一起吧，你瞧，我们现在是DevOps了。” DevOps整合一系列贯穿整个（跨多方的）交付路径的流程与实践。DevOps中一组关键实践是持续集成与持续交付。简单整合两个团队就号称是DevOps，这并不是真正的DevOps实践。

2.DevOps不是独立团队

设立独立的DevOps团队是很多组织开启DevOps之旅的另外一个误区。事实上，我不是DevOps团队的拥趸，因为我相信，这将导致更多的竖井。我也发现在责任没有清晰定义的情况下，成立这些团队，会创造更多的混乱。

在一些情况下，临时的DevOps团队或许有助于组织接纳流程与（潜在）工具，但关键是：团队必须是临时的，即使这样也只是在理论上美好。一些优秀的博客也在讨论DevOps团队，例如，Matthew Skelton的博客：“什么样的团队结构有助于DevOps成功”。

3.DevOps不是一个工具

首先声明的是，我非常喜欢有越来越多的工具能够让我们持续优化我们的DevOps，但我发现，很多人在使用一两款工具之后，慢慢就有了一个观念（看法）：DevOps就是一个工具。不知道你听过多少次？

“我们已经在做DevOps了，我们有Chef。”

“我们在做DevOps。我们通过Jenkins进行自动化部署了。”

需要说明的是，我是Chef与Jenkins的铁杆粉丝，但我认为如果你将一款自动化工具的运用等同于DevOps，那就太小瞧DevOps了。采用自动化工具本身不是DevOps，只有将这些工具与持续集成、持续交付、持续的反馈与优化进行端到端的整合时，这些工具才成为DevOps的一部分。

4.DevOps并非万全之策

当设立总体DevOps策略和选择相应的工具链时，由于存在不同商业驱动以及多种技术可供选择，因此，对DevOps策略使用相同的DevOps原则就尤为重要：拥抱变化、收集指标、了解反馈、快速试错并纠正你的路线。举个例子，一旦你最初选用的工具不再适用于你的技术或环境，抛弃掉，然后继续前行。 这个项目使用的工具不一定适合你下个项目。我们首先需要理解我们当前策略和环境，然后做出相应的变化。

5.DevOps不是自动化

这是非常吸引眼球的一点，因此，我需要澄清一点：DevOps不仅仅是自动化。毫无疑问，自动化是DevOps非常重要的一部分，但不是唯一的部分，一定程度的部署自动化往往会与DevOps混为一谈。我想理解DevOps的关键实践，重要的标志是：DevOps不仅仅被视为自动化。理解DevOps的核心原则，关键是真正理解采纳DevOps的价值。

DevOps是什么，已有很多论述。DevOps不是什么或者不仅仅是什么，我认为更应该进行广泛的传播。如果你刚开始你的DevOps之旅或者仍旧在优化你的模式，确保你团队所有人都接受基本的DevOps培训，理解DevOps是什么，DevOps不是什么。

王葱权原创翻译DevOps系列相关文章请点击：DevOps十大IT管理工具

关于译者：

王葱权

EAII-企业架构创新研究院 常务理事

2001年加入普元信息技术股份有限公司，现任软件产品部总经理，负责普元信息技术与产品的运营工作，长期致力于企业软件平台建设实践。毕业于同济大学，主持完成一系列产品研发工作，包括普元SOA应用平台、普元BPM/ESB集成平台及移动与云计算平台等。对企业技术架构有较深刻理解，曾主持中国建设银行、中信银行、国开银行等多家大型企业的技术平台规划与落地。

原著作者：

Shelbee Smith-Eigenbrode

IBM云基础设施能力中心资深工程师/IT架构师。她担任过软件开发生命周期的各个角色。各个职能经验以及在传统竖井式的深入工作，导致她拥抱DevOps文化、并通过实践DevOps来提高团队的技术交付能力。同时她也是致力于驱动创新与技术进步的—-IBM 研究院的成员。