DevOps不是什么

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

    一方面，这对任何团队来说都是一种促进（影响），要么开始DevOps之旅，要么提升当前DevOps的成熟度。另外一方面，当DevOps成为一种（必要）工作时，伴随DevOps这个词的滥用、误用，那些草根式的激情将荡然无存。

    DevOps体现一种新协作文化，包含诸多有关持续软件部署方法的实践，这种方法强调持续反馈、协作和优化。DevOps要改变基本文化、要包含如此多的实践，会让那些刚刚起步的（DevOps）行程难于适从（难于承受）。

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

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

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

DevOps不是独立团队

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

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

DevOps不是一个工具

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

“我们已经在做DevOps了，我们有Chef。”
“我们在做DevOps。我们通过Jenkins进行自动化部署了。”

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

DevOps并非万全之策

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

DevOps不是自动化

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

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

关于作者/Shelbee Smith-Eigenbrode

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

原文链接