友观察总第195期-DevOps通俗演义.pptxVIP

DevOps通俗演义总第195期主办 集团产品管理与文档工程部发布日期：2021.07.23瀑布开发流程的困境诞生意义瀑布开发流程是一个非常了不起的创意，因为它利用了不同团队的开发者们只在必须的时候才进行沟通的这个事实。当一个团队完成了他们的工作的时候，它就会和下游的团队进行交流并把任务进行往下传，如此一级接一级的传递下去，永不回首。困境来了贪婪的人们(客户)又开始提出更多的诉求。他们希望能够更多地参加到整个软件的开发流程中来，不时的提出他们的建议，甚至在很晚的时候还提出改需求这种丧心病狂的事情来。结果就是如大家有目共睹的事实一样，软件项目非常容易失败这个说法已经作为一个行业标准被人们所接受。数据表明超过50%的项目最终都是以失败告终的。更可悲的是，在当时看来，人们对这种情况是束手无策。DevOps是什么？DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。看完之后是不是一头雾水？这可能是刚接触到DevOps的第一反应。2009年，Patrick Debois（DevOps之父）在提出Dev和Ops概念时的主要目的是如何在运维工作中应用 Scrum 和其它敏捷实践，为的是促成开发运维合作（打破开发和运维之间的部门墙）。部门墙：传统的Dev 和 Ops 的关注点不同Dev的关注点是如何开发测试交付新的功能Ops的关注点是保证应用运行的稳定和高性能在价值流上游的 Dev 无法获得价值链下游的 Ops 的真实运行环境，因此无法提升交付质量。在价值流下游的 Ops认为价值链上游的 Dev 软件非功能质量不满足要求，因此阻止变更。瀑布/敏捷/ DevOps的演进和区别软件工程方法论从瀑布到敏捷，到目前的DevOps，都不是凭空演进出来的。敏捷的目的是为了打破产品和开发团队之间的部门墙，但是市场变化越来越快，充满易变性、不确定性、复杂性、模糊性。我们需要更快的交付和反馈，所以只打破产品和开发部门部门墙还不够，现在现在需要将开发和运维运营也打通。DevOps将给我们带来哪些改变?IT企业的开发和运维部门的运作模式是共享的运维团队，开发完成后的交付物，交给运维团队负责部署、发布和运维。DevOps推荐的多功能团队类似于图中虚拟运维组的形式，每个开发团队都有自己的运维人员（运维人员少的也要有共享的运维联络人）。这里的运维人员指的是一种角色，有些团队也有全栈工程师，开发测试兼运维。对于中大型的公司，还经常会有基础设施运维团队，提供基础设施即代码等平台化能力。未来随着云原生服务的发展，运维的角色会有更大的转变（打破部门墙的最高境界，干掉运维部门，一切运维服务都是云原生服务）。DevOps将给我们带来哪些改变?随着IT技术的不断发展，应用系统的建设经过单体应用、SOA应用、逐步走向微服务应用。微服务的实施必然要具备需求管理、代码版本管理、质量管理、构建管理、测试管理、部署管理、环境管理等全流程自动化工具链，以及开发部门与运维部门的深度协作。因此，DevOps是微服务实施的充分必要条件。DevOps将给我们带来哪些改变?从信息流转来看，DevOps包含了从需求管理到需求开发、代码管理、基础设施管理、持续集成、自动化测试、持续部署、持续发布和应用运维管理全流程。DevOps将给我们带来哪些改变?DevOps落地，研发交付的每个过程都离不开工具的支撑。传统的方式，是自己搭建零散的弱整合工具系统，比如我们用Gitlab来管理代码，根据企业的实际情况寻找合适的分支管理方法；我们用Jenkins来做持续集成；使用selenium来做自动化测试；使用ansible来自动化部署；使用chef或者puppet来管理基础环境等等。这种情况的问题一是系统完全需要自己维护，成本高，不稳定；问题二是子系统之间存在隐性墙，缺少数据共享/权限共享/系统交互等功能。目前大型金融以及互联网企业普遍采用强整合的统一DevOps平台。DevOps与虚拟化、容器、微服务微服务架构下，不同的工程师可以对各自负责的模块进行处理，例如开发、测试、部署、迭代。而虚拟化，其实就是一种敏捷的云计算服务。它从硬件上，将一个系统“划分”为多个系统，系统之间相互隔离，为微服务提供便利。容器就更彻底了，不是划分为不同的操作系统，而是在操作系统上划分为不同的“运行环境”(Container)，占用资源更少，部署速度更快。虚拟化和容器，其实为DevOps提供了很好的前提条件。开发环境和部署环境都可以更好地隔离了，减小了相互之间的影响。这也是DevOps为什么09年时不火，现在越来越火的一个主要原因之一。持续交付实施框架：能力演进地图云原生架构与DevOps的落地与转型，需要从团队