DevOps对于企业IT的价值

其实从敏捷延展开的 DevOps 概念很早就已经被提出，不过由于配套的技术成熟度水平层次不齐， DevOps 的价值一直没有有效地发挥出来。现如今，随着容器技术的发展， DevOps 在企业中的实践难度大幅降低，其价值也得以体现。

1. DevOps概念的发展历史

现在是2016年6月初，DevOps 作为一个IT圈的热词，几乎已经是无人不知，无人不晓。

如果你是一个有心人的话，可能会好奇DevOps这个概念到底是在什么情况下诞生的。

在 Wikipedia: Devops[1] 的词条里，可以发现 DevOps 相关概念已经早在2008年就被提出了。

At the Agile 2008 conference, Andrew Clay Shafer and Patrick Debois discussed "Agile Infrastructure". The term "DevOps" was popularized through a series of devopsdays starting in 2009 in Belgium. Since then, there have been devopsdays conferences held in many countries worldwide.

即便是在2006年Amazon发布了ECS，微软在2008年和2010年提出和发布了Azure，DevOps 的重要性似乎没那么强烈。

可是在8年前的那个时候，为什么 DevOps 没有迅速走红呢，第一个很重要的原因是因为那时候云计算（ Wikipeida: Cloud computing[2]  ） 还是小众产品，更多地与虚拟化相关。 第二个很重要的原因是 Docker 还没有横空出世，直到2013年7月。第三个很重要的原因是，Martin Fowler 在2014年3月提出了 Microservices[3]  。

可以看出，当前 DevOps 概念的深入人心，离不开云计算、容器/Docker、微服务、敏捷等相关概念和实施的成熟发展。

2. 企业IT对于企业的价值

谈到企业IT，就没有办法回避两种迥然不同的企业，一种是以传统制造业或者服务业为基础的，对生产资料进行加工的「传统企业」； 另一种是以「信息互联」为基础的，对「人与人关系、人与物关系、物与物关系」进行信息加工的「互联网企业」。

这两类，是两类极端的企业，一类企业的日常运行，可以没有信息系统；另一类企业，完全离不开信息系统。

一般的信息系统，对于企业的价值，主要有三类渐进过度的典型类型。

第一类，是将信息系统定位于「辅助和支撑」企业的产品制造以及企业运营部门，因为这类企业的生产资料系、生产力、生产关，都以实体制造为主，不以信息加工和处理作为企业产品核心。

第二类，是将信息系统作为数据加工、传输作为主体，但业务模式来自于传统行业，信息系统主要完成已有业务规则的虚拟化，例如金融、电信行业。这类企业的信息或者数据，主要来自于业务受理，或者说数据的生产者和使用者是企业自身。

第三类，是将信息系统作为企业唯一生产工具，并将企业的客户（个人或企业）所自发贡献的信息、数据，作为生产资料，形成新兴的业务模式。这里企业的典型，就是互联网企业。

随着又一轮「数字化」的概念席卷全球，非互联网企业所面临的更多针对用户和客户的思考和探索，都需要有更快交付能力的信息系统进行支撑，这也是传统企业互联网化，打开企业边界围栏迈出的第一步。

3. DevOps对于企业IT的价值

通过前文的分析，可以看到，企业IT对于三类不一样的企业价值体现各有不同。

对于互联网企业，信息系统是企业产品的命脉，企业对于软件的价值观以及投资组合，对于其他两类企业要高出很多。

DevOps 的核心价值，是能够帮助企业快速交付变更，以便于快速响应企业对于市场的变化、用户的需求。

• 代码

• 构建

• 测试

• 打包

• 发布

• 配置

• 监控

以上7个过程，是 DevOps 站在软件生命周期平台化运营的视角，为企业IT所建立的一个「IT for IT / IT4IT[4]  」的业务平台。

如果说，软件开发、交付、运维是一个传统行业，那么 DevOps 就是映射了这个传统行业的一个软件平台。

通过 DevOps 可以助力企业软件交付的效率提升，帮助企业IT实现数字化运营。

可以用一句话定位以下三者在价值链上的关系：

「信息」（数据）

「信息系统」（处理数据的工具）

「DevOps」（制造与维护处理数据的工具的工具）

在「信息」（数据）成为企业「生产资料」一部分的条件下，信息系统快速演进的业务驱动力、DevOps的价值，才能够清晰地得以体现。

企业IT系统的从「业务支撑型」走向「业务驱动型」的转折点，是由企业产品的最终用户，直接以低成本为企业提供生产资料——信息（数据）——并使之成为企业产品的一部分 。

如果信息是企业产品的全部，那么这种类型的企业就是第三类——互联网企业。

4. DevOps在企业中的实践

和众多源于互联网的理念一样，在 DevOps 的概念被炒热之前，众多互联网公司其实已经实践了 DevOps 。 其中的原因也正是因为信息系统，是这些公司的生产工具，没有人比互联网公司的人更明白提高自身的办公效率，提高团队、企业的生产力，就是为提高企业产品的生产力进行有效的保障。

除了前文提的 DevOps 覆盖企业软件生命周期中的7个过程， DevOps 在企业落地过程中，传统企业或多或少都已经建设了一部分配套系统，尤其是AAAA与监控系统，其他的代码管理、持续集成工具也或多或少的有所积累。

DevOps 更多的是把IT服务产品化的平台，企业中的任何一个IT能力，都应当能够在 DevOps 中面向其用户提供自服务的能力。 

例如，系统的开发者，能够自主地在 DevOps 上联机分析生产环境的日志，而不必经过层层壁垒，一台台登录生产环境的主机，检索日志。 再例如，项目组的快速变更、员工的快速入职、离职，都应当能够在 DevOps 中实现自动化的账号开通和注销。

需要注意的是，相比传统企业尤其是制造业的产品制造工艺和制造流程，软件产品的制造，IT服务的交付，更多的是交付一些无形的软件产品和知识工作。 正因为这些无形产品受制于不同的人认知所产生的多变，其管理复杂度远比制造业来的复杂，企业软件的设计、开发、发布、上线，缺乏标准化的管理过程。

对于如今的非互联网企业而言，能够快速见效的 DevOps实践，应当从（环境）配置的管理，以及自动化部署。 在实施难度上，配置的管理要低于自动化部署。因为非互联网企业的技术路线由于供应商的竞争（甚至是恶意竞争），变得极其多样，架构离散化程度也很高。

对比互联网企业，（环境）配置管理和自动化部署，由于IT技术从硬件到虚拟化/容器的自主可控，企业整体技术架构的收敛性就比较理想。

5. 当前DevOps对于

企业架构支撑的不足

从 代码 到 监控 , 可以看出 DevOps 对于企业尚有以下不足（或者说 DevOps 本来就不考虑这些）:

1. 缺少对企业IT战略规划、企业IT业务架构规划、企业IT系统架构设计、企业IT系统需求管理以及IT项目管理进行有效的平台化、数字化支撑。

2. 缺少对企业IT部门、信息系统运营效能的系统性评估和优化模型。

3. 缺少对企业不同IT系统供应商的技术架构、IT产品的标准化、基线化管理。

4. 缺少对企业数据类应用的支撑，更偏于交易型应用的交付。

对于第 1,2 两点，任何企业都有这方面的需求，但由于企业在投资组合上对这个领域投资较少，投资规模较大、实施难度较大，企业主更愿意进行面向企业产品「开源」投资。

对于第 3 点，几乎不会在秉承「自主建设」互联网公司存在，但在其他企业中也逐步会通过精益运营的方式进行落地实施。

6. 参考资料

1. Wikipedia:Devops: https://en.wikipedia.org/wiki/DevOps

2. Wikipeida: Cloud Computing:https://en.wikipedia.org/wiki/Cloud_computing

3. Microservices:http://martinfowler.com/articles/microservices.html

4. IT4IT: http://www.opengroup.org/IT4IT

关于作者：

王延炯

EAII-企业架构创新研究院 专家委员

王延炯，现任普元信息主任架构师。密码学博士，毕业于北京邮电大学。曾先后任职于西门子(中国)研究院、垂直行业互联网公司。带领团队交付了移动、金融、电信等多个行业、众多IT系统的咨询、设计、研发、实施、维护、优化工作。对分布式架构，企业架构，以及企业IT平台化运营有深入的研究和理解。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，是专注于企业架构与业务创新领域的研究机构，致力于金融、电信、能源与政务等行业领域的企业软件架构优化设计与 创新研究，以及分布式计算、服务构件技术、可视化技术、业务流程管理、内存计算、企业移动计算、数据治理等领域的技术研究。