DevOps的三步工作法
我们先回顾在管理和技术领域里所发生的几个重大事件，了解它们怎样为DevOps的诞生奠定了基础的。同时，我们还将介绍“价值流”这个概念，解释为什么DevOps是把精益原则应用到技术价值流中的结果，并探讨DevOps的三步工作法：流动、反馈以及持续学习与实验。
第一部分包括以下内容：
> 流动原则：DevOps加速了从开发、运维到支付给客户的流程。
> 反馈原则：DevOps使我们能建设出更安全可靠的工作体系。
> 持续学习与实验原则：DevOps打造一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。
DevOps的简史和演变
DevOps和它所产生的技术、架构及文化实践，体现了哲学和管理学原则的融合。虽然说这些原则是由不同组织独立发生的，但DevOps博采众长，展现了人们思想上的惊人进步和不可思议的相互关联。基于制造业实践了数十年的管理经验，它是将可靠行组织、信任度管理与DevOps实践相结合的产物。
DevOps基于精益、约束理论、生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了搞新人管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合底应用到IT价值中，就产生出DevOps这样的成果。将它贯彻于整个技术价值流中,涉及产品管理、开发、QA、IT运维和信息安全专员等不同角色,在更低的成本和努力下,保障产品的高质量、可靠性、稳定性和安全性。
虽然 DevOps是精益原则、约束理论和丰田套路运动的衍生物,但也被许多人视为始于
2001年的敏捷运动的延续。
“DevOps是一组过程、方法与系统的统称”，但我们也不用拘泥于概念，因为每年DevOps权威组织对DevOps的定义或者对DevOps所关注的重心都在发生变化。
我们来看看DevOps定义的发展变化：
2008年，还没有人提出这个DevOps名词，只是强调需要敏捷架构。
2009年，DevOps第一次被提出来，被定义为开发运维一体化。
2010年，DevOps的概念被明确为“一组过程、方法与系统的统称。用于促进开发、技术运营和质量保障之间的沟通、协作与整合”。
2011年，DevOps被定义为“一种强调Dev和Ops之间沟通合作的文化、运动或惯例”。通过自动化式的交付与变更流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
2016年，DevOps被定义为旨在统一开发和运维的一种软件工程文化和实践。目标是
> 与业务目标保持一致
> 更短的开发周期
> 更高的部署频率
> 更可靠的软件发布
2017年，兴起的DevOps运动，强调了DevOps的重心——“将软件建设的所有环节进行自动化&全面监控”。
通过收集和监控各个组件、各个过程的执行数据，提供直观的精益看板进行展示，作为企业持续改进的依据，能帮助企业发现目前项目或研发团队存在的问题，持续改进DevOps团队生产和交付，最大化体现DevOps的价值。
精益运动
价值流映射、看板和全面生产维护这些实践起源于20世纪80年代的丰田生产系统。1997年精益企业协会开始研究如何将精益理念应用于服务业和医疗行业等其他价值流中。
精益的两个主要原则包括:坚信前置时间(把原材料转换为成品所需的时间)是提升质量客户满意度和员工幸福感的最佳度量指标之一；小批量任务的交科是缩短前置时间的一个关键因素。
精益原则聚焦在如何通过系统性思考为客户创造价值,系统性思考的范围涉及建立持久目标,拥抱科学思维,创造流和拉动(而非推送)的协作模式,提倡从源头保证质量,以谦逊为导间尊重流程中的所有个体。
敏捷宣言
敏捷宣言是在2001年由软件领域的17位顶尖大师共同提出的。他们希望用一套轻量级的价值观和原则体系,来优化那些沉重的软件开发流程(如传统的瀑布式开发模型)和方法论(如统一软件开发过程)。
在敏捷宣言中,一个重要的原则是“频繁地交付可工作的软件,交付周期可以是数星期也可以是数月,推荐更短的周期”,并强调用小批量任务进行增量发布,而非大规模的作业和布流程的发布。同时,强调建立自组织的小团队,让成员在高度信任的环境中愉悦地工作。
在很多实施了敏捷的企业里,生产效率显著提升,敏捷也因此获得了越来越广泛的支持和认可。有趣的是,在 DevOps的发展历程中,如下所述的几个关键活动都发源于敏捷社区或者敏捷大会。
DevOps相关资讯热线
