当我们尝试了解任何一个技术的时候，我们都需要先搞清楚这项技术出现的背景和其将要尝试解决的问题。 DevOps在零几年的时候就出现了，它并不是一个新的概念，为什么最近(尤其是从16-17年)开始突然就重新火了起来呢，从业者们应该能感受到，无论是在BATMD等各大厂的技术分享上，还是程序员们日常闲聊的话题或招聘描述中，DevOps这个词的出现频率都在不断上升，我们先尝试从行业角度来聊一聊为什么会出现这种情况。

为什么是DevOps

首先，从比较广泛的角度来说，如今的每一个公司都正在或者即将成为一家‘软件公司’，以我们比较熟知的传统企业为例，比如，招商银行、中国人寿、平安集团、长安汽车等等，在数字化转型的浪潮下，这些公司无论是从软件研发的人数规模上，还是在线上软件运行规模上，都已不落后于多数我们所理解的知名互联网企业了，已经让人们很难再拒绝承认它们也是一家互联网企业。 以央行为例，在我们传统的观念里，它是一个制定和执行货币政策，防范和化解金融风险，维护金融稳定的一个国家部门，但同时，它也是一家技术投入巨大的科技公司，尤其在数字货币和区块链领域，以2017年为例（因为那个时候我还是一个区块链从业者），央行在数字货币和区块链领域的软件相关专利提交数在全球是排第三的，第一是阿里，第二是美国银行，而大家常识期待的比如google，IBM等都在后面。从这个角度来说，无论是央行，还是美国银行，其实都已经可以归类为软件公司了,而且是很头部的那种。

第二点，是各行业类的竞争。

一方面，各行业正在变得越来越细分，大家都在跑马圈地，领域内的竞争变得越来越激烈；

而另一方面，来自新兴企业的对传统行业的冲击几乎可以看到降维打击的影子。最典型的比如特斯拉，滴滴，再往前可以推到各种电商，等等，这里就不再细说了。

最后一点我要提的是技术的更新迭代正在提速，这一点大家的体会应该会更加深刻。 这一块我主要从我所比较关注的几个领域简单聊一下。首先是云计算领域，这一点我们以14年为起点，那个时候我们提到云计算在聊什么呢，虚拟化，KVM，OpenStack， 同时，Docker开始火了，然后我们聊的是什么了，容器化，LXC，K8S，到现在我们在聊的是什么，微服务，ServiceMesh，Istio。同时另一个层面我们在聊的从私有云到混合云多云技术，甚至在深度学习的加成下边缘计算也发展的如火如荼，可以说正在席卷物联网。 那么另一个方面肯定就是机器学习领域了，这一块的内容涵盖非常广，这里我单以大家可能比较熟知的ImageNet图像分类的历年冠军及其成绩为例，我这里只是提一下几个比较有里程碑意义的深度网络，2012年开始，AlexNet是当年冠军，错误率是15.3，14年googleNet，VGG，都比较接近6.7，然后2015年ResNet，错误率3.5，再到17年Senet 2.25，然后就停了，因为已经没有必要了，已经远比人类分类更准确了，大家可以看到，这就是短短5年时间发展。

说了这么多，归纳一下，我们再从另一个角度来聊一下这个问题，其实就是软件工程里易变性，不确定性，复杂性，模糊性的特性的新挑战。 那么我们作为开发或开发上下游人员该如何面对这些挑战呢，接下来回到主题。

DevOps是什么

Development 加上 Operations 翻译过来就是’开发+运营‘，关于翻译这个点上，前面这个词‘开发’没有问题，但是Operations这个词国内更多的都是翻译成运维，但我更愿意把它理解为运营，因为在我的理解里，运维是面向服务的，而运营是面向业务的，而DevOps是面向整个软件生命周期的，关于这一点，我们接下来细聊。

首先我们不得不先了解传统瀑布流模式的软件生命周期，瀑布流模式严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行，这个如果是软件相关专业或者有软件开发经验的应该比较容易理解，只是可能在我们具体实施中有可能会跳过其中的个别步骤。所以接下来用一个简化过的图来给大家解释一下DevOps究竟干了什么

在这个图里，把软件的生命周期简化为设计/开发/测试/部署 这四个步骤 第一个瀑布流模式 第二个是也火过的敏捷模式，设计完，就进入不停开发/测试的迭代过程中，最后交付部署 最后一个就是我们今天要讲的DevOps，可以看到它是在不停地开发/测试/部署。

所以DevOps到底是什么呢？

一个软件生命周期的流程管理。在下面这个流程图里，左边是开发人员的工作，包括需求/计划/编码/构建/测试 完了之后，由Operations上线并进行监控，再反馈到开发调整开发计划。这里就是我为什么会把运营这个角色也纳入到DevOps这个体系的原因，因为做开发计划是需要与线上实际业务的运行情况保持必要的一致性的。

如何推进

了解了DevOps的基本思路后，我们可以知道，DevOps其实就是加快了软件开发到部署的节奏，将一个大周期进行了拆解，那是不是意味着我们之前的开发模式直接就可以切换过来呢，也不是，我们该如何进行交付，如何保证快速迭代的情况下的质量，如何高效的沟通变更，等等等等，都是问题 刚好，有一大堆工具正在等着我们，那么DevOps也是一系列工具链，这里应该有一些大家比较眼熟的，比如。。。。

工具链也有了，是不是搭起来就完了呢。当然也不是。

首先这么多工具，不一定搭得起来，也不一定需要。 其次，即使搭出了一个工具链了，还有更重要的，那就是使用这些工具的人/组织。 这里我也简单的聊一下我所理解的学习型团队中比较重要的点，当然不会很全。

第一就是合作与沟通，在DevOps的体系下是需要推倒部门墙，进行更高效的团队配合的，但随之而来的就是

相对应的第二点，责任感，因为在团队责任变得相对模糊的情况下，每一个成员自身的责任感就便更加重要了 除此之外，我个人觉得还有比较重要的一点就是工具化和自动化的思维，这一块主要是可以减少我们频繁反复的人工操作，避免’手抖‘带来的错误，这一点本质还是为了使我们的沟通和合作变得更高效。

推进中可能面临的挑战

技术里面没有银弹，一方面，没有技术可以解决所有问题，另一方面，技术在解决一方面问题的同时，可能会带来其他好多方面新的问题，那么我们唯一可以做的就是时刻准备着。DevOps也是一样，它并不能帮我们解决没有故障，测试覆盖率会更高，故障响应会更快，更清晰的业务逻辑，懒惰…此处省略1000个字 本性难移

另一块是学习型的团队文化建设的调整，我刻意的把这部分拆成了两个部分来讲，因为任何技术变革要落地，最大的挑战都是文化革命。 这里我就再补充几点，学习和创新，这个很容易理解，很难做 安全的失败，这里我想延伸一下，聊一下关于安全绳和安全网的区别 大家可以思考一下，你们所在的团队现在属于那一种，以及最适合你们团队的是哪一种。

最后，有道无术，术尚可求也。有术无道，止于术。