DevOps是近期非常火的一个概念，谈IT流程建设不说点DevOps都不好意思和人打招呼。

但是DevOps究竟是个什么东西，这个东西能不能用？怎么用？什么样的情况才叫做DevOps落地成功？

对于这些问题的答案，虽然网上有铺天盖地的文章和教程，但是一般来说都是从理论或者方法论上去阐述，也有大厂的实施经历。

个人就感觉这里的它山之石，很难攻玉了。最终还是得思考下DevOps的由来，综合自己所在企业的现实状况去考虑。

目录

• devops是什么
• devops概念提出

1. 单体架构+瀑布模式
2. 分布式架构+敏捷开发模式
3. 微服务架构+DevOps

• devops深度理解
• devops的实践方式
• devops实现相关工具

1. devops平台搭建工具

一、devops是什么

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

这里先给出维基百科的定义，没指望你一下子看懂，先有个概念了解一下。

二、devops概念提出

2.1、单体架构+瀑布模式

单体应用架构

瀑布开发模式

以电商系统为例，单体应用架构为 LNMP，这个时候只有 DEV 没有 OPS，DEV 就是全栈，就跟我们上大学玩的 demo 一样，项目开发好，找台服务器安装好环境，把 jar 包 scp 到远程服务器，放上去开启服务就可以。

这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，部署简单，通常开发就可以完成运维的工作，不需要专门的运维来做部署，所以开发模式很简答，直接按照瀑布流方式开发就可。

2.2、分布式架构+敏捷开发模式

分布式架构

敏捷开发模式

随着业务体量发展越来越大，一台机器扛不住，那么就加机器，单机变多机，业务架构也开始加入了 nginx,cdn,缓存等通用基础服务，业务变多肯定会招人，就涉及到多人协同开发，多人多机器模式。

多人协同开发问题:

先说说多人协同开发问题，人员一多，为了更好的分工，大多会将项目进行拆分，每个人负责专注于一部分，有点包干到户的感觉，敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。

另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，QA的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证。这样开发产品的可控性也更强，遇到了sb甲方的时候，阶段性的让他检验一下项目成果，防止画鸡成鸭。

多机器问题:

再说说多机器问题，之前机器很少架构简单的时候，开发就可以干运维的活，就算加了几台服务器，那也是脚本将 JAR 包同时发布到这些机器上，好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，所以大家在上线之前可能会去群里吆喝一声，”我要上线了，大家先别上线哈“，可想而知这样效率也很低下。

公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。但是这个时候也不是 DEVOPS，而是 DEV+OPS，这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。

开发和运维角色的天生对立问题：

加入运维，就要协调人员配合，运维的宿命就是维稳，他们是很讨厌变动的；开发的天职确是不断地推代码上线，进行代码变动，更替迭代，这两个工种天生就是对立的。

很多大公司有那种，开发人员想要上线，需要提交各种审批，层层签字画押，多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。所以，敏捷开发解决了协同开发和多机器部署开发问题，但是没有解决内部人员的矛盾，留着这个矛盾在公司，开发和运维随时都可能约‘生死架’。

2.3、微服务架构+DEVOPS

微服务架构 

DEVOPS 

wiki定义微服务: 微服务（英语：Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。

上面是我摘自wiki对微服务的定义，注意几个关键词：软件架构风格，小型功能区块，模块化，语言无关。

第一，公司发展到BAT这种体量，会招很多人，JAVA，PHP，GO 技术栈都会有，需要协调技术栈；

第二，项目到后期往往会变得很大，全部都兑到一个项目里，最直接的后果就是项目变得很大，上线项目启动时间变长，一个BUG可能导致整个业务全线崩溃，最终的后果就是项目变得越来越难以维护，加一个改一个东西几乎搞不动，而且还越来越难重构，牵一发而动全身。

所以，拆分解耦是最终的出路，将项目拆成一个个小的服务单独部署，以电商项目为例如图，将整个项目拆分为用户服务，商品服务，订单服务，积分服务......每个服务单独部署，之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础东西，抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘中台服务’。

拆分部署催生出DEVOPS 再看看这种架构下的开发模式DEVOPS，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦。

那么为何不能再远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是DEVOPS开发模式诞生了，开发也是运维。

三、devops深度理解

我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：产品规划、开发编码、构建、QA测试、发布、部署和维护。

最初大家说到DEVOPS，都是指的‘开发运维一体化’，如下图:

现在大家说的 DevOps 已经是扩大到“端到端”的概念了，如下图：

DevOps 的三大支柱之中，即人（People）、流程（Process）和平台（Platform）。即

DevOps = 人 + 流程 + 平台

人 + 流程 = 文化

流程 + 平台 = 工具

平台 + 人 = 赋能

 四、DevOps的实践方式

上面提到了当前的几个问题：

    业务/代码复杂度高，任何修改无法评估，失败风险大。逐步退化成靠文档去规范每个阶段
    环境多，需要大量的人力成本来维护
    需求开发速度和稳定性之间的矛盾

那么就考虑下DevOps提供了哪些方法和工具来解决这些问题，从网上盗了一张图，是每个阶段的工具集合(侵删)

看完了简直是一脑壳包，所以要梳理下。

是否引入一个新的工具或者方法的时候，总要有一个判断标准，根据数字化的标准去判断是否由于当前的方法和工具。对于研发效率这个方向而言，有下面几个指标可以参考：

•   部署频率：指应用和服务向生产环境部署代码的频率。
•   变更前置时间：指代码从提交到成功运行在生产环境的时长。
•   服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
•   变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。

或者说，我们就是要从这想办法提高这几个指标。

或者从软件工程的角度理解，我们可以把往DevOps演进可以逐步分成下面几个阶段：

•   持续集成，代码统一管理，持续构建，开发持续输出到测试。
•   持续发布，持续测试，完成到产品发布的持续输出
•   持续部署/交付，完成产品到生产环境上的持续输出

也就是说，我认为提高效率的过程中(不管是不是DevOps)，都是可以针对性的去提高这几个指标，逐步的演进到下一个阶段。在这个过程中来针对性的选择工具。使用工具就是想让各个流程步骤自动化，避免对人的依赖。

1. 开发自动化，主要从配置管理，代码托管(Git)，代码评审(GitHub)，代码静态检查(sonar)，单元测试(JUnit)，配合Jenkins工具来提高。
2. 测试自动化，引入自动化测试
3. 运维自动化，引入环境监控(Portainer)，日志收集等工具

策略就是发现瓶颈，解决瓶颈。发现人工部分，考虑工具来替代人工操作，不断循环往复的过程。

五、devops实现相关工具

 人自然不用多说，开发前后中涉及到的所有人，流程前期是产品出原型，UI出设计，然后前后端代码开发，QA测试，最终部署上线，下图是部分流程图：

这里重点来看看devops平台搭建工具，工具很多，组件很多，百家争鸣,这里我列举的大多数是我公司用的，也是大部分公司都在用的。

5.1、devops平台搭建工具

项目管理（PM）：jira。运营可以上去提问题，可以看到各个问题的完整的工作流，待解决未解决等；

代码管理：gitlab。jenkins或者K8S都可以集成gitlab，进行代码管理，上线，回滚等；

持续集成CI（Continuous Integration）：gitlab ci。开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

持续交付CD（Continuous Delivery）：gitlab cd。完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。

镜像仓库：VMware Harbor，私服nexus。

容器：Docker。

编排：K8S。

服务治理：Consul。

脚本语言：Python。

日志管理：Cat+Sentry，还有种常用的是ELK。

系统监控：Prometheus。

负载均衡：Nginx。

网关：Kong，zuul。

链路追踪：Zipkin。

产品和UI图：蓝湖。

公司内部文档：Confluence。

报警：推送到工作群。

有了这一套完整的流程机制，整个开发流程涉及到人员都可以无阻碍的进行协调工作了，开发每天到公司，先看看jira,看看线上日志，出了问题看看监控日志，运营同学反馈问题不着急的去JIRA，着急的群里吆喝，产品和UI的图直接蓝湖看，运维关注监控着大盘，改革春风开满地，互联网人民真高兴~

如果你想从零开始掌握DevOps的话，可以看看我录制的这套DevOps教程，希望对大家有帮助！

如果觉得有帮助的话，可以帮我点赞收藏一下，写的不对或不清楚的地方，也欢迎大家在评论区指出，谢谢！