对DevOps中可交付软件部署的阐释

Dan Zentgraf是Ascendant Technology公司的一名领域架构师。他的任务是帮助顾客采用DevOps和敏捷实践。作为一位咨询师和产品经理，他在软件领域拥有与商业、工程主管一起工作的12年从业经验。

这片文章讲述了将传统的软件开发方式转变为使用新兴的Devops理论、技术所带来的挑战以及在新方式中所需要注意的变化。这篇文章的研究范围包括部署内容的定义以及为了利用DevOps 所需要的组织和文化的革新。

敏捷开发的一般原则是开发团队应该一直以可持续的速度不断地交付软件。与此同时，基于相关的虚拟化和云计算，许多新的操作工具和基础设施已经可以为我们所用。虽然很多研发团队已经主动采取了敏捷开发的方法，但是他们开发的软件常常不能被用户接受，因为他们的程序充满了缺陷、易出错的手工任务或者和运维相关的延迟。

同时，竞争日益激烈的市场环境给业务主管带来了巨大的压力，因此他们要求在更短的周期里把新软件和特性交到客户手里。敏捷开发、新运维技术和市场需求导向这三个因素正在使人们重新思考应该如何看待软件开发。

这三种趋势的共性是变化的速度增加了。那种把用户所需要的软件功能搁置几个月再去开发的做法已经无法被接受了。软件只有使用的时候才有价值，快速的得到那种价值在今天的市场上显得尤为重要。这种转变使人们质疑团队开发软件的种种假设，而质疑的结果就是DevOps的问世。

为了总体上理解软件交付，尤其是用DevOps进行软件部署，理解以下两点很重要：

首先，对DevOps以及各种利益相关者对它感兴趣的原因有一个清晰和正确的理解是十分必要的；

其次，当我们尝试应用DevOps时，理解软件部署的假设是如何变化很重要。

当这些理解了这些之后，才有可能了解支持DevOps的可执行部署的框架。

理解DevOps和利益相关者

DevOps这个术语，由英文单词development和IT operations组合生成，一般指的是一种利用所有各种规则统一软件系统的相关工作的方法，，从而以业务部门要求的速度将更改交付给系统。它通常与进行快速而小的改变的敏捷开发结合起来，目的是注意力集中于高价值的工作，最小化由大的变化所产生的缺陷风险，减小由于工程完工后软件特性与商业要求的严重背离而带来的软件价值偏移。另一方面，运维的观点是指将变化视作不稳定性的成因。不稳定性必然会导致宕机，这是运维当中最严重的负面事件。因此，运维团队常常抵制变化。

然而，DevOps常常被视为一种改变，因为在绝大多数的开发团队中，开发、运维和市场三者之间有着一系列的的冲突行为和回报，从而导致无数的不当行为。市场给进行新特性开发和追求变化的开发团队以回报，但是却因为宕机而处罚运维团队。因此，开发团队迫切要求运维人员进行更多的部署；运维团队则要求开发人员的交付模块包含更多结构和更高的精确度。这些矛盾在很多开发团队中已经根深蒂固，并且因为各自团队成熟度的固有不同而更加严重。DevOps力图消除这些障碍，为这些竞争团队搭建一个共同合作的平台，从而把他们集中到同一个目标上。为了实现这个目的，理解每一个团队的心态非常的重要。

研发

研发通常被认为更加的接近市场需求。《敏捷宣言》已经问世十多年了。从某种程度上说，该宣言是早期极限编程、结对编程和实践的结果。公平地说，这个难题的软件部分被视为是很容易实现的目标（它很容易改变，但理论上独立于基础设施和平台之上）。基础设施习惯上被认为是一种很难被改变的昂贵资本支出，并且有很长的摊销周期。不幸的是，复杂的软件需要很多的基础设施，并且要求基础设施和软件本身同步发展。这种联系就是为什么早期DevOps有时被称作“敏捷运维”。

无论人们怎么称呼它，如果科技与市场需求保持同步的话，坚持软件和基础设施分开的想法是不可持续的。这迫使研发团队接受维持复杂基础设施生产的现实。

运维

幸运地是，一些新的科学技术已经成为运维领域的最前沿，从而帮助运维更加的符合市场需求。运维领域最主要的颠覆性技术是便宜的硬件商品虚拟化的广泛普及。这产生了新的系统管理方法，当然还有云计算。这种科技由于能让开发团队快速而容易地整合他们未被充分使用的计算资源从而直接产生价值，因而快速流行起来。美国Gartner咨询公司估计现在50%的应用在虚拟环境中运行。

然而，简单的整合只是一种有限地回收价值、缩减开支的的办法。虚拟化技术也使基础设施具有了一定的可变性，让运维团队在不影响稳定性的前提下以以前不可能达到的速度改进基础设施。虚拟化利用技术常常在与云计算有关的项目中出现。这些新兴的技术给了运维团队一条同研发团队一样敏捷并且能切合市场需求的途径。

业务

对业务主管们来说，他们已经明白了理解和利用技术来实现目标相比以往更加的关键。根据IBM2012年的CEO调查（这个调查建立在对64个国家1700个首席执行官进行访谈的基础上），技术因素是影响开发团队排名第一位的因素。2004年技术因素只在九个因素中排名第六，此后，这个排名稳步地上升。

因此业务主管注意到响应顾客需求的能力是一种竞争优势。由此可以推断，糟糕的技术执行力是对业务的一种内在威胁。这种威胁不会一夜之间就成为现实，但是它已经一触即发。同样的调查还讨论了调查对象如何权衡理解客户的需求和用更短的交付时间来满足他们的需求。最后，这是一种和过程现实相冲突的业务压力。这种过程现实就是研发和运维的技术规程过去是如何运作以及激发将商业做的更好的讨论。

DevOps和部署

高频率

为了实现这些目标，最明显的变化之一是我们假设把新的软件功能交到用户手中才能让软件更有价值。这个假设意味着越早发布新的软件功能越好，因为这意味着新的软件功能所带来的价值实现的更快。但是绝大多数的开发团队，以前都以用很长的时间开发很大的软件为导向。

这种短周期、高频率的开发假设才正是软件开发定义转变的根本所在。DevOps摒弃了原来那种一年当中将开发进程暂停很多次而去做很大的软件整合和组装的想法，取而代之的是一个开发系统应该能持续运行，并且擅长连续不断地开发大量小的增量。关键点是替代。传统的以大的开发为导向的系统通常都很笨拙，所以很难高速运转来支持DevOps。“用旧方法做，就是尽量快点”的企图常常会失败，因为创造旧方法的假设从来不是为了支持高频率的活动。这不是好与不好，这只是一个需要解决的工程问题。

鉴于这种新的交付过程变成了从软件投资中获取价值的固有的一部分，这种过程理所当然也就成为了整个系统新的扩展。它成为了评价研发投资最基本的方式。于是，这也形成了管理交付进程的效率和效果对整个系统来说有着直接且可计量的商业价值的假设。这个假设所暗含的意思是忽略维持交付能力所产生成本是不可行的。

系统全景

DevOps研发另外一个特点是它着眼于完整的系统而不是简单的能实现软件功能的代码变化。DevOps严谨地认为应用程序代码依靠服务器、网络和数据库等基础设施来实现它的价值。因此，DevOps部署方法同等地对待系统组成部分的所有变化，以同样的方式追踪记录这些变化。一些基础设施的变化，比如一个谨慎的网络交换机升级或者存储设备的增加，会被视为性能的增强（系统的新功能），即便这些变化可能会不太容易察觉。同样的，网络服务器的或者SAN固件补丁可能会被认为是修复补丁或者缺陷。不论一个开发团队如何将事物分类，关键是他们能够用同样的严谨态度去对待其他部分，来保证整个系统的持续稳定。

在DevOps环境下，将全局系统的视角运用到一个高层次的模型中会产生下面四种将被交付的核心变化：

应用

应用是系统中编写代码的真正特性。它是驱动整个核心业务进程的具有高度可见性的功能。它的这种可见性使它获得了很多的注意，但是这种关注几乎没有给支持它的环境带来任何主动式的价值考虑。

操作系统服务

操作系统服务适用于所有的机器（虚拟的或是真实的）、操作系统服务、程序库和能让应用运行的中间软件。所有环境下配置的协调性，从测试一直到生产，都是应用稳定性和质量的关键驱动因素。

网络服务

网络服务将所有的网络设备和配置集中在应用的周围。这些配置显然影响运行和可用性，但是也能影响应用行为和体系结构。例如，应用和负载均衡器必须就在其他事物中就session处理达成一致。

数据库

应用中的数据库包含应用使用和产生的关键数据。在应用的整个生命周期中，数据库和应用必须在数据规划结构方面完美地保持同步。

DevOps部署系统的特性

DevOps部署需要一种很严格缜密的方法将各种变化传递到这种部署所支持的软件系统。系统需要承受的异常、变化或者是特殊的事件越多，系统开发尤其是维护就会越昂贵。控制交付过程的复杂程度就要理解并控制将被交付的对象以及它们是怎样被交付的。这要求开发团队必须商定一套构成每个交付单元的已定义的程序包和一个能和谐地将程序部署到所需要的环境中的系统。

已定义的程序包

一个有效的交付系统要求被交付的项目符合一定的标准。现实世界中的集装箱就是一个很好的例子。这种标准的集装箱能够被标准的设备通过极其复杂的物流网运输。这个物流网络包括很多不同的交通方式，如火车、货船和货车。在起重机和追踪系统的帮助下，我们能将任何东西运送到任何地方，只要它能够被装在一个集装箱中。将这些集装行标准化是世界商品运输和贸易史上的一次革命。

好消息是我们没必要制定一个国际化的标准来将变化交付到一个软件系统中。许多开发团队已经通过一些活动拓展实现了这个目标。许多开发团队正在通过持续集成或者其他的计划以稳定的速度开发软件内部版本。这些内部版本拥有或者应该拥有一些独特的身份标识，能让使用它们的人，比如测试者，预期软件的性能和特点等。

这种方法能给开发团队提供一条理解其他三大组件中变化组群的基准。如果这四大构成中的每一种都有一种标准方式去识别变化，那么通过独有的变化指示器去追踪这四大构成的组合就会变得相对直接简便。对应用的内部版本号、配置服务器以及数据库的模式版本等的组合

就能够被记录并且被部署到任何测试或者使用环境中。

交付系统

然而，不像集装箱，可部署数据包系统不一定和水力学和柴油燃料有关。相反，它涉及一组工具和程序，它们能让开发团队以同样的方式操控他们的开发环境、测试环境以及生产环境并且任何时候都能将数据包部署到任何一个环境中。这些工具和程序涉及环境中的各种函数。这些函数包含不同领域的专业知识，并且根据四大组件中出现的问题以不同的方式运用。考虑到各种函数复杂性，根据它们的作用建立一个框架来将它们形象化并分成不同的种类将会很有帮助。

对DevOps而言，容量分类法包含六大类，每一大类又有很多小类。这个框架不是为了分类而分类，也不是说所有的部件都必须拥有所有的性能。然而，它却为理解优先化在构建一个DevOps交付系统时所存在的障碍提供了一种有用的工具。

下面这些定义总结这六大分类：

变化管理——保证对系统进行的改进被正确地记录而进行的活动；

编制——同步协调分布系统中所有活动；

部署——和管理正在基础设施上运行的各种模块的生命周期相关的活动；

监控——提供保持环境正常的指示器和为相关利益人提供系统运行反馈；

系统注册——将整个系统运行需要的所共享的基础设施信息进行集中归档；

供应——保证基础设施环境提供足够数量的正确部件来供系统运行。

分类法应用

分类法的价值是它为我们理解环境，识别其中的首要目标以及评价合适的解决方案提供了一种方法。它使得一个开发团队能快速对目标和和现有工具的性能有一个结构性的了解。此外，它也能用来评价一个开发团队或者解决方案在一段时间的运行情况。这种结构性的分类法根据具体的情境，也会一定程度让评价内容更加详细。

例如，2012年IBM发布了一款持续部署框架软件的测试版，叫做SmartCloud连续交付系统。这个框架的目的是开发交付可以帮助开发组织应用DevOps交付方法的工具和整合程序。

通过只应用分类上层的一些函数，我们就能看到这种分类方法是如何系统而完善地包括着六大分类的：

首先，SmartCloud持续交付测试版利用IBM的Rational Team Concert软件和Rational® Asset Manager软件来提供一些变化管理、编制以及部署功能。

其次，也有一些利用IBM的云系统基础设施工具（比如IBM Workload Deployer，IBM® SmartCloud™ Provisionin，IBM® PureSystems）来提供系统注册和供应的功能的整合方法。

第三，也有一些报告反馈程序提供监控功能。

最后，也有一些整合工具，如Rational Automation Framework和Rational Build Forge。它们具有部署和编制功能。

即使用结构化的分类方法随便看看，也能知道SmartCloud连续交付对这六种功能都有涉及，但是每一种功能涉及的深度又有所不同。每种功能的不同深度正是工具提供者在强调不同方法、整合不同的产品或产品组合及将客户要求最优化时所期望的。用一种协调一致的的方法来评价解决方案是开发团队保证客户能得到他们想要的东西的关键所在。

系统操作

不论用什么结构来理解，DevOps交付系统是一个应用系统中所有变化的中心代理。这种集中性对所有应用运行所在环境都适用，包括生产和再生产环境。这保证应用总是在一种已知的状态下和一种配置已知的环境中运行。到达那种状态不仅仅需要对开发新功能的原则和所在框架有一个清晰的了解。它更需要对原则的应用和遵守，开发团队必须尊重一些因素才会更有效。

环境管理

允许软件系统运行的多环境总是存在。我们有生产环境，当然同时也要有一些质量保证和测试环境。这些质量保证环境是开发团队验证某一给定的变化会产生所预期的效果的地方。这些环境常常被视为仅次于生产环境，但是事实是测试环境中错误的信息会导致生产中断。这种依赖意味着开发团队必须严肃地对待这些环境。这是成功的DevOps交付所依赖的。

严肃对待这些环境的第一步是保证所有的环境都真正的具有代表性。确认某一质量保证环境中某一假定的配置对生产环境来说是一个好的代理，这是一项工程性工作。在这条基线建立之后，保持这种状态就会变得更加简单直接。

第二步是保证所有的变化都通过质量保证环境得到提升，而后再进入到生产当中。因为一项应用应该被视为一个整体，所以对生产环境任何方面不经过质量保证环境的的配置变化都是不允许的。这要求我们改变自己的观点，不要再认为变化很容易或者自己所做的变化和其他的不同。除了明显的减小风险和提高可靠性的好处外，这种做法也能减少环境维护和同步的花费。这种方法意味着环境总是在一种已知的状态中运行，同时也意味着减少了管理多环境配置的重复工作。

异常处理

即使用一种统一的环境管理方法，紧急情况也会出现。在环境中异常事件应该非常的罕见。一个严重的事件经常是由外部因素导致的。平台中的供应商Bug或者紧急安全补丁就是很好的例子。这些不应该是由内部因素导致的变化。

处理异常情况时，我们应该把异常当做重要的事件并且应该及时矫正并反思。矫正必须着眼于环境的再同步。例如，如果标准的变化传递系统不是用来将变化适用于突发性环境，这个变化必须被加到标准的变化传递系统中。不管这个变化是如何被适用的，也必须有一个事后处理过程来解释异常发生的原因，更要要的是解释如何减小异常再次发生的机率。

度量和持续改进

用DevOps方法来传递软件变化为我们提供了充分的机会来度量和改进程序。除了标准系统的一致性外，DevOps方法的高频率也提供了更多的数据点。各种各样的度量对象，如周期、数据包缺口和程序故障，都是常见的度量之物。这些度量不是典型的运维度量，如可用性和可用时间。相反，它们以保证可用性和可用时间为工作方针。其他好的追踪记录对象是对程序有效性和效率的度量。维护应用系统所需的工作时间、维护DevOps基础设施所需要的时间和向给定环境交付所需的等待时间都是很好的度量对象。

一个DevOps交付方法也能让应用系统拥有强大的检测仪功能。这些度量只能针对特定应用的，但是它们揭示了运行情况和用户体验反馈等等。因此，这些度量告诉我们是否应该主动比较操作环境、识别应用系统中的瓶颈或者管理容量需求。

松散耦合

DevOps交付中的工具必须松散地耦合到它们被部署的环境中去。这意味着开发团队必须能够在不对整个系统进行重大分裂的条件下替换某个工具。从架构上讲，有一些方法来实现这个目的。例如，将注意力集中于那些使用网络服务APIs作为基本整合原理的工具就是部署运用DevOps工具时的流行做法。不管用什么技术方法，开发团队必须意识到改变某一工具对团队整体部署变化的能力有一定程度的影响。当开发团队想替换某一工具时，他们必须谨慎地分析所带来的影响并将它和替换所带来的好处进行权衡。

总结

DevOps倡导一种软件交付的根本性变化。这么做的好处却是更加快速频繁地交付更高质量的软件。用一种结构性的方法去将应用系统视为一个统一的整体能帮助开发团队进行协调合作。那种协调合作能够通过一种系统的方法来支持，从而更加高效地交付和提高用来交付整个系统的功能。DevOps方法支持以稳定、多周期渐进式改进为特点的敏捷开发，并且提供给开发团队持续地按用户要求交付有价值的软件所需的结构和洞察力。这才是开发部署软件的要义所在。

 

查看英文原文，请点击这里。