团队组织是否“DevOps化”很难被定义，因为它在IT中的各种角色的工作原理是不同的，其间也有很多误解。- Alan Koch

是否“DevOps化”真的很难被定义，以下会讲到这里面的几点原因。IT系统中各种角色的人还会存在不同观点，可能它看起来和它的工作原理看起来有很大区别吧。DevOps影响IT中的每个人，但它会以不同的方式去影响每个角色，从而产生不同的描述。

是否DevOps也很难定义，因为世间对它存有太多误解。那么，在我们尝试定义DevOps之前，先花几分钟来描述最常见的误解吧。

DevOps不是新工具

DevOps要求的许多工具无法在没有工具的情况下完成，随之DevOps社区很多无私奉献的大神创建了许多酷酷的新工具。当然，用着Puppet或Docker，又或Jenkins等其他工具并不意味着你就在做DevOps的事情。这些工具不代表DevOps，它们只是工具。

DevOps不是新团队

字面上看，“DevOps”把开发部分与Ops部分联系起来。事实上如果还要在开发和运维之间增加其他组织，这就会起反作用。创建DevOps团队测试流程和工具，并促进Dev and Ops共同合作，这是一个好的开始。

DevOps不是新角色

许多公司都在暗地打听“DevOps工程师”，这说明他们不明白其内涵以及需求什么。其实，DevOps包括了IT组织中的一切，DevOps工程师将是一个IT-one-man-band，而且对象无所不包。

DevOps也等你定义

DevOps领域没有权威，没有标准，DevOps也没有一个“永恒正确的打开方式”。

别人眼中的DevOps

Gene Kim等人的DevOps手册说：DevOps及其产生的技术，构建和实践代表了许多哲学和管理运动（包括）的融合：精益，约束理论，Toyota生产系统，弹性工程，学习型组织，安全文化，人为因素，高信任管理文化，雇佣领导，组织变革管理和敏捷方法。

换句话说，DevOps是一个从许多不同领域获取良好做法的问题，并将其实施在IT组织中，以提升IT的绩效。

虽然DevOps来自一些非常完善的学科，但DevOps本身就是近年的东西。“DevOps”一词是在2009年底创造出来的，这个时候也标志着这个快速增长运动的开始。将其与2001年初出现的“敏捷”一词比较，敏捷性方面大涨两倍以上。

出现时间短也是DevOps难以界定的另一个原因。DevOps社区一直在增长和快速学习，这些实践正在发展，工具正在成熟，并且加入的每个组织都有助于我们对DevOps的进一步了解。

《凤凰项目》Gene Kim认为的三种方式：

Gene Kim曾在DevOps这个短暂的历史变动中清晰描绘过DevOps体系。他的2013年的novelette《凤凰项目》描述了一个虚构的IT组织及其使用DevOps原则来解决一系列严重的问题。他把之前数百家组织已经实施成的DevOps经验浓缩于2016年的《DevOps手册》，为任何开展DevOps之旅的组织提供了详细的指导。

两本书都以“三种方式”为基础展开描述。Gene Kim本人向我们描述：基金会的三种方式是DevOps旅程的主要组成部分，并提供了一种了解和实施DevOps的路线图。它们是：

1. 迁移（flow）

2. 反馈（feedback）

3. 持续学习（Continual Learning）

• The First Way: Flow

第一种方式是专注于IT组织中的活动流程，往顺利，快速方面进行优化。在此环节中，需要解决的关键流程之一是从开发团队到生产中的价值流（the flow of value，以软件的形式），这涉及连续交付和优化部署Pipeline等概念。

以精益思维看，第一种方式是理解你追求的“价值流”，识别和消除阻碍流动的障碍，并自动化以增加流量。

• The Second Way: Feedback

第二种方式是建立在第一种基础之上优化从右到左的反馈流程。这也包括最终的反馈 - 开发团队敏锐地了解他们的软件在生产中的表现以及最终用户实际如何使用它们。这部分还包括所有角色中所有人的任何类型反馈。

第二种方式目的是为在IT组织反应工作质量以及对客户的影响，并将之可见。这不仅包括确保反馈的稳定提供，且包括缩短和优化反馈循环，以便人们尽可能快地自动收到反馈。

• The Third Way: Continual Learning

流动和反馈良好的前提下，第三种方式利用了建立继续学习和持续改进的模式。

它生来自带一些门槛问题：“我们可以从我们所做的和我们收到的反馈中学到什么？”以及“我们如何利用这些知识来改善IT组织的绩效？

最终，这种学习超出了我们工作的基础，包括尝试寻找新的和创新的方式来更好地满足客户、用户和组织的需求。例如，在“假设驱动的开发”中，我们假设用户和客户可能需要哪些软件功能，然后构建软件实验来测试这些假设，丢弃失败的实验，并建立在那些正向工作上的继续学习和持续改进。

第三条途径涉及到我们失败方法的文化转型：愿意把失败当作学习机会。无论是意想不到的操作失败，还是我们通过实验带来的失败，我们认为失败是好的，因为我们可以从中学习，逐渐完善。

尽可能的自动化

一个关键的DevOps原则是“自动化你尽可能想到的一切”。这个论调很重要，自动化利于优势流转（第一种方式），快速反馈回路（第二种方式）和高性能（随着持续学习和持续改进，第三种方式）。

自动化是DevOps底线，再看它想对现有模式的优势所在：

1. 加快速度

自动化比手动快。如果某环节实现了自动化，那就几乎是最快了。

2. 减少人为错误

工具不会像人们那样犯错误。一旦工具被配置和验证正确，它将每次都正确地完成任务。

3. 一致性

一旦每个工具都按照定义确保了一致性。那就可以用工具来检查和执行不自动化环节的一致性。

4. 减轻风险

由于工具不会出错，可用于检查手动活动，因此可以部署以减轻无法避免的风险。

高效能组织尽量的自动化一切 - 这就是他们高效的诀窍。

DevOps解决核心冲突

每个IT组织都有两个同时的核心/优先事项：

**创新.**通过开发和部署新的增强服务和应用，跟上客户和用户不断变化的需求。

**稳定.**确保客户和用户都可以使用这些IT服务和应用，并保证其数据和信息安全。

这两个优先事项是相互冲突的，因为将变更部署到生产环境中是造成中断和其他操作问题的最常见原因。更坑爹的是，这些相冲突的优先事项还经常引起其他功能性障碍，因为开发通常首选创新优先级，而运维首选稳定优先级。

DevOps不只是说Dev和Ops（以及QA和Security）必须合作， 同时DevOps也通过实现创新和稳定来解决核心慢性冲突。 DevOps的做法和工具确保整个IT操作的稳定性和可预测性，特别关注创新和部署过程中的稳定性。 这可以通过允许IT团队快速移动并经常部署，从而加速创新，而不会危及安全性和稳定性。

先知而后行

看到这里，你心里已经迈出DevOps旅程的第一步了（至少），DevOps并不意味着抛弃一切，重新做。相反，它注重的是你在做什么，用特定的工具和技术改造工作流程，改进反馈，并开始不断学习和改进。

什么困难暴击了你，Google下别人怎么解决的这个问题，然后学习改进。至少，你有了开始DevOps之旅的心。