文档介绍：从敏捷开发到敏捷运维:DevOps将带来革命?你听说过DevOps一词,或者听说过敏捷运维这个运动么?人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象,从而导致冲突和低效,因此DevOps应运而生。传统的工作流程中,开发和运维之间存在很多的沟通错位而造成部署上的问题,由此,DevOps理念应运而生。如果你对IT管理感兴趣,尤其是对Web运维感兴趣,那么最近一定会注意到“DevOps”这一热词的出现。现在#DevOps标签频繁出现在微博客***上,同时DevOps相关的技术交流聚会也在慢慢增多。在许多方面,DevOps是一个集合性概念,指的是能够理顺开发和运维之间相互配合关系的任何事物(51CTO编辑注:在英文中,Developer指开发者,Operations指运维,所以DevOps一词本身含有开发+运维的意思)。但是DevOps背后的理念要比上述说法更深远。什么是DevOps?人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象,从而导致冲突和低效,因此DevOps应运而生。正如李·汤普森(LeeThompson)和安德鲁·谢福尔(AndrewShafer)所言,在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。开发与运维之间的“混乱之墙”以开发为中心的人通常认为,变化会带来回报。企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。而运维人员则往往视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性,运维业务有理由对它说不。我们已经多次听到过如下统计数字:在所有宕机事件中有80%情况是源于***式的改变(根据51CTO之前进行的调查,很多时候,仅仅是给系统应用补丁就会造成生产服务器无法正常重启)。开发人员和运维人员认识世界的方法,以及各自所处的角色,存在根本性的差别。他们都认为自己的做法是正确的。的确,孤立的来看他们都是正确的。更糟糕的是,开发和运维团队通常处于公司组织架构的不同部分,通常具有不同管理者的和竞争关系,而且通常工作在不同的地点。开发与运维通常工作在不同的地点让混乱之墙更坚固的还包括开发和运维工具之间的错位。看一下开发者要求和日常使用的常见工具,再看一下系统管理员,你会发现两者存在很大不同,开发人员没有兴趣使用运维人员的工具,反之亦然;而且两部分工具之间也不存在重要的集成。即使在某些工具类型上有一些重叠之处,使用方式也完全不同。开发与运维常用工具的不集成当应用程序变动需要从开发团队推向运维团队时,混乱之墙的存在则将变得更加明显。有人将其称为一个“版本发布(Release)”,有人则称其为一次“部署(deployment)”,但有一件事情是公认的,问题可能会随之而来。下图虽然是一个抽象化场景,但是如果你经历过这一过程,一定会感觉到它的真实性。应用程序变动从开发到运维开发人员把一个软件版本“扔”给墙对面的运维人员。后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本。他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是,他们重复在此前环境中已完成的工作;而糟糕的情况是,他们将引入或发现新的漏洞。运维人员然后开始进行他们自认为正确的部署过程。由于开发和运维之间的脚本、