DevOps很难定义,因为有很多原因。它看着像什么,怎么工作的,IT行业里各种各样角色有不同视角和不同的观点。DevOps影响着IT中的每个人,但是它用不同的形式影响着每个角色,他们对它有不同的描述。

DevOps不是什么

仍然很难给它定义,因为人们对它有不少误解。因此,在我们试着给DevOps定义前,先花点时间来击破这些最常见的误解。

DevOps不是一个新工具

当DevOps社区创建了很多很酷的新工具的时候,许多DevOps建议不能没有工具。使用Puppet、Docker、Jenkins或者其他工具,并不意味着你正在“做DevOps”。工具不是DevOps,它们只是让它变得可能。

DevOps不是一个新团队

“DevOps”这个名称表明了它连接了IT中的Dev和Ops部分。在它们之间增加其他组将对实现最终目的产生反效果。创建一个DevOps团队,通过进程和工具进行实验,建议开发和运维如何一起协作是一个伟大的开始——只要那个团队是开发或运维,而不是处于他们之间。

DevOps不是一个新角色

许多公司在网上做广告找“DevOps 工程师”,这说明他们并不理解他们需要的是什么。DevOps 包含了一个IT组织中所有的的事,一个DevOps 工程师是个“一人乐队”,需要做所有的事。所有的事!

DevOps不是大量的知识

没有中央集权也没有DevOps 标准。并没有唯一的“正确的方法”来实现DevOps 。

DevOps是什么

DevOps手册的作者 Gene Kim说道:

DevOps以及它产生的技术,架构和文化实践代表了许多哲学和管理运作的融合(包括):精益,约束理论,丰田生产系统,恢复工程,学习组织,安全文化,人力因素,高度信任的管理文化,服务型领导,组织变更管理和敏捷方法。

换句话说,DevOps的伟大实践来自于许多不同的领域,并且在IT组织内执行,为了提升IT的性能。

虽然DevOps 从许多非常成熟的学科中吸取经验,但是DevOps 潮流是最近才兴起的。DevOps术语出现在09年,标志着这个快速增长潮流的开始。与敏捷术语相比,它早在01年就出现了,说明敏捷潮流出现比它早2倍。

这股年轻的潮流是它难以定义的另一个原因。DevOps 社区增长和学习迅速。实践也正在发展演化,工具趋于成熟,并且每个加入其中的组织都贡献了关于DevOps 的经验和知识。

Gene Kim的三个方法

GK已经通过这股潮流的简短历史,清楚的描述了DevOps。他的2013年短篇小说The Phoenix Project描述了一个虚构的IT组织,使用DevOps 原理解决了一些棘手的问题。他的2016年手册The DevOps Handbook 给刚进入DevOps领域的企业提供了详细的指导,基于上百家已经使用DevOps的企业实践经验。

这两本书都基于和围绕他的“三个方法”。GK的三个方法是DevOps的主要部分,提供一种路标来理解和执行DevOps。他们是:

1. 流程

2. 反馈

3. 持续学习

1. 流程

第一个方法包括专注于IT组织内活动的流程和不断优化,让流程变得更顺畅和快速。流程的关键之一,就是我们需要处理流程的价值(软件的形式),从我们的开发团队到在生产操作中使用。这包含的概念就像持续交付和优化开发管道。

精益的来讲,第一个方法包括理解你的 “价值流程”,鉴定和为顺畅流程除去障碍,并且为了流程的增长速度采取自动化。

2. 反馈

第二个方法建立在第一个之上,通过优化反馈的从右到左的流程。这包括基本的反馈——开发团队观察他们的软件在生产中执行的如何,实际的最终用户使用的怎么样。它也包括任何和所有类型的反馈,和其中所有涉及到的角色。

第二个方法的意图是为人们提供清晰的可见性,做任何任务他们都可以进入工作质量中,并对他人产生的影响,都在IT内部和在大多数客户,用户和组织上。这不仅包括确保提供反馈,也缩短和优化反馈环路,因此人们能尽可能快和自动的收到反馈。

3. 持续学习

通过流程和反馈的完善,第三种方法利用持续学习和持续改进成熟的模式。

也许有人会问,诸如:“我们可以从所做的和收到的反馈中学习到什么?”或者“我们如何使用那些知识来提高IT组织的性能?”

最后,这个学习超越了我们的基础工作,并且包括实验来发现新的和创新的方法,来更好的满足客户、用户及组织的需求。例如,在“假设驱动开发”中,我们假设软件功能是用户和客户需要的,然后建立软件实验来测试假设,丢弃失败的实验和建立在工作之上。

第三中办法涉及到一个文化转型,在我们类似失败中:拥抱失败的意愿可以看做是一个学习的机会!不论它是一个意料之外的运行故障,还是一个我们经过实验的发展,我们看到失败既是好的,因为我们从中得到了学习,它让我们变得更好。

自动化你所能的一切

一个DevOps关键原则是:“自动化你所能的一切。”这个原则非常重要,因为自动化对IT厂商的能力来实现流程(第一个方式),快速反馈回路(第二个方式)和高性能(当第三种方法持续学习和持续改进奏效了)的核心。自动化可以从多种方式来增强DevOps性能:

• 增长速度。自动化活动比手工快得多。如果一个活动可以自动化,那么没人可以比自动化做的更快。

• 减少人为错误。工具不会像人那样犯错。工具一旦被配置好,验证也是正确的,它之后每次执行任务就不会出错。

• 一致性。任何工具的定义都是一致的。工具可以用来检查和核实活动内的一致性,那个不是自动化的。

• 降低风险。因为工具不会犯错,并且可以用来检查手工活动,部署它们可以降低不可避免的风险。

高性能组织会自动化他们能自动化的一切;这也是他们如此高性能的原因。

DevOps长期冲突解决的核心

每个IT组织有2个同时要做的重点:

• 创新。通过开发和部署新的成熟的IT服务和应用,紧跟和客户及用户的变更需求。

• 稳定。确保客户和用户能使用那些IT服务和应用,并且保障他们的数据和信息安全。

这两个重点,彼此本质上是互相冲突的,因为部署变更到生产环境中,是最常见的中断原因和其他操作问题。更糟的是,这些冲突的优先级在IT厂商内导致摩擦和其他障碍,因为开发通常创新优先,而运营是稳定优先。

DevOps不是说开发和运维(和质量和安全)必须合作。它也通过同时能够创新和稳定,解决核心的长期冲突。DevOps时间和工具确保整个IT组织的稳定和可预见性,在创新和开发进程的时候,通过特殊的集中于稳定。通过允许IT团队移动更快和部署不会危及安全和稳定,来加速创新。

学以致用

你的IT厂商已经在DevOps旅程的第一步了(至少),因为DevOps不是意味着扔掉所有东西和返工。不如说它意味着看看如何做,做什么,并且使用特殊的工具和技术让工作流程顺畅,提高反馈,开始持续学习和提高。

识别什么有害,从其他人那学习修复问题,做一个提高。你看,你已经在DevOps进程上了。