导语

DevOps诞生已经13年了，你理解他吗？

为什么相伴了13年，你仍然对他不甚了了呢？

你真的以为DevOps是一个筐，什么东西都可以往里装吗？

你以为DevOps落地就是找一个JIRA（敏捷管理工具）+ CICD吗？

DevOps的未来又会是什么样子？

今天，就跟大家聊一聊DevOps，力图跟大家聊清楚如下两个问题，希望聊完之后，你对上面的问题有更明确的看法。

· DevOps是什么？

· DevOps的未来又是什么样子？

至于，DevOps如何落地，限于篇幅，咱们今天不聊。

DevOps是什么？

1) DevOps的历史

先讲一个故事。1908年，有人曾经问过基辛格：“基辛格先生，您可以解释一下昨天波斯尼亚所发生的事件吗？”基辛格先生回答：“哦，是这样的。这要从1722年谈起。”

为什么基辛格要扯那么久远的事？因为历史是一串连锁反应的事件，要想理解后来发生的事情，必须理解由一连串历史事件所形成的背景。

这叫历史观。

同样，我们理解DevOps，也需要从历史来看他，咱们直接上图来了解DevOps的诞生和发展。

大概用文字说明一下：

2007 年：

一切始于 2007 年，当时Patrick Debois开始负责数据中心迁移工作。在这个项目的过程中，他经历了很多挫折，从问题的开发端不断来回切换，到运维端等待的一堆操作。他意识到，在将项目从开发转移到运维过程中花费了（或者更确切地说是浪费了）大量的精力和时间。然而，弥合这两个世界之间巨大的鸿沟是不可能的。

2008 年：

2008 年在加拿大多伦多举行的敏捷会议上，一位名叫 Andrew Shafer 的人试图安排一场名为“敏捷基础设施”的聚会。Patrick参加了这次会议，他很兴奋终于遇到了一个志同道合的人。他在会议上找到Andrew，并在走廊上与他交谈。后来，他们继续为各种想要发表想法的人组成一个讨论组，这些想法将有助于为开发和运维之间的巨大差距带来相关的解决方案。

2009年：

在最初阶段，并没有多少人从这个角度提出他们的想法。然而，事情在 2009 年 6 月开始好转，Paul Hammond 和 John Allspaw 举办了一场题为“每天部署 10 次以上：Flickr 的开发和运维合作”的演讲。Patrick在比利时的家中，观看了该演示文稿的流媒体视频。它的观点引起了他的高度共鸣，使他意识到这正是他一直在寻找的解决方案。受这次讲座的启发，他安排了一次系统管理员和开发人员的聚会，他们坐在一起讨论开始弥合这两个不同领域之间鸿沟的最理想方法。该活动名为 DevOpsDays，于 2009 年 10 月的最后一周举行。

2010 年：

由于这一事件引起了这两个领域专家的极大关注，因此在用户使用#DevOps 标签的 Twitter 上进行了热烈的辩论。到这个时候，DevOps 成功地获得了起初的追随者，成员们开始广泛地推动他们各自的想法。

2011 年：

2011年 3 月，Gartner 的 Cameron Haight 预测 DevOps 将在接下来的几年中上一门课程。凭借他积极的态度，许多其他成员和用户纷纷涌入并开始实施具有广泛想法的 DevOps。很快，企业无论规模大小都开始采用 DevOps。DevOps 是工作区中最内部的框架之一，并且开始采用这些新实践。随着 DevOps 的名气越来越大，它是一个类似于 Agile 的东西。

2015 年：

纳入 SAFe 的 DevOps SAFe 在企业领域迅速获得关注，DevOps 在其中得到采用和扩展。

2016 年：

DevOps 是高绩效公司的新规范。

2018 年：

DevOps 状态报告定义了从 0 级到 5 级的 5 阶段方法，引入了一种描述性、务实的方法来指导团队执行 DevOps 计划。

其实，要更详细了解DevOps，需要了解DevOps诞生之前的历史，也就是软件工程的历史，从机器语言、编译语言、高级编程语言、面向过程开发、面向对象开发，从瀑布模型到敏捷，特别是理解瀑布模型和敏捷。限于篇幅，我这里就不详细谈了。

2) DevOps的本质

由DevOps诞生的历史，我们可知，DevOps的出现就是为了解决Dev团队和Ops团队之间的鸿沟。那么，他们之间的鸿沟是什么呢？Dev要快，Ops要稳。具体来说，Dev要求变更快，包括（开发快、测试快、上线快），而Ops要求稳，他们讨厌变更，因为生产环境不稳，他们要负责任。所以，很多大公司上线需要各种审批，各种签字画押，这都是在给变更增加障碍。

我们再给这个DevOps定个性——DevOps的出现，是为了解决一个软件工程领域的不同部门（或角色）之间的协作问题。

这里可能你会有另外的问题：

为什么不需要解决产品经理、开发人员、测试人员之间的协作问题？

答：需要解决。但已经有了解决方案——敏捷（Agile）。敏捷是解决产品经理、开发人员、测试人员协作的框架，但把Ops给落下了。所以，从这个角度上讲，Devops是敏捷的增强版，DevOps = Agile Pro。

敏捷的核心又是什么？

答：敏捷的核心是：需求小颗粒度（story）交付 + 快速反馈。其实做好敏捷本身，比消除Dev和Ops团队之间的鸿沟重要得多，强烈建议读者好好学习一下敏捷。

我们再来看一下DevOps在维基百科上的定义，英文版本和中文版本对照一下：

· 英文版：DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary to agile software development; several DevOps aspects came from the agile way of working.

· DevOps 是一组结合了软件开发 (Dev) 和 IT 运营 (Ops) 的实践。 它旨在缩短系统开发生命周期并提供高质量软件的持续交付。 DevOps 是对敏捷软件开发的补充； DevOps 的几个方面来自于敏捷的工作方式。

3) DevOps包含什么

圣经里面有句话：日光之下无新事。解决协作问题，在经济学、管理学、组织学等学科里面早已经有了论述。DevOps这个框架里面的包含的内容，也并没有什么特别之处。一般而言，解决协作问题的框架如下：

· 认知。Ops需要改变认知，软件工程可以做到又快又稳，二者并不矛盾。

· 目标。Ops需要跟Dev对齐目标，都是为了又快又稳的交付价值。

· 指标。为了达成目标，需要有个指标来衡量，这就是DevOps的4个指标，这4个指标都做得好，才算DevOps做得好，缺一不可。

变更提前期。指代码变更提交到主干分支与进入可部署状态之间的时长

变更失败率。变更失败率是指生产后需要热修复或其他补救措施的代码变更百分比。

部署频率。将新代码部署到生产环节的频率。

平均恢复时间。部分服务中断或完全故障中恢复所需的时间。

· 为了达成目标与指标，才有了各种创新的组织架构、流程、标准、工具、模板、指南。

所以，对齐了目标和指标之后，各种手段和方法都可以包含在DevOps里面。从协作的角度上讲，消除Dev与Ops团队之间的鸿沟，在对齐了目标与指标的前提下，重点是最好信息和交付物的高效流转。

4) 关于DevOps，正在发生什么？

Ops正在弱化……

云计算的发展，让企业不用做基础设施的运维、或者只用少量的人做基础设施的运维。

K8s的发展，让应用的运维越来越标准化，应用运维变得很简单，应用部署升级、应用的韧性、应用的弹性、应用的可观测性，可以由开发人员轻易完成，不再依赖Ops团队。

DevOps未来是什么样子？

软件工程从瀑布到敏捷、到DevOps，下一阶段是：云原生 + 平台工程 。

为什么是云原生 + 平台工程 ？因为云原生以应用为中心，应用之外全部由平台能力来提供。应用本身的部署方式、韧性、弹性、可观测行由开发人员来定义，交给平台后，平台自动来保障。做到这一步之后，Ops就会消失，只有Dev团队。

平台工程除了提供应用的各种运维能力之外，还会将Dev内部的工作流程标准化，信息标准化，以任务流的方式驱动Dev内部的协作，到时，Dev的内部协作，不再是靠人来驱动，而是靠平台来驱动，每个人只需要完成平台分发的任务即可，每个人都是研发协作流程上的一个螺丝钉。而这一天，很快将会到来。

CloudOS（企业云原生数字化创新平台），可以为企业构建敏捷创新的应用研发环境，实现应用研发可视化、敏捷化和技术平台标准化，让传统应用研发人员快速实现云原生应用创新，加快企业数字化转型。提供可视化操作界面，通过WEB页面完成架构设计、API管理、在线开发、API自动化测试、多云发布、多云应用调度、应用运维等云原生应用全生命周期管理。支撑传统应用迁移上云，助力传统应用研发团队高效完成云原生应用创新。

体验平台工程，不妨试一试CloudOS >>