下载掌阅APP，畅读海量书库
立即打开
2008年8月，在加拿大多伦多的敏捷大会上，就有了关于敏捷基础设施（Agile Infrast-ructure）话题的讨论，旨在探讨如何在运营工作中应用Scrum和其他敏捷开发模型。而2009年6月，在美国圣荷西的第2届Velocity大会上的一篇题为“10+Deploys per Day:Dev and OpsCooperation at Flickr”的发言证明了Dev和Ops可以有效协作来提高软件开发部署的可行性。2009年10月，在比利时根特的DevOpsDays会议上，Patrick Debois第一次提出了DevOps的表述。于是，DevOps这个称谓正式诞生。
在2010年之前，DevOps主要停留在社区讨论层面，并没有引起相关厂商的关注。直到2011年，DevOps才开始引起业界关注。而随着相关技术的发展，特别是云计算技术和基础设施的成熟，DevOps被业界快速接受，甚至涌现出新的架构范式。
事实上，DevOps需要构建一整套完整的工作流程，才能确保通过不断地适应需求变化来驱动软件的开发、部署、运行以及升级。其中，工作流程主要涉及以自动化流程、持续集成、持续交付、持续部署为基础的开发和运营等环节。具体来说，DevOps理念主要是由敏捷管理、持续交付、IT服务管理三大支柱和精益管理构成的
，如图3-8所示。
·敏捷管理：在DevOps流程中，敏捷开发团队能快速响应市场需求的变化，交付高质量的代码。在传统的软件开发模式下，产品迭代慢、项目周期长、问题发现滞后。在DevOps模式下，代码提交之后开发人员在很短的时间内就能得到反馈意见，并且各个流程之间相关人员紧密协作、高效沟通。
·持续交付：指软件自动构建、自动测试、持续部署、持续发布。传统的软件开发模式下，开发、测试、运营部门各自分立，导致部门间沟通少且不方便，容易出现软件开发推进缓慢、交付周期延长等问题。而DevOps模式旨在践行开发运营一体化，通过一系列工具实现高水平的自动化测试、持续部署，极大地缩短了开发周期，实现了高效交付。
·IT服务管理：IT服务的连续性和高可用性是业务生死存亡的两个关键因素。传统的IT服务管理（IT Service Management,ITSM）虽然是以流程为中心，但核心流程也是从传统的IT运营管理活动中梳理出来的，与DevOps所倡导的快速迭代不符。因此，我们需要基于DevOps理念重新调整ITSM，建立包含最少必要信息的、严格聚焦于业务持续性的轻量级ITSM。
·精益管理：精益管理需要转变传统观念。比如建立共享平台，公司的各个部门员工都可以借此共享信息，促进组织内知识体系的形成和相关知识的复用与学习，同时提升员工间的沟通效率，进而提高整体工作效率等。
图3-8 DevOps理念构成
为了更好地应对市场需求的快速变化，企业有必要在组织架构中建立DevOps团队。DevOps团队包含开发人员、运营人员、测试人员等，规模一般在6～20人。具体的团队成员角色描述如表3-1所示。
表3-1 DevOps团队成员角色
（续）
构建持续交付流水线主要包括可视化管理、项目规划、需求设计、开发测试、上线部署、运营维护等环节。
·可视化管理：流程主管需要了解如何对整个流程实现可视化有效管理。
·项目规划：项目主管统一规划项目的整体目标，再把整体目标细分成若干个小目标以便周期性实现，最终实现项目价值最大化。
·需求设计：DevOps开发团队在需求设计阶段需确定需求并对需求功能进行优先级排序。
·开发测试：开发团队按照开发安全规范、测试规范等进行敏捷开发，版本的迭代也要遵循规范要求。
·上线部署：在完成持续交付、持续集成后，流程进入自动化部署阶段。
·运营维护：运营团队贯穿整个项目的开发生命周期，不仅仅关注产品发布和上线。当系统出现突发问题时，运营团队能在第一时间做出有效补救措施，使损失降到最小。
DevOps的实现依赖于自动化，而自动化需要端到端、自动化的工具支撑。相关的工具主要用于软件设计与开发、项目开发与管理、持续交付和持续部署、自动化测试等。
·软件设计与开发：集成开发环境、应用框架等。
·项目开发与管理：包括工作项、计划、文档、团队协同等的管理。
·持续交付和持续部署：通过DevOps工具链最大限度实现自动化测试、快速发布和自动化部署。
·自动化测试：包括测试计划、测试用例、性能测试等。
收集企业内部现有系统的开发模式，对现有系统的交付方式进行剖析，总结罗列出需要整改的清单，对不同系统的交付方式给出不同的改进建议。
要想在竞争激烈的市场中脱颖而出，组织需要迅速行动，团队成员要勇于承担风险，还要以节约成本的理念去运营。当公司开始接纳DevOps时，安全文化也随之发生了变化，同样安全文化也必须融入DevOps，而这一切都要从聚焦客户开始。
DevOps有3种部署实施方式，即全量方式、协同方式及持续交付方式。不同企业可以根据自身情况选择适合的方式。
·全量方式：重点关注IT服务战略，比较适合IT服务提供商。
·协同方式：更加关注快速和频繁地提供可靠的IT服务，适合交互型系统（SOE）和记录型系统（SOR）共存的企业。
·持续交付：关注快速、频繁的迭代发布，适合开发数字产品的企业。
在各企业追求系统灵活高效且信息量不断膨胀的背景下，DevOps迎来发展机遇。可以确定的是，DevOps仍会发挥重要作用，并将在IT市场占据愈加重要的地位。从行业发展情况来看，DevOps的价值还未充分发挥，但是已经得到企业的认可。
DevOps的发展趋势介绍如下。
（1）自动化流程标准化
DevOps将开发和运营有效地结合了起来，其核心价值就是自动化，通过自动化流程使软件的构建、测试、发布和运营更加高效可靠。目前，大多数企业还处在工具、平台、服务、组件等相互独立的阶段，而且企业构建自动化流程会耗费大量人力、物力，因此将DevOps深度集成各种工具平台，制定一套全方位的自动化流程标准，实现真正意义上的流程自动化，会给更多的企业带来更高的价值。
（2）将安全嵌入DevOps工作流程
传统开发模式下通常认为业务功能需求优先于安全需求；且传统的安全保障是外挂式，即在软件开发、运营流程外，通过上线前的测试和上线运营过程中的安全监控保障软件产品的安全。在这种模式下，安全与软件开发是割裂的，相关人员在流程中有足够的时间进行安全操作。由于安全并不对客户直接产生价值，在敏捷开发模式下，外挂式安全活动经常被放弃。人们意识到敏捷开发下安全活动外挂的做法是不可取的，因此内生安全的概念在DevOps实践中被提出。DevSecOps的核心理念是将安全嵌入DevOps工作流程，通过在软件生命周期的不同阶段加入相应的安全活动或工具，赋能软件内生的安全性，有效保障软件的正常上线、发布和稳定运行，这将对快速的、安全的交付软件产生积极而深远的影响。
研发团队对外聚焦于用户，安全团队对内聚焦于自身环境。一方想提升组织的价值，另一方想保护现有的价值。对于一个健康的生态系统来说，二者都是不可或缺的，如果两者的目标没有达成一致，则会对沟通和开发效率造成很大影响。在安全变成DevOps不可分割的一部分之后，开发团队以及安全人员可以将安全控制直接内建到产品中，而不是事后强加到产品之上。每个人都要有安全意识与责任，将安全引入DevOps的核心思想就是让安全赋能整个团队，将注意力从保护基础设施转移到通过持续改进来达成整个组织的目标。
（3）架构低耦合性
在DevOps实践过程中，软件架构与持续交付有着密切关系。在DevOps开发模式下，使用低耦合架构会大大提高交付速度。在低耦合架构下，软件项目团队可以在不依赖关联组件的情况下修改各自所负责模块下的组件或者服务。微服务、容器化等新型技术会与DevOps实践结合起来，真正实现项目组件之间的解耦。