*要了解什么是DevOps，我们先来认识一下软件工程。

了解软件工程

对于新晋程序员来说，软件研发主要意味着编码（coding），或者叫开发。想到编程，大家头脑中可能浮现出这样的场景：

当然这是软件工程的一部分，而且绝对是很重要的一部分，只是对于整个软件的生命周期来说，还有很多重要的组成部分。其实软件工程是个系统工程，它工业性的一面更应被展示，所以软件工程更像是这样：

下面这个图展示了一个软件从提出需求到上线运维所要经历的流程：

在编码之前，有需求分析和设计阶段，编码之后要经历几道测试，测试通过了进入可交付状态，而软件真正被用户用起来，需要部署上线，上线以后还有个大活，就是需要运维，运维的内容包括维护现有的业务、上线新业务以及修复运行过程中出现的问题。随着互联网应用的蓬勃发展，专门的运维职责和岗位已经不再陌生，这个岗位以黑白颠倒的生活而著称。而所有的这些阶段都是软件研发过程中重要组成部分，缺一不可。

进入正题。

Why DevOps？

DevOps提出在2009年，相对软件工程发展史还是比较年轻的。它的提出旨在倡导一种改变，在改变之前是这样的：

从上面的软件研发流程的图中可以看到，软件研发活动是分阶段的，大体可以分为4个大的阶段：设计、开发（Dev）、测试（OA）和运维（Ops），而人员和团队（或者部门）也基本是按照这样区分的。在这个流程定义里面，认为软件研发基本上是一个向前不会倒退的过程，也就是说后面的流程依赖于前面流程的完成，比如说为了能让开发一次性正确完成，设计阶段必须力求完整全面，同样为了能让测试结束就能发布软件，开发阶段也要力求正确全面。运维阶段也不例外。这种流程假设软件研发是一个确定的，可计划的活动，同时各个流程是相互独立的，可独立运作的，可以想象成流水线，开发把工作做完了传给测试，测试再传给运维，等软件出厂（上线）以后基本和生产者（开发人员）没关系了，更和设计者没关系，除非问题很大，需要重新设计，发生这种情况基本也是不怎么允许的。

IT的兴起对这种静态化的假设来了沉重的一击，互联网应用不断涌现消亡，软件的迭代速度也以前所未有的速度在增长，这种需要依赖周密计划的单线流程已经完全无法满足互联网软件快速迭代的需求了。

另外，两个主要活动，开发和运维之间的界限如此明显，而他们对软件的关注点又是矛盾的：开发者主要关注更多更快的功能发布，更低的内存消耗等等，运维者关注系统的稳定性和性能。运维者希望系统尽量不要出问题，而开发新功能几乎是没法避免的。

好，那么DevOps想要的软件研发流程是什么效果？看图：

DevOps倡导什么

首先：运维阶段以后还有后续，就是继续进入一个新的循环，从计划重新迭代开始，这也是一种反馈；此时的计划是带着上个循环的反馈结果新的计划；

其次：期望这种一种平滑、快速的循环，这就需要高度的自动化，因此8字外围重多的工具支持是必不可少的；

最后：强调各个阶段紧密的协作，而不是流水线式的传递，这就要求打破团队壁垒，信息共享。

What is DevOps？

来自百度百科的定义：

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

我们来理解一下：

DevOps首要关注在文化，涉及到人、团队组织、工作习惯，实践工具集，它不是流程，也不是工具集合，流程和相应的工具软件都是它用来落地文化的工具而已。

DevOps几个直白理解的变体

Dev + Ops：强调开发和运维加强沟通协作，打破界限。

Dev Ops（开发者运维）：谁做的软件谁来运维，也就是开发者自己参与运维，那么在软件设计之初，就会考虑可运维性的问题。

How DevOps

以下将从三个方面（流程、工具、组织）浅析DevOps的实践

流程实践：关键字“持续”

让“8字环”流动起来，离不开尽量快速地将环内的环节执行起来。而其中的关键是将重复可自动化的环节尽量自动化，尽可能频繁地做，“持续”意味着时时刻刻。

持续集成（Continuous Integration）：需求的不断变动触发持续的编码、构建流程。

持续交付（Continuous Delivery）：完成测试的业务应用以合适的方式交付到适当的节点。

部署发布（Continuous Deployment）：将交付的业务应用按照规则部署到生产环境，完成测试后发布。

持续监控（Continuous Monitoring）：时时监控业务应用以及系统平台的运行情况，形成监控报告。

持续改进（Continuous Improvement）：基于监控的数据，反馈的意见，启动新的改进计划流程。

频繁做，快速做，那么另一个关键是：减小每次的发布增量。每次的新的循环还是，计划（Planing）要随着之前的数据进行新的调整。因为在足够快的循环下，可以不需要做超前规划和超前研发，这种模式非常适合业务变化快速的IT软件研发。

工具和平台：云+微服务

从下面这张图可以了解到，整个DevOps生态所包含的工具已经极其丰富。

除了常规的工具，重点圈出两个概念：云和微服务。

微服务强调的是业务系统彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。微服务的理念本身是面向部署的，和DevOps理念天然契合。服务独立保证了应用易于增量部署，增量部署是对于一个大应用来说，可以每次只更新修改过的小应用，也就意味着更易于实现持续部署。

而各种云基础设施平台的兴起（Google Kubernetes、AWS、Openstack、阿里云等），以及容器（Docker）的产生，更让微服务有了落地的平台和介质。容器特别适用于轻量化的应用部署，云基础设施让容器等应用的生命周期管理更加智能化、集中化，也就是微服务的生态已经成熟，剩下的就看应用方怎么施展了。

对于DevOps来说，有了云基础设施或者微服务，持续发布便是一项有理论和技术支持的运维活动，围绕着持续发布的前后流程可以以此而设计、迭代起来。

组织变革：按产品来组织团队

要按照产品来组织团队，而不是按照职能来划分部门。在一个团队里包含一个产品研发所有的角色，让生产一个产品的人在一个团队内。

一个可能的DevOps团队（激进版）

首先需要对开发者的角色和职责做一下变更，传统的开发者只需要专注于coding，而他的开发蓝本是前面的人（业务设计和系统设计）设计好的，他写完代码保证自己的功能测试通过，交由专门的QA团队进行测试和验收。

在DevOps中，一个开发者除了上面这些工作，可能还需要做：

1、将自己写的应用/系统/变更进行测试、发布

2、将自己写的应用/系统/变更部署到生产环境

3、保持手机开机，保证新变更发布产生的告警短信能够收到，并及时处理或回退

如果他想每天晚上不被告警短信吵醒，他可能需要做：

1、保证自己写的功能是经过充分测试的，因为经常编写代码，所以手工测试是不可行的，他要为自己合入的功能和代码编写自动化测试用例；

2、在写代码之前就考虑过系统的稳定性、可靠性、性能的问题，保证合入自己的代码后系统的这些指标不劣化

3、为了能够让运行错误及时暴露，他会保留可供运维框架调用的接口，或者给监控系统吐适量又足够的告警信息

即便在理想的情况下，上面所描述的开发者的职责位于一个团队内，而不是一个人身上，因为个人通常难以擅长并承担这所有的职能，特别是在一个阶段内，应该由不同的人完成开发、测试和运维。但是团队内部的职责划分不是静态的，DevOps鼓励相互学习和流动。

那么QA和Ops他们做什么？

一句话：搭建产品测试和运维的基础设施，设计维护易于测试和运维的系统，并对开发的可测试性和可运维性提供技术支持。他们需要做这些事情：

1、引入新的工具、技术和系统支撑测试和运维，提供基础设施服务

2、制定服务于可测试性和可运维性的规范

3、当开发者的设计和修改不符合可测试性和可运维性的要求时打回修改，并提供技术支撑

4、对产品的可测试性和可运维性提供度量，持续监控，推动改进

这样QA和Ops他们处于基础设施服务提供者和技术服务提供者，他们应当在不同的部门。

既然是文化变革，那么离不开人和组织形式的变革。倡导一种文化需要付诸行动，管理者需要对组织和角色重新安排，这一切的目的是为了能够减少无用的沟通，增加有用的知识共享，减少壁垒带来的协作障碍，并提倡跨职能的角色思考。

最后，欢迎来到真实的软件工程世界！