1.2.3　DevOps

房屋装修是一个大工程，操作过程中的工序环环相扣，泥工、水电工、木工、漆工等角色依次进场，不能像赶场一样一股脑地都冒出来，而且各角色只需要关注自己的工作即可。传统软件研发项目与装修房子类似，也有很多工序，几个关键岗位，如需求、开发、测试、运维依次参与，大多数时候是串行作业，每个岗位同样只关注本阶段的相关任务。

传统软件研发项目的这种研发模式在业内有一个专业名词，即瀑布模式。从需求分析开始，直到产品发布，开发过程从一个阶段“流动”到下一个阶段；这也是“瀑布”名称的由来。这种模式的优势是各阶段任务划分比较清晰，输入输出物定义较为规范，软件的更新频率较低，甚至是以年为单位进行更新，各阶段、各角色的人员都有相对充裕的时间来消化任务。

瀑布模式软件开发过程如图1-3所示。

由于迭代周期较长，瀑布模式对客户需求的响应速度自然快不了。这在21世纪初及以前倒也没什么问题，平均一年发布一个版本很正常。可是随着用户对软件的依赖度越来越高，用户需求越来越迫切，特别是随着互联网和移动互联网的蓬勃发展，传统软件研发模式下的迭代效率已经满足不了业务需求。IT管理与研发模式也进入新阶段，针对软件研发过程最耗时的环节出现了一系列优化措施，敏捷研发就是其代表，敏捷模式也逐渐成为潮流。

缓慢而烦琐的瀑布开发逐渐转变成敏捷研发，每个版本的迭代周期通常是1～4周，多数情况下约为两周，整个研发团队（敏捷战队）要在这么短的时间内完成该版本规划的各项任务，包括需求分析、系统设计、编码实现、功能自测、测试验证以及发布部署等。每个迭代周期都需要开发、质量、运维等团队的通力合作，但每个角色的关注点可能并不一致，开发团队希望更快交付，运维团队想要稳定运行，质量团队则焦急地等待构建部署以便开展测试验证工作，如果不同角色间的协作未能理顺，团队里每个人都可能充满怨气。因为不管是Scrum、XP、水晶还是精益等，这一系列的敏捷方法给研发过程带来了敏捷，但对运维方面的关注不够。

与传统开发方法大规模、不频繁发布（通常以“季度”或“年”为单位）相比，敏捷模式通常也大大提升了对发布频率（以“天”甚至“小时”为单位）的要求，而在很多企业，应用程序发布又是一项涉及多个团队、风险很高、压力很大的活动。快速迭代意味着产品需要频繁地部署上线，这也意味着研发、测试、运维团队必须克服这种频繁上线带来的诸多问题：研发质量低，测试不充分，上线后Bug层出不穷，运维上线部署慢、跟不上研发的节奏，经常由于环境、配置等问题导致应用不能正常提供服务等。一方面公司希望将产品快速交付给用户，另一方面如果体系不完善，技术人员压力会很大，毕竟发布越快越频繁，出问题的概率也越高。

为了解决上述问题，DevOps闪亮登场。自2009年DevOps概念被提出到现在，仍然没有一个准确的定义（一直在变化），甚至DevOps之父本人也反对将DevOps理论化、模型化，而是坚持DevOps的实践性和灵活性。那么DevOps具体能做什么，或者说做了什么？讲得直白些，DevOps就是应对产品研发过程中各团队交汇处的工作，让各团队能集中精力做他们自己的主业，如图1-4所示。

可能有读者会想，ITIL能不能发挥作用呢？ITIL能够发挥一定作用，变更管理和发布管理在ITIL中也是最重要的管理流程之一，只不过ITIL理念重点围绕的是规范化流程，虽然听起来模块名称里都带着服务，其实其后最硬核的都是流程，强调的是流程优先，照章办事，因此对于传统频度的跟进和推动会比较适应，但对于周期短、要求快速响应的场景，若流程过于复杂的话，可能就很难适应了。这个时候，DevOps就能派上用场了。从接触到的实际情况来看，需求的紧迫/强烈程度才是DevOps最大的推动力。触发此需求可能是为了提高效率，也可能是为了优化内部流转的流程，甚至可能只是为了提升科技团队对外的形象。当然，不同需求带来的效果也不一样。

真正想落地DevOps的公司多半会有这样的特点：业务发展不错，科技团队响应业务需求压力比较大，希望引入DevOps来提升科技团队的运作效率，以支撑迅猛发展的业务。但真正能使DevOps落地的企业，往往是其研发或运维人员都面临较大的工作压力，人少、事多、时间紧、任务急，IT团队不得不想尽办法提高效率。对于服务器数量上了一定规模的企业，部署这件看起来不起眼的“小事儿”也会演变成一件很麻烦的事情，尤其对存在多机房、多套环境的场景，部署的难度更是提升了许多。

DevOps倡导采用自动化基础设施、不向下游传递缺陷、自动化部署、快速试验等思维和方法来加强开发、测试、运维人员间的沟通与协作，通过自动化手段实现对业务需求快速迭代、快速响应，在提升部署效率的同时也能提升交付的质量，还能通过自动化手段，在面对软件研发及交付过程中的各个环节，包括环境初始化、编译构建、代码检查、安全扫描、自动化测试、发布部署等过程，统统一键触发，自动化执行，有效降低人工操作或等待人工操作的时间，全面提升研发交付过程的自动化水平。

这初听起来像是持续集成和持续部署，但两者是不同的。持续集成和持续部署的重点是自动化交付，而DevOps则是一系列自动化解决方案，可以说持续集成只是DevOps的一个子集。除此之外，从工具层面来看，DevOps还囊括版本管理工具、项目管理工具、基础设施云管理平台、监控系统、性能分析工具、批量运维工具、日志分析工具等。换句话说，当你在推行自动化，并开始使用各种自动化工具时，就已经走在DevOps的康庄大道上了。

DevOps通过自动化的过程管控，让开发、质量、运维等不同角色之间的沟通协作更加顺畅，使得各相关方像齿轮一样嵌入一个不断循环的流水线中，能够快速、安全和高质量地执行软件开发、测试和发布部署，可靠、高效地交付应用软件，如图1-5所示。

基于DevOps的交付过程便于包括代码检查、安全扫描、单元测试、集成测试等环节的落地，研发交付质量的检测从原有的保障部署结果（是否成功）延伸到源码质量检查、代码安全审计、测试覆盖度等过程，从而实现从源代码编写到发布部署全过程的质量检查与提升，使交付版本的质量得到更好的保障。整个过程尽可能减少人工干预的环节，既能够提高效率，又能有效降低误操作的概率。

基于DevOps平台，也便于建立能效管控体系，针对敏捷研发过程中的需求分析、开发、测试、发布部署及线上运营等过程，建立数字化度量模型；针对重点指标建立评价指标，从而实现自动化的技术管控。在此基础之上，结合一定的制度管控和数据分析，打通交付过程的持续优化，这中间既包括DevOps平台的优化，也包括研发交付流程、标准规范等方面的优化。

正如前文所讲，随着时间的推移，DevOps的内涵也在不断丰富，从最初“一组过程、方法与系统组合的统称”，发展为“一套集文化理念、实践和工具于一身的体系，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和管理基础设施流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争[1]”。

DevOps体系本身系统化、整体性的设计思想，既包括软件全生命周期的系统化考虑，也蕴含IT管理过程中的多方诉求，DevOps与敏捷开发的天然互补，无形中契合追求快速迭代的互联网模式。DevOps能够推动企业自身效率不断提升，通过运用新的理念和工具持续优化组织架构和流程，不断进行自我改革和创新，从而进化成为敏捷型组织，这也是DevOps获得越来越多企业青睐的真正原因。

[1] 可参考《什么是DevOps？》，https://aws.amazon.com/cn/devops/what-is-devops/。