我们来思考一个问题，我们为什么要关注DevOps，它能为我们带来什么？

第一个原因是，DevOps已经被证实能在IT和商业两方面提升效率和质量。

在Puppet实验室发布的DevOps调查研究报告中，指出使用了DevOps的团队和没有使用DevOps团队对比，部署更改频率提高30倍，交付周期缩短200倍。在问题质量方面，和其他组织相比，问题故障减少了60倍，在问题恢复上快了168倍。

第二个原因是，DevOps能让你的日常工作变得更简单，让你的工作节奏更加稳定可持续，让你的工作变得更有价值。

DevOps的目标简单来说就是帮助产品研发团队可持续的又快又好的交付价值。

“可持续性”是指以比较稳定的节奏长期的持续进行交付，比如经常加班赶工就是不可持续的，团队的交付速率也不稳定，波动性越大，风险越高。

“快”是指研发效能提升，具备按时可预测交付的能力。

“好”是指研发质量提升，减少缺陷和返工，降低成本，提升用户体验。

“交付价值”是指通过持续的频繁的迭代交付可用的产品，经过市场和客户的检验，持续的将问题和建议反馈给产品开发团队，进而对产品的功能的演进方向调整，使最终交付的产品更符合用户需求，最大化交付价值。

DevOps将给我们带来哪些改变？

DevOps落地由于涉及的内容非常多，所以不同的角色以不同的视角看，基本就是横看成岭侧成峰，远近高低各不同。我们从不同角度和层面来看看DevOps将会带来哪些改变？

从人员管理层面看：

从上图可以看出，DevOps落地后，人员管理的组织结构会有变化。目前大多数传统IT企业的开发和运维部门的运作模式是共享的运维团队，开发完成后的交付物，交给运维团队负责部署、发布和运维。DevOps推荐的多功能团队类似于图中虚拟运维组的形式，每个开发团队都有自己的运维人员（运维人员少的也要有共享的运维联络人）。这里的运维人员指的是一种角色，有些团队也有全栈工程师，开发测试兼运维。对于中大型的公司，还经常会有基础设施运维团队，提供基础设施即代码等平台化能力。未来随着云原生服务的发展，运维的角色会有更大的转变（打破部门墙的最高境界，干掉运维部门，一切运维服务都是云原生服务）。

看完组织结构的变化，再来看技术架构的演进。从技术架构层面看（以Java Web应用为例）：

随着IT技术的不断发展，应用系统的建设经过单体应用、SOA应用、逐步走向微服务应用。微服务的实施必然要具备需求管理、代码版本管理、质量管理、构建管理、测试管理、部署管理、环境管理等全流程自动化工具链，以及开发部门与运维部门的深度协作。因此，DevOps是微服务实施的充分必要条件。

从信息流转层面看：

从信息流转来看，DevOps包含了从需求管理到需求开发、代码管理、基础设施管理、持续集成、自动化测试、持续部署、持续发布和应用运维管理全流程。

从工具使用层面看：

DevOps落地，研发交付的每个过程都离不开工具的支撑。传统的方式，是自己搭建零散的弱整合工具系统，比如我们用Gitlab来管理代码，根据企业的实际情况寻找合适的分支管理方法；我们用Jenkins来做持续集成；使用selenium来做自动化测试；使用ansible来自动化部署；使用chef或者puppet来管理基础环境等等。这种情况的问题一是系统完全需要自己维护，成本高，不稳定；问题二是子系统之间存在隐性墙，缺少数据共享/权限共享/系统交互等功能。目前大型金融以及互联网企业普遍采用强整合的统一DevOps平台。