在过去的三年中，我作为 DevOps 的咨询师参与了很多企业的 DevOps 转型咨询以及技术实施，也在不同的社区活动中分享了自己在 DevOps 上的实践、理解和观点。

随着 DevOps 的盛行，我在很多场合和越来越多的人聊起 DevOps。也在不同的渠道听到了很多人在讲 DevOps。然而，讨论的背后，我发现每个人对 DevOps 所指并不是同一件事情，也由于各执一词导致不欢而散。

[好文分享：www.11jj.com]

于是我通过 DevOpsDays 的官方网站整理所有 DevOps 的有关材料，随着学习和了解的不断增多，我也渐渐的对 DevOps 有了更进一步的认识。我把学到的材料经过整理后把陆续放在了简书上，形成了" DevOps 前世今生" 这个系列，这个系列还在不断补充新的材料。

含义越来越丰富的 DevOps

DevOps 至今都缺乏一个清晰和统一的认识。对于一场运动来说，这是一件好事，也同样是一件坏事。虽然 Patrick 曾经在自己的博客里一再提到自己对 DevOps 的"正确认识""，但社区似乎不以为然。

缺乏“官方定义”好处是人人都可以定义，因此没有一个人或者组织可以垄断 DevOps 定义权。所以每个人都自己可以参与到这一运动中去，不断为其增加新的概念、新的实践和新的工具。这会使 DevOps 社区不断的繁荣。

而坏处也很明显，对于 DevOps 的后来者 —— 那些没有参与进来的人，需要学习和理解的 DevOps 知识的广度和深度也越来越大。

以至于后来出现了这幅众所周知的“盲人摸象图”：

这幅图中包含了很多概念，但主要表现的意义 DevOps 是一系列概念的总和，任何一个单方面的定义只是 DevOps 的一个部分，而不是 DevOps 的整体，随着 DevOps 这个概念的不断膨胀，人们就更难理解 DevOps 了。

那么，你理解的 DevOps 是指的什么？

在接触了各类客户和社区之后，我开始尝试理解每个人谈到 DevOps 的时候，他们分别指的是什么，以及所指内容背后的目标和动机。渐渐的，我把我所听到的 DevOps 概念分成如下四类，分别是：

DevOps 是一组技术/实践

DevOps 是一个角色

DevOps 是一种工作方式

DevOps 是一种组织结构

那么，我们分别来谈谈这四类 DevOps。

当 DevOps 是一组技术/实践

在工程师文化的组织里，对先进技术的渴望是最常见的学习动机。可以促进工程师用更有效率，更优雅的方式解决问题。而对于非工程师文化的组织，新的技术往往是提升其 KPI 的工具。以下是我听到 DevOps 的时候，经常触及的话题：

高频部署

持续交付

云计算/虚拟化技术

基础设施即代码

Docker

自动化运维

高频部署

曾经和某跨国著名银行的外汇交易产品的 IT 产品负责人交流 DevOps。对方很自豪的告诉我，他们产品每天的部署频率超过500次，我听了不以为然。因为，部署频率高不见得是件好事。于是我问了以下几个问题：

为什么你们需要这么频繁的部署？有这么频繁变动的业务需求吗？

在这么多次部署里，是发布业务价值的部署更多，还是修复问题的部署更多？

这些生产环境的变更难道完全是不可规划的吗？

由于对方的金融业务有相应的法律法规，理论上没有这么频繁的变更需求，除非清理技术债，否则没有很强烈的变更动机。但对方并没有直接回答我的问题，而是换到了其它问题上，因此我最终也不清楚对方这么频繁变更的驱动力。

这对我有一个重要的：指标导向的 DevOps 往往是一种 DevOps 的反模式，它会忽略和掩盖真正的问题。

指标的背后是某种度量，如果部署频率一直很高，一定反应了某种现象。而这些现象不一定是个好现象：不是业务的变动很频繁，就是技术的变动很频繁。但如果二者都频繁，我们应该衡量变更带来的价值和风险（当然，DevOps 可以降低变更的风险），并优先变更价值较高的请求。有可能新的业务尝试让我们从市场上获得了更多的关注，也有可能新的技术提升了生产率。但无论是哪一种，部署频率应该是一个有多到少不断循环的过程。这表明系统在走向成熟和稳定的同时，能够及时响应变化，无论是对技术还是对业务，对变更产生的影响都需要一段时间去积累和总结数据。

此外，DevOps 绝不是为了提升部署频率而牺牲了软件质量和业务价值，甚至是安全措施。换句话说，DevOps 不是一种对质量的平衡和妥协，它是一种全局改进。全局的改进就意味着以价值为最高原则所度量的相关指标是不能有所下降的。

持续交付