从敏捷开发到敏捷运维DevOps将带来革命

  categories:java资料, linux资料  author:

你听说过DevOps一词,或者听说过敏捷运维这个运动么?人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象,从而导致冲突和低效,因此DevOps应运而生。传统的工作流程中,开发和运维之间存在很多的沟通错位而造成部署上的问题,由此,DevOps理念应运而生。

【51CTO精选译文】如果你对IT管理感兴趣,尤其是对Web运维感兴趣,那么最近一定会注意到“DevOps”这一热词的出现。现在#DevOps标签频繁出现在微博客Twitter上,同时DevOps相关的技术交流聚会也在慢慢增多。

在许多方面,DevOps是一个集合性概念,指的是能够理顺开发和运维之间相互配合关系的任何事物(51CTO编辑注:在英文中,Developer指开发者,Operations指运维,所以DevOps一词本身含有开发+运维的意思)。但是DevOps背后的理念要比上述说法更深远。

什么是DevOps?

人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象,从而导致冲突和低效,因此DevOps应运而生。

正如李·汤普森(Lee Thompson)和安德鲁·谢福尔(Andrew Shafer)所言,在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。

相互冲突的动机、流程和工具导致了这面“墙”的存在
开发与运维之间的“混乱之墙”

以开发为中心的人通常认为,变化会带来回报。企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。

而运维人员则往往视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性,运维业务有理由对它说不。我们已经多次听到过如下统计数字:在所有宕机事件中有80%情况是源于自杀式的改变(根据51CTO之前进行的调查,很多时候,仅仅是给系统应用补丁就会造成生产服务器无法正常重启)。

开发人员和运维人员认识世界的方法,以及各自所处的角色,存在根本性的差别。他们都认为自己的做法是正确的。的确,孤立的来看他们都是正确的。

更糟糕的是,开发和运维团队通常处于公司组织架构的不同部分,通常具有不同管理者的和竞争关系,而且通常工作在不同的地点。

开发和运维团队通常处于公司组织架构的不同部分
开发与运维通常工作在不同的地点

让混乱之墙更坚固的还包括开发和运维工具之间的错位。看一下开发者要求和日常使用的常见工具,再看一下系统管理员,你会发现两者存在很大不同,开发人员没有兴趣使用运维人员的工具,反之亦然;而且两部分工具之间也不存在重要的集成。即使在某些工具类型上有一些重叠之处,使用方式也完全不同。

开发者要求和日常使用的常见工具
开发与运维常用工具的不集成

当应用程序变动需要从开发团队推向运维团队时,混乱之墙的存在则将变得更加明显。有人将其称为一个“版本发布(Release)”,有人则称其为一次“部署(deployment)”,但有一件事情是公认的,问题可能会随之而来。下图虽然是一个抽象化场景,但是如果你经历过这一过程,一定会感觉到它的真实性。

版本发布与部署
应用程序变动从开发到运维

开发人员把一个软件版本“扔”给墙对面的运维人员。后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本。他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是,他们重复在此前环境中已完成的工作;而糟糕的情况是,他们将引入或发现新的漏洞。

运维人员然后开始进行他们自认为正确的部署过程。由于开发和运维之间的脚本、配置、过程和环境存在差别,这一部署过程实际上也是首次被执行。当然,期间如果发生一个问题,开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题。而开发人员则会回应称该产品在他们的环境下运行良好,因此一定是运维人员在部署的过程中做错了什么。由于配置、文件存储位置和过程的不同,开发人员诊断问题也并非一件易事。

没有一个可靠的方式来把环境回滚到此前已知的正常状态。本来应该一帆风顺的部署过程最后变成一场救火行动,经过反复测试之后才让生产环境恢复到正常状态。

本来应该一帆风顺的部署过程最后变成一场救火行动
本来应该一帆风顺的部署过程最后变成一场救火行动

部署阶段已经非常明显的需要DevOps理念来解决问题,但需要DevOps的绝不仅仅是这一阶段。正如约翰·阿尔斯帕瓦(John Allspaw)所指出的那样,开发和运维之间的协作需求在部署之前就已存在,同时也会在部署之后的长时间之内继续存在。

DevOps所带来的好处

DevOps是一个非常强大的概念,因为它可以在众多不同层面上产生共鸣。

从开发或运维的一线人员的观点来看,DevOps可以让他们从众多烦恼中解脱出来。它虽然不是具有魔力的万灵药,但是如果你能够让DevOps奏效,则会节省大量时间,而且不至于打击自己的士气。显而易见,投入精力将DevOps落到实处,我们应该会更加高效、更加敏捷和减少挫败感。有些人可能会反驳称DevOps是一个遥不可及的目标,但这并非说我们不应该去尝试实现它。

DevOps会节省大量的时间
DevOps会节省大量的时间

对于企业来说,DevOps直接有助于实现两个强大战略性企业品质,“业务敏捷性”和“IT融合”。它们可能不是IT人士所担忧的事情,但是却应该获得掌握财政大权的管理者的注意。

IT融合的一个简单定义是,“企业渴望达到的一个状态,能够高效的使用信息技术来达到企业目标——通常是提高公司业绩或市场竞争力。”

通过从共同企业目标角度出发来校准开发和运维的职责和流程,DevOps有助于实现IT融合。开发和运维人员需要明白,它们仅仅是一个统一业务流程中的一部分。DevOps思想确保个体决策和行为应力求支持和改进这个统一的业务流程,无论你是来自哪一个组织架构。

DevOps有助于实现IT融合
DevOps有助于实现IT融合

业务敏捷性的一个简单定义是,“一个机构以高效、经济的方式迅速适应市场和环境变化的能力。”

当然对于开发人员来说,“敏捷”有专门的含义(参考51CTO开发频道的专题:初探敏捷开发),但目标是非常类似的。敏捷开发方法旨在保持软件开发工作与客户/公司的目标同步,尽管需求不断变化,也可以产生高品质软件。对于多数机构来说,迭代项目管理方法Scrum是敏捷的代名词。

Scrum
Scrum

业务敏捷性承诺,在企业权益集团作出决策和开发者进行响应之间能够紧密互动和快速反馈。看一下一家运转良好的敏捷开发团体的产品,你会看到一个与业务需求保持一致的稳定持续改进。

但是,当你从企业角度回顾一下整个开发-运维周期,敏捷方法的相关优势通常会变得非常模糊。混乱之墙导致了应用程序生命周期的分裂。开发和运维分别按照不同的节奏进行。实际上,产品部署之间的长期间隔使得一个团体的敏捷工作变成了它一直试图避免的瀑布生命周期。当存在混乱之墙时,无论开发团体有多么敏捷,改变企业缓慢和迟钝的特点是极其困难的。

敏捷开发与企业结构的不同步
敏捷的开发与瀑布式企业结构的步调不同

DevOps使得敏捷开发的优势可以体现在机构层面上。通过考虑到快速、反应灵敏但稳定的业务运维,使其能够与开发过程的创新保持同步,DevOps可以做到这一点。

如果你希望在自己的组织内建立一个DevOps项目,务必牢记“IT融合”

阅读全文

Spring事务管理中@Transactional的参数配置

  categories:java资料  author:

来源:http://blog.csdn.net/zsm653983/article/details/8103466

Spring作为低侵入的Java EE框架之一,能够很好地与其他框架进行整合,其中Spring与Hibernate的整合实现的事务管理是常用的一种功能。  所谓事务,就必须具备ACID特性,即原子性、一致性、隔离性和持久性

注意@Transactional 注解及其支持类所提供的功能最低要求使用Java 5(Tiger)。

除了基于XML文件的声明式事务配置外,你也可以采用基于注解式的事务配置方法。直接在Java源代码中声明事务语义的做法让事务声明和将受其影响的代码距离更近了,而且一般来说不会有不恰当的耦合的风险,因为,使用事务性的代码几乎总是被部署在事务环境中。

下面的例子很好地演示了 @Transactional 注解的易用性,随后解释其中的细节。先看看其中的类定义:

  1. <!– the service class that we want to make transactional –>
  2. @Transactional
  3. public class DefaultFooService implements FooService {
  4.        Foo getFoo(String fooName);
  5.        Foo getFoo(String fooName, String barName);
  6.        void insertFoo(Foo foo);
阅读全文

maven-shade-plugin对可执行java工程及其全部依赖jar进行打包

  categories:java资料  author:
现在基本上都是采用maven来进行开发管理,我有一个需求是需要把通过maven管理的java工程打成可执行的jar包,这样也就是说必需把工程依赖 的jar包也一起打包。而使用maven默认的package命令构建的jar包中只包括了工程自身的class文件,并没有包括依赖的jar包。我们可 以通过配置插件来对工程进行打包,pom具体配置如下:

maven-assembly-plugin (使用此插件会有一些问题)

Xml代码
  1. <plugin>
  2.     <artifactId>maven-assembly-plugin</artifactId>
  3.     <configuration>
  4.         <appendAssemblyId>false</appendAssemblyId>
  5.         <descriptorRefs>
  6.             <descriptorRef>jar-with-dependencies</descriptorRef>
  7.         </descriptorRefs>
阅读全文

TCP 系统调用序列

  categories:资料  author:

从内核到应用程序级别的函数调用序列

TCP/IP 编程接口提供各种系统调用,以帮助您有效地使用该协议。TCP 堆栈代码数量繁多,深入到内核级别的完整调用序列可以帮助您了解 TCP 堆栈。在本文中,将回顾和学习关于 TCP 调用序列的详细信息,其中包括对 FreeBSD 的引用,以及在用户级进行系统调用后在 TCP 堆栈中发生的重要函数调用。


引言

典型的 TCP 客户机和服务器应用程序通过发布 TCP 系统调用序列来获取某些函数。这些系统调用包括 socket ()bind ()listen ()accept ()send ()receive()。本文介绍在应用程序发布 TCP 系统调用时在较低级别中发生的情况,如图 1 所示。

阅读全文

Hadoop的SecondaryNameNode、CheckpointNode、BackupNode、HA、Federation

  categories:资料  author:

来源:http://www.mamicode.com/info-detail-670006.html

一、SecondaryNameNode

Secondary NameNode不是NameNode的备份。它的作用是:定期合并fsimage与edits文件,并推送给NameNode,以及辅助恢复NameNode。
SNN的作用现在(Hadoop2.x)可以被两个节点替换CheckpointNode和BackupNode。
CheckpointNode可以理解为与Secondary NameNode的作用一致。
BackupNode:NameNode的完全备份。
配置文件:core-site.xml
fs.checkpoint.period、fs.checkpoint,size、
fs.checkpoint.dir、fs.checkpoint.edits.dir

Secondary NameNode定期合并流程,如下图所示。
技术分享

[root@master current]# more VERSION
#Mon May 04 15:06:37 CST 2015
namespaceID=1967523381
clusterID=CID-bdf70043-346a-
阅读全文

智能机器人“入侵”教育:可以教孩子编程

  categories:资料  tags:  author:

Play-i是一个由三个圆球组成的机器人,顶上的那个圆球有一只大大的眼睛,两边的圆球底部则装有两个轮子,帮助它前进。从它偏向可爱的外型上可以看出,它主要的职责不是什么完成酷炫任务,而是帮助5岁以上的小朋友学习编程语言——配合一个iPad,小朋友就可以运用可视化界面进行命令编写,给它下达各个指令,比如操控前进方向、检测前方物体,甚至完成跳舞等复杂动作。在这个过程中,小朋友可以非常直观而又轻松地学会和实践编程。

是不是觉得很神奇?可能各个程序员们都恨不得马上生一个小孩来配合这个机器人了。但是,它并不是唯一的瞄准儿童教育的机器人创业公司。事实上,教育已经成为了各路智能机器人“入侵”的一个重要领域。在一个名叫Robo Madness的机器人论坛上,Play-i的创始人兼CEO Vikas Gupta就和另外两个同样专注教育/护理型机器人研发的创业者分享了他们的创意。

同样是针对小孩的机器人,Romibo又是完全不同的一个产品。它看起来更像是一个毛茸茸的玩具,只除了脸部由一个LED屏幕代替,可以显示自定义的五官和表情。它针对的更多的是需要特殊护理(比如患有自闭症)的小孩,用CEO Aubrey Shick的话来说,它是一个社交型机器人,是一个情感上的看护,或者说,是那些不愿意与人接触的孩子们的朋友。Romibo会用前置摄像头来捕捉动作,老师或者护理人员可以用iPad来远程控制它发出声音、四处移动等,从而配合他们进行日常的沟通和教育。Shick说,Romibo是想用最简单的方式,来给这些孩子提供社交联系。不过,他们现在主要还是和研究机构进行合作,下一步,他们要做的就是让它进到教室里,和老师或者治疗师一起给那些孩子特别的照顾与陪伴。

与上面两个针对低龄儿童的教育/护理机器人相比,Linkbot就显得极客的多,它甚至没有做成仿人或者动物的样子,而是方方的一块,机身都是各种接口,再配上可以自由拆卸的轮子或者支架。它的特色就在于它的无限拓展性,就像是乐高积木一样,可以让人自由组合,组件之间可以连接,或者分享行为,甚至让一个机器人控制另一个。你可以用几个Linkbot组合成一个大的机器人,或者配上附件,让它成为各种有想象力的模样。尽管样子看起来酷酷的,但是这同样不妨碍它的创始人Graham Ryland把它应用到教育领域。Ryland认为,Linkbot就是最棒的机器人玩具:它既降低了玩机器人的学习门槛,同时,只要孩子们想,就可以组建出非常复杂的结构。

尽管定位和产品形态都不一样,但是同样作为面向教育领域的机器人,三者还是有不少共性,或者说,面对他们的特殊用户——孩子,他们都呈现出了一样的特点。

首先就是有趣。Vikas Gupta称,他们重视的不仅仅是编程语言,更多的反而在于引导小孩子们怎么思考。比起传统的编程教学,这种互动式的探索和更像是在鼓励小孩子们创造和发现。“我们在这个过程中发现,有趣对于小朋友们而言是最重要的事情,他们不需要坐在那里看代码,而是玩着玩着就学会了。也许有人会觉得编程语言对于5岁的孩子太难了,但是你永远不要低估孩子们的学习能力。”Gupta说,因为所有的结果都会实时在机器人身上反应出来,这也绝对能够激发他们在玩乐中学习的兴趣。

其次还包括易用。不过,和你想象的不同,这个易用更多的是针对老师们,要让老师们很容易就学会操作,这比孩子们学会怎么玩甚至更困难。所有这三个公司都希望老师可以参与到他们的产品与孩子们的互动中来,或者说,让他们的产品走到课堂上去,所以,如何让老师可以轻松地在课堂上使用他们的技术,成为最大的难题。

“孩子们学的很快,但是老师们需要一点时间。”Ryland说,“总不能让老师们为了学会使用这些机器,还要去拿一个计算机的学位。”所以他们希望在软件上下功夫,尽量把操作做的简单,这让他们花在硬件和软件上的时间达到了一半一半。Shick则把希望放在了创造容易控制的交互界面上,Romibo就花了大量时间来简化UI设计,但是上面提到的那个问题,也并没有解决——也许孩子们可以很快和机器人相处,但是让老师们不看说明书就知道怎么用,还是太难了。“只要对于很多老师来说,这个不是自己可以学会的、而需要有人来教授,那它就不可能快速普及。”Shick说。

但是,一旦这些因素可以克服,机器人在教育领域的应用将具有非常大的想象空间,甚至你可以说,它将颠覆人类学习的方式。Romibo已经逐渐显现出这方面的能力——根据Shick的描述,在一间特殊学校里,他们就发现了不少让他们非常惊讶的事例。比如说,有一个不喜欢讲话的小男孩,几乎一天都没有怎么开口了,于是护理老师让Romibo跟着他,然后一直对他说,“嘿,你在干什么!”或者发出各种声音逗他笑。过了一阵子,那个看起来很沮丧的小男孩转身,给了一直跟着他的Romibo一个拥抱,再过一会儿,老师们就发现,小男孩已经在和Romibo小声聊天了。

即使是在传统教育方面,Ryland说的也没错,“我们需要让机器人走到教室里去。现在教育内容都数字化了,但是人们还是在用物理(physical)的方式学习——机器人将会要填平这个鸿沟。”… 阅读全文



快乐成长 每天进步一点点