一篇全网最通俗易懂的DevOps认知扫盲文

上一篇分享介绍了产品和设计师不得不了解技术的理由和入门方法，这一篇内容趁热打铁，再继续分享最近在整理的 DevOps 相关的原理和流程的说明。

DevOps 是国内所有大型企业都在实践和应用的项目改革，不管是互联网大厂如腾讯、字节、阿里、美团，还是老牌企业华为、移动、电信或银行。也孕育出一系列新兴的 SaaS 产品，如极狐、Coding、蓝鲸和博云等。

了解 DevOps 不仅能跟上时代的步伐和主流项目开发流程接轨，拓展进入相关项目的可能性，同时也是一个很好的了解技术的窗口，不再做技术方面的小白。

DevOps 是 Development 开发和 Operations 运维的组合缩写，多数中文翻译叫开发运维一体化，它并不是一种技术或编程语言，而是一种面向项目编程管理的方法论，类似于传统制造业中的精益制造理论。

它的主要作用，是在开发过程中促进团队成员（主要是开发、运维、测试）的沟通和协作，实现更高效、更频繁、更可靠的软件交付，以完成业务目标。

相信看到这里会产生第一个疑问，程序员码代码质量越高和交付成果速度越快不是天经地义的吗，这种要求难道是最近才提出来，以前就不用高效、频繁、可靠了吗？

问题就出在以前的工作模式上，不是不要求，而是很难做到。所以我们要首先理解没有应用 DevOps 前的产品开发流程和问题是什么。

一个传统的项目流程，在确定需求以后，开发人员（Dev）完成相关的功能代码，然后交付给运维人员（Ops）部署到测试环境，然后测试人员进行测试并提交问题，修改完成后再提交到生产环境正式运行。

这种流程很直观也很好理解，多数企业初期和小团队都会使用这种最朴素的方式。但随着企业的发展，团队成员开始增加，本来只有几个人的研发部门可能增长到几十上百人，一个单一的团队被拆解成若干的小团队，每个团队负责自己对应业务和模块功能的开发。比如做个电商网站，会员、购物、活动、社交、会员、广告、搜索分别由不同的团队负责并开发。

这就导致，团队之间往往不清楚其它团队在做什么，大家各写各的，等到临近上线日期的时候，各部门再把写好的代码进行合并（形成完整的新版本代码），交给运维进行部署做测试。

这时候问题就开始集中爆发，因为不同部门成员写的代码可能在本地运行的环境里正常，但是合并到一起就会引发一系列难以预估的问题，如服务运行时的报错、中断、泄露等。每个问题的解决往往要投入大量的时间精力，严重干扰了上线的进度。

且能在测试环境解决的问题都还算小问题，最让人担心的还是在测试环境中明明已经测好了，上线后却出故障了，导致诸如用户交易记录丢失、限量商品无限库存、重要页面访问无效等灾难性后果。这时候只能下线服务，团队继续耗费大量的精力加班加点修复BUG让服务恢复正常运转。

所以每一次发版都是一次折磨，项目越庞大折磨越大，不仅造成产品本身质量变差，同时项目执行效率大打折扣，不但提高了企业的人力成本，还会对业务造成非常负面的影响。

这时候不得不提一提运维这个岗位，很多人都知道开发即前后端的程序员，主要负责产品功能模块的开发。而运维则是负责搭建可以运行该产品的网络环境，并保持服务运行的稳定。

最早这些工作是由后端工程师负责，但随着互联网基础设施的发展和完善（越变越复杂），运维相关的工作也变得越来越专业和繁琐，除了代码仓库、集成、部署、编译外，还涉及服务器的硬件维护、网络布线、虚拟化，以及负载均衡、内容分发、环境管理、镜像备份等工作。

所以工程师团队就分离出了运维这个岗位，他们的作用和重要性毋庸置疑。但是他们的工作本质就是—— 维稳，因为搭建出稳定运行的环境是很费劲的，对这个系统加入任何新的代码都可能打破它的稳定制造出新的问题。

而开发的责任则是——改变，通过修改代码或添加新的代码才能实现产品的需求，所以他们的工作就势必会对运维工作目标造成阻力。

这两者之间的职能天生就有冲突，以前面的开发流程为例，在前期的开发阶段中，开发人员不仅是在完成产品需求，也是在给运维制造问题。开发周期和规模越大，就会创造出越多运维问题进行积压，之后再将代码和问题一起交付给运维，让它们在运维手里合起来爆炸……

在这种分工体系下，开发人员会认为自己只需专注功能代码的开发就可以了，“运维的工作关我什事？”。而运维团队面对这种不负责任的行为是束手无策的，但不满的情绪是会累积，并反应到实际工作中，降低项目的执行效率和完成质量。

DevOps 的作用，本质上就是要改变这种现状，通过新的项目方法和一系列工具、自动化处理，来促进开发和运维人员（还包括其他项目岗位）的沟通和协作效率，让产品的开发过程更透明，发布可以更快捷、频繁和可靠。

看到这里相信你们已经对 DevOps 是什么有了大概的认识，但对于它具体的内容和执行方法依旧一头雾水。所以下面，我就要进一步深入，讲一讲 DevOps 的流程和内容是怎么一回事。

单体服务架构

深入理解 DevOps，就涉及到对一些基础服务架构的认识，这就要从这几年的演变说起。

最早期和最简单的网络服务架构叫单体应用架构，比如开发人员编写一套电商的系统和代码，将对应的程序上传到某个服务器中运行，就可以发布且让用户访问了。开发人员只要监控这台服务器的状况就能实现该产品的运行和维护。

比如我们自己买一台Nas或软路由放在家里接上网线，在上面安装好相应的系统和服务，实现远程的登录和访问，就是最基础的单体应用架构。

想要对运行中的软件进行更新只要先中断服务（类似关闭软件），然后把新的代码和文件替换掉线上的文件，再重启服务即可，比如 FTP 传输工具就是用来实现这种文件传输的。可以想象成服务器就是一台独立的电脑，上面安装运行的软件是由很多零碎的文件组成的，比如代码文件、配置文件、图片、音视频等，想要修改或者更新软件就是将新编辑好的文件上传覆盖掉原有的，是你们在电脑软件升级和 “破解” 中都操作过的步骤，非常简单。

虽然单体架构操作起来很简单，但是面向规模更大、更严肃的场景就显得太简陋了。如果访问量过大，或者断网、断电、机器故障，或者机器被流星砸中物理毁灭……

所以，单体架构只适用于个人和一些小型企业的基础服务，随着项目规模的扩大，就需要进行架构的升级。

分布式架构

分布式架构就是单体架构的对立面，它将原本只有一台的服务器拓展成多台，并且让每台服务器都具备相同的功能，且运行完全一致的程序和服务，这些服务器可以在一个机房里也可以在不同的机房和城市，通过负载均衡技术 Nginx 将它们组成一个集合，共同为用户提供服务。

在这个集合中，每台服务器都是一台独立运行的个体，无论哪台服务器下线还是损坏其它服务器都能保持正常运转。Nginx负载均衡器负责将用户的访问请求自动分配给不同的服务器，让它们进行计算并返回相关的数据，避免服务器过载，提升服务最大的处理能力和访问速度。所以，这个集合里的服务器数量越多，支持同时访问的人数（并发量）、处理的任务也就越多。

除此以外，在这种架构下还会应用CDN、缓存、主从数据库等其它基础服务，对任何一台服务器的调整都涉及到一系列其它服务的开关和配置。

这么做虽然让服务变得更稳定和可靠，但也产生了很多负面的影响，那就是让软件服务的更新变得非常的繁琐。本来只需要面对一台服务器变成面对几十上百台，以及涉及的若干其它服务项的调节。就使得每次安装、更新软件变得非常麻烦，需要执行非常多的操作步骤，我们将这个安装 、更新的过程称为 “部署”。

尤其是更新软件，过去架构简单，项目规模小文件少，每次更新就是用 FTP 手动更新下文件，删除一些冗余的文件。而随着项目规模变大，文件数量急剧膨胀，每次更新可能涉及好几个团队，上百个开发完成的数百个文件的调整，那就不可能再用原有的方式执行。

于是在本地阶段，工程师需要先各自提交写好的代码，运维再对这些代码测试后进行CI集成，即将不同开发写的代码合并成最终的文件，这个文件往往是某种安装包的形式。然后部署的过程就是把原有服务器中的软件删除，再安装新的安装包，而不仅仅是手动进行文件更换。

但因为服务器数量变多，部署是没有那么容易的，也不会轻易关闭所有服务器中断网络服务然后进行升级。所以部署会具备一定的策略，如先部署到一小部分服务器中正式运行，用户使用没有问题后再部署剩余的服务器，这也叫灰度部署，是灰度测试在运维层面的应用。还有将服务器划分成两套，先关闭升级一套，运行稳定后再升级另一套的蓝绿部署，以及每台轮流升级的滚动部署。

这些部署策略的发明，原因就是前面说过的，开发阶段制造了大量的问题会在运维手上爆炸，而爆炸就发生在部署的阶段，因为在正式运行新软件前我们都不知道会发生什么问题，所以必须分批进行，先测试再全部部署。

在真出现问题的情况下，一方面问题的排查特别困难，修复也麻烦，另一方面往往一个小改动都会导致前代码集成、测试、部署的环节重新跑一遍，就是俗话说的为了一点醋还得包一顿饺子。

所以分布式架构的应用虽然理论上让产品的服务变得更可靠和稳定，但使得从研发到上线的流程变得异常复杂，很多公司的 IT 部门不得不花费大量的时间和这套架构做博弈，而不是将精力花在如何服务业务提升产出量上。

如果产品的体量再进一步扩大，变成像京东、拼多多这种量级的服务怎么办？每次新版本从集成到部署的时间可能就比之前长几十到上百倍，这就会让产品越发跟不上业务的进展，让所有的产品战略实施都增加了额外的滞后性，从而丢失竞争力。

于是，在大厂中分布式架构就慢慢被放弃，要转用新的架构类型。

微服务架构

分布式架构问题，就是没办法很好的适应大规模产品的运维，所以微服务的概念就产生了。既然项目规模特别大，那我们就把项目根据业务模块进行划分，拆分成若干小的独立的产品，每个产品都是独立运行在不同的服务器集群中。

这就极大的提升了产品维护、更新的灵活性，比如更新这款社交相关的功能，要增加短视频服务，那么开发人员写完代码后运维也只需要集成社交模块的代码，并部署进社交相关的服务器集群中，不用牵扯到其它服务。即使上线后产生问题，定位问题的范围也就在这个模块内，而不需要牵扯到其它所有模块。

而这些拆分出来的独立模块，就是一个微服务。实际的微服务往往比我现在的举例更小，它们虽然独立但服务之间依旧需要进行交互和数据的传输。而这些微服务中会有非常多通用的服务（比如短信验证码、广告邮件发布），一方面可以直接找网上开源的代码使用，另一方面也可以使用外包服务，或开发完成后剥离出来进行共用。

比如，公司运行好几款产品，服务内容有一定交叉和重叠（比如淘宝、天猫、咸鱼、极有家），那么基础账户、交易、商品这些服务就可以共用，整合成一个新的平台，让不同的产品从这里面的调用服务或数据，这就是前几年鼓吹的 “中台” 概念。

微服务是目前大型产品和企业都在使用的服务类型，虽然让代码的发布变得更容易，但整套架构也改变得越来越复杂。团队的协作需要经过特定的规范，并且需要依赖大量的自动化工具和数据可视化工具来减轻运维的压力。

比如前面说到的代码集合、测试、部署，这么多服务、集群、服务器全靠手动那运维肯定是这个星球上最肝的人。所以我们必须采用自动化的策略，让这些繁琐但是重复性的劳动可以交给机器自己完成。同时，运维还需要监控各个不同服务和硬件的各项指标，而可视化的工具是最佳的解决方案。

面对这样的背景，DevOps 的方法论就被提出来了，想要让产品更好的交付，那就需要制定出一套更有针对性的工作流，匹配新架构的应用，以及在不同工作阶段结合各类不同的工具，来提升产出的效率和质量。

之所以前面讲那么多架构有关的内容，原因就是 DevOps 是在遇到实际项目的问题以后提出的解决方案，而不是某些人凭空想出来的管理概念。

而 DevOps 作为一种方法论，也是经过演化后得到的结果，所以我们要再认识一下开发所经历的流程有哪些。

瀑布流

瀑布流，最朴素简单的开发方式，即开发收到需求和设计以后，花一段时间进行开发，然后交付给 QA 统一测试并找出 bug，本地修改完成后部署上线。

这也是外行对项目开发的普遍认识，它在小项目和单体式架构中确实可以比较快的完成任务。但这种简单的工作方法在应对大项目时是非常脆弱的，因为漫长的开发阶段中，如果工作的产出没有持续被审核、检验、校对，那么很可能产出的质量根本无法保障。甚至一开始开发理解的需求就是错的，那么等到测试阶段才发现就为时已晚。

而更重要的是，在开发阶段制造的问题在测试部署阶段改起来是很费劲的，因为积压 Bug 数量过多，代码质量差且系统脆弱，最容易发生的就是修复好一个 Bug，又产生新的 Bug，然后越改越多。

所以专业的团队都会直接放弃瀑布流的模式，需要更有效更灵活的工作模式。

精益/敏捷开发

然后精益和敏捷的开发模式就营运而生了，它们本质上都遵从 MVP 最小可行性原则，先开发出一个最简陋的版本用于评审测试，验证可用性，然后再完善细节。

一个完整的项目，就可以拆分成若干的模块，每个模块使用这种原则去执行，就能更早的发现问题，提升产出的效率和质量。简单解释起来，就是把测试流程前置，尽量减少问题的堆积分批次处理。

当然，这个模型描述起来很简陋，如果只是简单的分段和测试说到底还是瀑布，它们真正的价值在于每次测试除了发现 Bug 外还可以找出更好的开发、产品思路，从而修改原先的想法达到更好的效果，让产出物处于可变更的状态（所谓的拥抱变化），并优于最初的方案。

虽然大多数瀑布流的最终产出也和初始方案南辕北辙，但主要是受各种问题的影响而产生的妥协，质量只能远远低于预期。而精益/敏捷的目标是在兼顾项目目标和流程的同时，最大化发挥团队的创造力并给出更好的结果（理想情况下）。

因为篇幅关系，我就不打算去拓展精益和敏捷的概念，尤其是敏捷，这是一套非常复杂的项目管理系统，很少会有团队能真正理解并运用它，多数团队的敏捷仅仅都是魔改版的精益流程。

之后有机会我会单独写一个敏捷的扫盲系列出来，大家只要知道它们大概得价值和作用即可。

DevOps 流程

在这里终于要进入 DevOps 的相关解释了，DevOps 的核心出发点是为了解决开发和运维的协作效率而提出的概念，不然也不会用 Dev+Ops 的命名方式。

但既然要引入到项目中，只解决开发和运维的两个岗位之间的协作局限性太大了，所以索性拓展它的范围，加入产品、设计、质量工程、安全相关的成员和工作内容，使这些角色的工作相互依赖，成为影响整个应用程序生命周期（版本发布周期）的管理工具。

在微软的官方说明中，DevOps 影响的产品生命周期包含四个主要的阶段，计划 Plan、开发 Develop、交付 Deliver、运维 Operate。

计划：确定产品需求的阶段，并使用敏捷的方式（如 backlog 或看板）规划后续的工作。

开发：进行开发的过程，包含编写、测试、评审，并集成代码构建成可部署的文件。

交付：包含对基础环境的搭建和配置，然后将相关的文件部署到对应环境中。

运维：在产品上线后对产品进行维护、监视、故障排除的工作。

为了最大化发挥这四个阶段的效果，就会结合不同的工作流程、编程技巧、运维思路、数字工具。早期的 DevOps 流程搭建，会针对重要的工作节点配套一款数字化产品，提升生产力释放人力需求。

比如下面这样的例子：

要强调，DevOps 只是一种方法论并没有具体的执行要求，上面只是搭建 DevOps 平台时可选的配置方式，不同团队完全可以定义不同的工作节点（类似审批、安全管理、编排等）并搭配其它工具。

但每个节点选个工具来完成确实是太麻烦了，所以就有一部分开发商针对这些需求，提供了一站式的 DevOps 平台，将这些零散的功能整合到一起，让项目成员只需要访问一个工具就能实现大多数的服务，这就是 DevOps 的 SaaS 工具。

不要把 DevOps当成一个用来选择数字工具的过程，这些工具是用于执行 DevOps 流程的基础但不是全部。所以我们最后再总结一遍 DevOps 的操作过程是什么：

“结合敏捷的工作思路，在前期将项目分解成多个细分模块（Sprint），然后在执行过程（Scrum）中最快让测试和运维可以参与进来验证，并应用自动化工具高效的备份、集合、检查、构建、部署代码，逐一完成所有模块的更新完成整个项目，并有效的进行上线后的监控和维护……”

分布式+微服务结合 DevOps 的管理模式，让企业更新产品的速度和效率大大提升了，就可以用以周、或者天为单位的频率做更新，更快速地响应市场需求。比如下面就是互联网大厂和落后企业的部署节奏对比。

Amazon：23000次/天

Google：5500次/天

Netflix：500次/天

Facebook：1次/天

Twitter：3次/周

典型企业：1次/9个月

同时，它也让开发和运维的目标保持一致，关系更紧密而不是对立，激发团队的活力和创造性，这就是 DevOps 的价值。

结尾

针对 DevOps 更细致的认识，我相信光靠上面的解释还是有欠缺的，尤其是针对部分专业名词和敏捷开发的理解不足，就会不可避免的产生更多的疑问，这证明你们有在认真思考了。

而针对 DevOps 更完整的解析，我会在后面以 Wiki 的模式来整理，同时也会专门准备一篇内容来解释什么是敏捷开发，保证是你姥姥都能看懂的辣种……

本次的分享就到这里结束，如果中间有错误的地方，大家可以再下方评论中指出。

我们下篇再贱~