比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
解析大数据时代的数据库集群技术
　　当今世界是一个的世界，我们的生活中无论是生活、工作、学习都离不开信息系统的支撑。而信息系统的背后用于保存和处理最终结果的地方就是。因此数据库系统就变得尤为重要，这意味着如果数据库如果面临问题，则意味着整个应用系统也会面临挑战，从而带来严重的损失和后果。
　　如今“”这个词已经变得非常流行，虽然这个概念如何落地不得而知。但可以确定的是，随着、移动应用的兴起，数据量相比过去会有几何级的提升，因此数据库所需要解决的问题不再仅仅是记录程序正确的处理结果，还需要解决如下挑战：
　　当数据库性能遇到问题时，是否能够横向扩展，通过添加的方式达到更高的吞吐量，从而充分利用现有的硬件实现更好的投资回报率。
　　是否拥有实时同步的副本，当数据库面临灾难时，可以短时间内通过故障转移的方式保证数据库的可用性。此外，当数据丢失或损坏时，能否通过所谓的实时副本(热备)实现数据的零损失。
　　数据库的横向扩展是否对应用程序透明，如果数据库的横向扩展需要应用程序端进行大量修改，则所带来的后果不仅仅是高昂的开发成本，同时也会带来很多潜在和非潜在的风险。
　　面对上述挑战一个显而易见的办法是将多个服务器组成一组集群，这样一来就可以充分利用每一台服务器的资源并将客户端负载分发到不同服务器上，随着应用程序负载的增加，只需要将新的服务器添加到集群即可。
　　本文将对集群的概念、形式以及目前主流的数据库集群技术进行探讨。
　　数据库集群的形式
　　数据库的集群和扩展不像应用程序扩展那样容易，因为从数据库端来说，一旦涉及到了集群，往往会涉及到数据库层面的同步，因此从是否存在数据冗余这个角度来讲，我们可以从大面上把数据库集群分为以下两种形式：
　　Share-Disk架构
　　Share-Disk架构是通过多个服务器节点共享一个来实现数据库集群，两台机器最简单的Share-Disk架构如图1所示。
　　图1.简单的Share-Disk架构
　　在此基础之上，Share-Disk架构又分为单活和双活，双活即为集群中的每一个节点同时对外提供服务，而单活为集群中只有一个节点可对外提供服务，集群中的其他服务器作为冗余在“活”的节点出现故障时接替该服务器成为对外提供服务的节点。该类架构最典型的产品就是 Failover Cluster(SQL Server故障转移集群)、NEC的EXPRESSCLUSTER、ROSE的ROSE HA。这种方式的弊端也是显而易见的，如下：
　　硬件资源的严重浪费，同一时间集群中只有一台服务器活着，其他服务器只能作为冗余服务器。
　　集群无法提升性能，因为只有一台服务器可用
　　存储方面存在单点故障，除非在存储层级保证高可用，通常需要昂贵的存储。
　　因此该类仅仅可以做到服务器层面的高可用，无法带来性能的提升，也无法解决存储单点故障的问题。因此如果不搭配其他高可用或负载均衡的技术，存在的意义并不是很大。
　　另一类技术是Share-Disk中的双活的技术，与单活技术不同的是，双活的技术虽然也是共享，但集群中的所有节点都可以对外提供服务，典型的产品就是的RAC。RAC的技术性非常的高，因此需要水平比较高的人来运维系统。RAC设计的初衷并不是为了性能，而是为了高可用和可扩展性，如果应用程序不是针对RAC架构设计和开发的，则将应用程序迁移到RAC上由于block contention (block busy waits)可能会导致性能的急剧下降，并且节点越多性能下降越明显。
[ 责任编辑：杨瑗嘉 ]
为更好推动开放架构发展，打造开…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte当前访客身份：游客 [
这个人很懒，啥也没写
：想想也是这样，通过接口名称一定是反射
：非常的不错的文章，收藏，谢谢分享
：原来没想过 最近看到spring的JPA的时候就觉得好奇...
：已收藏 谢谢!
：谢谢来看了，我可能代码写的不够多，原理机制方面...
：求代码和jar
：看不懂在说什么，估计翻译有问题
：好，学习了！
今日访问：16
昨日访问：30
本周访问：269
本月访问：502
所有访问：40781
数据库DevOps
发表于11个月前( 10:10)&&
阅读（63）&|&评论（）
0人收藏此文章,
数据库DevOps
&&&&&&&&在这个充斥着大数据与商业智能的新代时，唯一不变的技术就是变化，尤其是在数据库方面。出于数据统计、继续增加的对服务的需求，以及规定制度等方面 的原因，几乎每天都有业务方面的变更需求，这些都会对数据库产生变更需求。当数据库变更发生时，能否从自动化中获得更大的敏捷性，以较少的资源实现较多的 功能，正是那些具有高度竞争力的世界级企业在芸芸众生中脱颖而出的关键因素。
如果你的竞争对手能够更快地、并且交付质量更好的特性，那么 你必然会失去市场份额。敏捷开发方法的出现正是为了在应对不断变化的需求的情况下快速地发展，在有限的资源下也能够确保理想的质量。
重量级发布的方式已经过时了，为了每次更新或发布要等上足足六个月，这种方式无异于自掘坟墓。敏捷开发方法减少了每次发布的范围，换取的是更快地完成每个变更，并且将每个变更的影响降至最低。对于技术公司与IT部门来说，必须以敏捷性来保证对不断变化的业务需求的支持。
接下来的一个逻辑步骤是将开发与运维相结合，即采用DevOps方法。
为了在敏捷的Sprint发布中有效地应用DevOps，你需要实现部署与流程自动化，自动构建内部的开发与QA环境，以及生产环境。否则的话，你只能选择手动实现部署与发布的每个步骤与流程，这就很可能产生人为的错误，而且也无法频繁地重复这一过程。
实现自动化依赖于版本控制系统，它能够管理所有等待构建并部署到下一个环境的软件资产。
构建流程的第一个步骤是清理工作空间，并从版本控制库中换取相应的文件。这一重要的步骤避免了流程外的变更。如果开发者直接将变更保存到构建服务器 的工作空间，而不是将变更签入版本控制库中，那么这种变更仍然有可能产生。这个例子听起来似乎有些可笑，因为开发者都明白，如果不把变更签入到版本控制库 中，这些变更就会丢失，因为技术手段保证了流程的正确性。这一步骤同时也避免了将尚未完成的变更包含至构建过程中，只有通过正确的签入流程提交至版本控制 库中的变更才会加入构建过程。版本控制库在这里成为了唯一的信赖源。
数据库是关键的部件
如今多数的IT应用程序都包括数量众多的部件，使用了多种不同的技术：移动、ASP、PHP、应用程序服务器、Citrix及数据库等等。为了让应 用程序正确运行，必须让这些组件相互配合。下面举个例子，如果在某张表中加入了一个新的列，或是在某个存储过程中加入了一个新的参数，那么为了让功能正常 运行，其它所有的应用程序组件也必须与结构的变化进行同步。一旦同步过程出错，应用程序在调用存储过程时使用了错误的参数，或者是在插入数据时遗漏了新的 列，应用程序就会出错。
数据库组件的独特性将它与其它组件区别开来：
数据库不仅仅只是SQL脚本，还包括了表结构、在存储过程中用数据库语言编写的代码、在引用表或配置表中所存放的内容，以及对象之间的依赖等等。
数据库是集中式的资源，多个开发者可以在同样的对象上进行工作，因此必须对他们的工作进行同步，以避免代码相互覆盖。
数据库变更的部署不像拷贝与替换旧版本的二进制文件那么简单，在将数据库从版本A转换至版本B的过程中，需要在保留业务数据的同时转换为新的结构。
数据库代码直接存在于数据库中，并且可以在任何环境中进行直接修改。这一点就与其它的组件不同，它们都是在构建服务器中的某个干净的工作空间中进行编译的。
必须满足的需求
在管理数据库变更时，需要克服一系列的困难，你必须做到以下几点：
确保所有的数据库代码都被涵盖（结构、代码、引用内容和授权等等）
确保以版本控制库作为唯一的信任源
确保被执行的部署脚本在运行时能够正确判断环境状态
确保部署脚本能够正确处理与合并冲突
只为相关的变更生成部署脚本
确保部署脚本了解数据库的依赖项
对于在开发阶段，以及内部部署（开发环境与QA环境）或部署到生产服务器时的数据库变更管理，有四种通用的管理方式。
建立开发阶段生成的SQL变更脚本
建立一个变更日志的跟踪系统
建立简单的比较与同步机制
建立一个数据库执行变更管理解决方案
建立开发阶段生成的SQL变更脚本
管理数据库变更的最基本方式，就是将所有变更命令保存在一个或一系列脚本中，并且在基于文件的版本控制系统中对它们进行管理。以此保证在一个单一的 存储库中保存所有的应用程序组件资产。对于开发者来说，将数据库变更进行签入可以使用的功能类似于他们签入.NET或Java的变更时的功能，例如将变更 与变更原因（变更请求、缺陷编号、用户故事等等）相关联。对于当前流行的各种基于文件的版本控制方案来说，基本上都能够在多个开发者对同一个文件进行变更 的时候发出合并的警告。
但让我们来看一下，这个解决方案是否真正能够克服数据库方面的各种挑战，并且避免各种可能的风险呢：
确保所有的数据库代码都被涵盖 —— 由于开发者或DBA编写了脚本，因此他们能够确保所有数据库代码都被涵盖。
确保以版本控制库作为唯一的信任源 —— 并非如此。因为开发者和DBA能够直接登录（任何环境的）数据库，并且直接在数据库中进行变更。
手动编写的SQL脚本
对于部署脚本的变更，例如发布内容范围的变更、分支合并及重复劳动等等必须手动完成，并且需要额外的测试。
这种情况下需要维护两种类型的脚本，即对这次发布的创建脚本，以及针对某些特定变更的变更脚本。对于同样的变更需要维护两种脚本，这已是灾难开始的前兆了。
确保被执行的部署脚本在运行时能够正确判断环境状态 —— 这一点取决于开发者，以及脚本编写的方式。如果脚本本身只包括相关的变更命令，那么它对于执行时的环境状态就一无所知。这就意味着即使某个列已经存在，它也会试图再次新增这个列。而如果要编写能够在执行期判断环境状态的脚本，会极大地提升脚本开发工作的复杂性。
确保部署脚本能够正确处理与合并冲突 —— 虽然基于文件的版本管制系统提供了合并冲突的功能，但这一点对于数据库来说意义不大，因为版本管理库里的内容未必是百分之百准确的，因此也无法充当唯一的信任源。脚本或许覆盖了另一个团队所做的某个hot fix，而这种错误不会留下任何痕迹。
只为相关的变更生成部署脚本 —— 脚本的创建是属于开发过程的一部分。根据所布置的任务，如果要确保脚本中只包括相关的、并且经过授权的变更，必需对脚本进行改动，而这进一步提高了部署时的风险，并且也会浪费时间。
确保部署脚本了解数据库的依赖项 —— 开发者必须在编写脚本时留意到数据库的依赖项。如果只使用一个唯一的脚本，那么变更通常是按顺序从脚本的最后加入的，这就有可能导致对相同的对象进行多次变更。而且如果要使用多个脚本，那么脚本的执行顺序则至关重要，并且必须手动维护。
结论：这种基本方式不仅无法克服数据库的各种挑战，并且极易出错，也极耗时间，并且需要引入一个额外的系统以跟踪被执行的脚本。
建立一个变更日志的跟踪系统
另一种常见的方式是使用XML文件作为一种抽象的语言，对变更进行描述并对执行过程进行追踪。这方面最常见的开源解决方案就是Liquibase。
Liquibase使用XML文件将逻辑变更从物理变更中分离出来，并且允许开发者在不了解数据库的特定指令的情况下编写变更。在执行期间，它会将 XML转化为特定的RDBMS语言以执行这些变更。所有的变更将被组合到一个变更日志中，日志可以作为一个单独的XML文件存在，也可以是由一个包含了变 更顺序的主XML文件所引用的多个XML文件共同实现。
可以用现有的基于文件的版本控制系统保存这些XML文件，这一点与基本方式的好处是相同的。此外，通过Liquibase的执行跟踪能力，还能够了解到哪些变更日志是已经被部署过，不应该再次运行的，以及哪些是尚未部署而等待运行的。
那么让我们来看一下，Liquibase是否解决了这些挑战呢：
确保所有的数据库代码都被涵盖 ——Liquibase中的XML文件不支持对引用内容变更的管理，必须由外部的扩展功能进行处理，这就很可能导致某些变更被遗忘。
确保以版本控制库作为唯一的信任源 ——Liquibase本身没有任何版本控制的功能，它依赖于第三方的版本控制工具对XML文件进行管理。因此，你还是必须想办法保证基于文件的版本控制 库能够正确地反映当前被测试的数据库版本。为了确保版本控制库能够作为唯一的信任源，开发者必需将变更签入，以便进行测试。这有可能导致尚未完成的变更也 被部署到下一个环境中。
确保被执行的部署脚本在运行时能够正确判断环境状态 ——Liquibase知道哪些变更日志已经被部署，并且不会再次执行它们。但是，如果某个逻辑变更是增加一个日期类型的列，而该列已经存在，并且是varchar格式的，那么部署肯定会失败。此外，Liquibase也无法避免外部进程对数据库进行的任何变更。
确保部署脚本能够正确处理与合并冲突 ——在Liquibase之外对数据库进行的任何变更都可能导致冲突，而这是Liquibase无法处理的。
无法处理外部进程产生的变更
只为相关的变更生成部署脚本 —— 在变更日志这一级别可以忽略某些变更，但将一个变更日志分解为多个日志需要重写编写XML文件，而这也需要更多的测试。
确保部署脚本了解数据库的依赖项 —— 在变更日志XML文件的编写过程中，需要手动维护变更的顺序。
结论：使用能够追踪变更执行的系统并不能处理数据库开发中的所有挑战，最终也无法胜任部署的需求。
建立简单的比较与同步机制
另外一种常见的方式是通过将源（开发）环境与目标（测试、UAT、生产等等）环境进行比较，由此自动生成数据库变更脚本。这种方式节省了开发者与 DBA的大量时间，因此他们无需手动地对每次发布的创建脚本或变更脚本进行手动维护了。只在需要的时候生成对应目标环境当前结构的脚本。
让我们再来看一看，这种方式是否能够应对数据库管理的挑战：
确保所有的数据库代码都被涵盖 —— 多数的比较与同步工具都了解如何处理不同的数据库对象，但其中只有一部分工具能够在比较与同步时处理引用数据。
确保以版本控制库作为唯一的信任源 —— 简单的比较与同步工具在执行比较与生成合并脚本的时候，并不会用到代码控制库。
确保被执行的部署脚本在运行时能够正确判断环境状态 —— 最佳实践是在准备执行的时候生成脚本，这样就能保证它引用了正确的环境状态了。
确保部署脚本能够正确处理与合并冲突 —— 简单的比较与同步工具将A与B（源与目标）环境进行比较，基于右方的表，该工具能够生成一份脚本，将目标环境进行“升级”，以符合源环境的内容。如果不了 解某个变更的内容，那么有可能会生成错误的脚本。举例来说，在目标环境中有一个索引，是在某个不同的分支或是严重缺陷修复时创建的。如果该索引并不存在于 源环境中，那么工具又该怎么做呢？删除这个索引？如果在开发环境中存在某个索引，而在生产环境中不存在，是意味着开发环境中加入了这个索引，还是说生产环 境中删除了这个索引呢？使用这种工具作为解决方案，需要你对每个变更的内容有深入的了解，以保证能够正确地进行处理。
只为相关的变更生成部署脚本 —— 比较与同步工具会对整个数据库schema进行比较，并显示出不同之处。但它们并不了解变更背后的原因，因为这些信息是保存在软件生命周期管理工具、 CMS，或是版本控制库中的，而它们对于比较与同步工具来说属于外部信息。结果是你可能会被一大堆无关的背景杂音所干扰，导致你难以判断应该做些什么。
确保部署脚本了解数据库的依赖项 —— 比较与同步工具能够了解数据库的依赖项，并且以正确的顺序生成相关的DDL、DCL与DML语句。但不是所有比较与同步工具都支持在生成的脚本中包含多个schema的内容。
结论：比较与同步工具能够满足这些必要需求中的一部分，但不是全部。脚本依然需要手动审查，而且在自动化过程中无法完成依赖。
建立一个数据库执行变更管理解决方案
数据库执行变更管理结合了对数据库对象强制使用版本控制的流程，并且基于版本控制库及当前环境的结构，在需要时生成部署脚本。
这种方式意味着“按需构建与部署”，意即部署脚本是在需要时才进行构建（生成）的，而不是作为开发过程的一部分。这种方式保证了有效地处理冲突、合并，以及外部进程产生的变更。
按需构建与部署
那么数据库执行变更管理解决方案又是如何应对相同的挑战的呢？
确保所有的数据库代码都被涵盖 —— 结构、用数据库语言编写的业务逻辑、引用内容、数据库权限等内容都被正确地管理。
确保以版本控制库作为唯一的信任源 —— 强制的变更策略能够阻止任何人在任何IDE（甚至是命令行）中对数据库对象进行更改，而不经过事先的签出与变更后的签入。这就保证了版本控制库在对象签入时始终于对象的定义相一致。
单一的流程强制了版本控制的实施
确保被执行的部署脚本在运行时能够正确判断环境状态 —— 按需（在准备执行前）构建（生成）部署脚本的方式确保了它完全了解当前的环境状态。
确保部署脚本能够正确处理与合并冲突 —— 在分析过程中使用基线比较，就能够了解变更的原因，并且能够简单地判断是否要将变更进行部署、或是对目标环境进行保护（即忽略该变更）、或是对冲突进行合并。
了解基线的分析
只为相关的变更生成部署脚本 —— 与应用程序生命周期管理（ALM）工具及变更管理系统（CMS）的结合保证你能够为每个变更分配一个原因，就如同你在基于文件的版本控制系统或任务管理系统中所做的一样。
确保部署脚本了解数据库的依赖项 —— 严密的分析与脚本生成算法确保了DDL、DCL和DML等语句能够根据数据库的依赖，以正确的顺序进行执行，包括了跨schema的依赖。
除了这些必需满足的需求之外，还存在着一些别的需求，例如对并行开发的支持、合并分支、与数据库IDE的集成，以及支持由数据建模工具生成的变更等等。无论你选择了哪种方式，都必须验证它是否能够处理这些需求。
对数据库组件的管理有着特殊的需求，因此对自动化流程来说是个极大的挑战。在距今较远的年代里，一年中通常只有几次发布，因此花费大量时间对数据库 部署脚本进行手动审查以及维护是常见的、也是情有可原的做法。现如今，随着对敏捷及更快的发布速度的需求不断增长，数据库管理必须成为自动化流程的一部 分。无论是编写SQL或XML脚本，或是使用简单的比较与合并工具，一旦在自动化过程中使用，都存在着低效或是高风险的问题。最有效的方式是实现。
更多开发者职位上
1)">1)">1" ng-class="{current:{{currentPage==page}}}" ng-repeat="page in pages"><li class='page' ng-if="(endIndex<li class='page next' ng-if="(currentPage
相关文章阅读DevOps成功的
08:20:00 论坛
　　将软件开发和IT运维团队整合到单一的DevOps组织可以带来更强大的软件开发项目交付能力，但两类团队的文化差异、以及缺乏有效的工具都会阻碍DevOps的成功。
　　越来越多的公司开始向DevOps模式转型，希望能更迅速地将越来越多的软件更新和修补程序交付到用户手上，而且能实现比传统模式更短的软件更新周期。
　　在持续的竞争压力下，能够更快发布软件产品的公司显然会拥有更强的竞争优势。
　　Gartner研究总监 Colin Fletcher 在2014 Gartner IT基础架构和运营管理峰会上表示，“它(DevOps)将决定你进军新市场或者推出新产品的速度”。Fletcher认为，新兴市场的竞争压力、适应新的计算平台，为产品增加新功能、提升能力，这些都是转向DevOps的理由。
　　传统的软件开发是一个人工过程，每一代产品从源代码到测试到发布的过程都会跨越组织内部多个相对分离的领域。虽然让开发人员、测试人员和其它岗位人员融合无间，消除相互之间的合作壁垒是DevOps的终极目标，但每个公司都会用不同的办法将DevOps付诸实现。
　　Gartner公司资深VM分析师Ronni Colville表示，开发人员和运营人员对于软件发布管理的看法完全不同。在软件开发人员眼里，软件是代码、功能和性能。然而，运营人员眼里的软件是致力于将代码数据传送到目的地的一个流程或者行为。如果能整合两方的看法，就能大幅精简流程，减少理解上的误差。
　　1.应对DevOps带来的文化冲击
　　平稳的文化过渡是让DevOps获得长期成功应用和增强发布软件产品的综合能力的关键。第一步是，明确DevOps的定义，调动开发和运营部门之间的协作，鼓励运营人员采纳软件开发方法，并利用云计算基础设施来完成真实的测试和代码部署。
　　在软件开发、测试、质量保证(QA)、集成、预生产和生产部署等方面的任何旧小团队必须打散，因为每个小团队都可能拖延开发周期并且带来不可预料的问题。
　　以上策略能更好地整合开发和运营人员，通过整合团队成员来产生效益。例如，在讨论运营解决方案或扰乱事后评估报告时应该邀请开发人员加入。相反地，应该邀请运营人员列席开发人员规划会议。让交叉组合的工作模式成为制度，可以让团队之间合作融洽，消除沟通不畅导致的延误或疏忽，使DevOps的推进更加有效。
　　这种文化上的改革并不容易。它需要公司提供统一的考核标准，以相同的形式衡量开发人员和运维人员的业绩。培养一种团队精神，让大家一起向一个共同的目标努力，而不再只是为了从前各自的狭隘的小团体目标。在这里有时可以运用岗位轮换或者知识共享的方法。Colville鼓励大家勇于尝试——尝试用创造性的新方法处理问题，谨慎应对风险，从失败中积累经验。
　　在Bob Jones 大学的案例里，开发和运营团队之间的文化差异成为巨大的挑战。
　　“从前我们的客户都没有好脸色”，Bob Jones大学IT运营总监Terry Worley表示，“我不得不拿着鞭子驱赶运营和开发人员，迫使他们在工作上认真地合作。我深有体会，文化差异是拦路虎，我要么坐着等死，要么就该去杀了它!”
　　Worley已经证明了文化变革的好处，他指出，在采用了优化后的DevOps模式完成两个项目之后，开发人员们就再也不想回到从前的传统软件开发模式了。
　　2.DevOps需要齐全的工具箱
　　想要超越文化的影响，组织还必须依靠各种 DevOps 工具。例如，开发人员编写代码需要工具、QA测试人员需要用工具完成新版软件的部署，环境准备、将新代码在测试系统和生产系统之间迁移也必须用到云资源调度工具。Fletcher表示，工具本身都不是问题，重要的是能够让各种工具互相配合，在软件的生命周期内提供支持。
　　当前在应用程序发布自动化工具市场已经存在众多的供应商。运营工具方面的供应商有BMC Software, CA Technologies Inc. 和 XebiaLabs Inc.等公司。软件开发工具方面的供应商包括IBM，Electric Cloud Inc.和Serena Software Inc。
　　关于开发人员工作流程、架构设计和软件发布工具方面的专业供应商也在不断涌现，这些供应商包括Atlassian, CollabNet Inc., Rally Software, ThoughtWorks Inc. ，OpenMake Software Inc.等公司。在评估这些新供应商时，应明智地预计到这些公司随时可能会被并购，其产品可用性和未来发展也会因此受影响——请记得在选择新的软件发布自动化产品时多留个心眼。
&copy 2004-.cn 渝B2-
手机IT专家网 .cn