理解DevOps的基本原则、价值

什么是DevOps?

DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。

对DevOps出现的思考

DevOps的出现有其必然性。在软件开发生命周期中,遇到了两次瓶颈。

第一次瓶颈是在需求阶段和开发阶段之间,针对不断变化的需求,对软件开发者提出了高要求,后来出现了敏捷方法论,强调适应需求、快速迭代、持续交付。

第二个瓶颈是在开发阶段和构建部署阶段之间,大量完成的开发任务可能阻塞在部署阶段,影响交付,于是有了DevOps。

 

DevOps的基本原则

  在《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》的书里,描述了DevOps的支撑原则——“DevOps三个基本点”,所有的DevOps模式都可以源自这3个基本点。

  第一个基本点强调整个系统的性能,而非将性能局限于特定的工作领域里,这个工作领域可以大到一个部门(例如开发和IT运维)或者小到一个个人贡献者(例如开发者,系统管理员等)。

  重点是由IT推动的的业务价值流,换句话说,它始于需求定义(比如被业务或IT部门定义),进行开发构建,又交给IT运维,最后价值以一种服务的形式交付给客户。

  实践第一个基本点的结果——决不传递一个已知缺陷至下游,决不因小失大,总是致力于改进流程,执着于深刻理解系统需求(根据戴明的理论)

  第二个基本点是关于创建从右至左的反馈回路,几乎所有的流程改进计划的目标都是缩短和放大反馈回路,以便可以持续进行必要的修正。

  应用第二个基本点的结果——包括理解和回应所有内部和外部客户,缩短和放大所有的反馈回路,必要时,非常容易的嵌入客户需要的知识。

  第三个基本点是打造一种文化用来促进两件事情——持续不断的探索精神,勇担风险的精神以及从成功和失败中来学习的能力,同时也得谨记:重复和实践是融会贯通的前提。

  这两件事情对我们来说同等重要,探索精神和勇担风险的精神可以确保我们持续改进,它甚至意味着我们可能到达了之前曾未到过的危险区域,因此这也迫使我们去学习,掌握并融会贯通那些技能,因而使得我们能够顺利离开危险区。

  第三个基本点的结果——分配时间去改进每天的例行工作,培养一种奖励冒险精神的风气,同时主动引入故障到系统中,从而提高弹性。

DevOps模式的应用领域

  在《DevOps Cookbook》里,将DevOps模式分成4个领域,

  领域一:将开发延伸至生产中——包括拓展持续集成和发布功能至生产,集成QA和信息安全至整个工作流,确保代码和环境可在生产中直接部署,。

  领域二:向开发中加入生产反馈——包括建立开发和IT运营事件的完整时间表用于帮助事件的解决,使得开发融入无指责的生产反思,尽可能使得开发可以自助服务,同时创建信息指示器用来表明本地的决策如何影响全局的目标。

  领域三:开发嵌入到IT运维中——包括开发投入到整个生产问题处理链,分配开发资源用于生产问题管理,并协助退回技术债务,而且开发为IT运维提供交叉培训,增加IT运维处理问题的能力,从而降低升级问题的数量。

  领域四:将IT运维嵌入至开发——包括嵌入和联络IT运维资源至开发,帮助开发创建为IT运维(部署,生产代码的管理等)使用的可重用的用户故事,定义一些可以被所有项目共用的非功能性需求。

DevOps的价值

  企业在应用了DevOps之后可以得到3个业务优势:产品快速推向市场(比如,缩短开发周期时间和更高的部署频率),提高质量(比如,提高可用性,提高变更成功率,减少故障,等等)并提高组织的有效性(比如,将时间花在价值增加活动中,减少浪费,同时交付更多的价值至客户手中)。

 

理解DevOps的基本原则、价值_第1张图片

1、基础设施即代码(Infrastructure as Code)
DeveOps的基础是将重复的事情使用自动化脚本或软件来实现,例如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等。


2、持续交付(Continuous Delivery)
持续交付是在生产环境发布可靠的软件并交付给用户使用。而持续部署则不一定交付给用户使用。涉及到2个时间,TTR(Time to Repair)修复时间,TTM(Time To Marketing)产品上线时间。要做到高效交付可靠的软件,需要尽可能的减少这2个时间。部署可以有多种方式,比如蓝绿部署、金丝雀部署等。


3、协同工作(Collaboration Culture)

开发者和运维人员必须定期进行密切的合作。开发应该把运维角色理解成软件的另一个用户群体。协作有几个的建议:1、自动化(减少不必要的协作);2、小范围(每次修改的内容不宜过多,减少发布的风险);3、统一信息集散地(如wiki,让双方能够共享信息);4、标准化协作工具(比如jenkins)

 

你可能感兴趣的:(DevOps)