3.2.1　DevOps体系的发展方向

关于DevOps，我们会听到各种声音：DevOps就是研发人员要懂运维，DevOps就是自动化运维，DevOps就是敏捷开发，DevOps就是一种理念。站在不同的角度，大家对DevOps的解读确实仁者见仁、智者见智。

我们引用百度对DevOps的定义。

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（Quality Assurance，QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

图3-2　DevOps交集图

DevOps的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。DevOps是软件工程、技术运营、质量保障3者的交集，如图3-2所示。

传统的软件组织基本都是按照职能划分的职能型组织。项目管理、软件开发、测试、运维都是不同的职能部门，负责软件生命周期的某一项垂直环节。大部分软件的编码迭代是由开发工程师主导，但是上线发布及线上问题的运营工作往往交给了运维人员。

垂直的分工方式并非不好，而是当高频的发布与部署出现时，明确的局部分工反而会降低组织整体生产力。当发布从每周2次到每周上百次、上千次时，很难保证流水的线式发布能够正常高效，某个重要的需求可能会导致测试或运维资源吃紧，进而影响项目整体的吞吐量。同时，由于不同部门的组织目标不一致，因此会导致“组织深井”更加明显，从而减慢了IT交付业务价值的速度。

在DevOps模式下，开发团队和运维团队都不再是孤立的。有时，这两个团队会合并成为一个大团队，工程师会在应用程序的整个生命周期内紧密协作，开发出一系列不限于单一职能的技能。有的公司可能不会做组织的调整，但是会重新定义职责和岗位，让开发工程师具备开发、质量、运维的意识，除了开发代码外，还要自己做单元测试，甚至自测回归，最后自己上线发布、线上验证。线上问题也是开发工程师第一时间收到报警，根据日志、链路追踪等工具定位分析问题，重新修复问题并上线。

所有的问题都交给开发工程师做了，那运维工程师和质量工程师做什么？我们可以看到，开发工程师的职责变大的前提是他们有了更多工具和平台。如同前两年非常火的中台一样，一线的“士兵”可以随时呼唤炮火，这些炮火是怎么来的呢？往往就是由DevOps团队或者运维质量工程师构建的。当年，阿里进行DevOps调整时，原来的技术保障团队全部开始学习编程，后来转战阿里云，最终成就了今天面向中小企业的优秀基础设施。

DevOps看起来大大缩短了软件开发的周期，我们来分析一下它有什么优势。

（1）快速交付

DevOps模式使开发工程师拥有更多的工具和自主权，可以更快捷地完成开发、测试、部署、验证等工作。相比于传统开发模式下的跨团队沟通和多层审批，整个过程降低了许多不必要的冲突和沟通噪声，变得非常扁平，进而大大提升了交付速度。

（2）快速运维

之前线上故障的修复链路是一线业务人员发现问题并通过即时通信工具找到开发工程师，开发工程师再找运维团队去定位和修复。这样的沟通路径和修复链路很长，同时会存在沟通不到位的情况。

在DevOps模式下，丰富的工具会让线上问题的暴露更加提前，定位问题和修复问题也更加及时，线上版本的发布与回退也更加便捷。开发工程师可以随时拉一个Bugfix分支快速自测上线，不用因等着多方审批而“贻误战机”。

（3）更高的质量

近几年，比较热的一个词是“质量左移”。在DevOps模式下，开发工程师能够更早地在上线前做用例验证、安全验证、灰度验证、AB测试，这样一来，线上的产品问题会更早地暴露在测试环境中或上线前，相当于运维的工作前置或左移，这样的模式能够大大提高产品质量。

（4）团队协作

DevOps其实更是一种文化，这种文化强调Owner意识，打破组织的束缚，开发团队和运营团队更加密切地合作，共同承担责任，将各自的工作流程相互融合。这有助于减少效率低下的工作，同时节约大家的时间。

DevOps的种种优势，使其逐步成为各个互联网公司争相采用的一种模式。