想要全面了解DevOps，从概念、实现相关工具到如何落地，看这篇就够了

我们总是在提DevOps，敏捷管理，但大家未必真的明白什么是DevOps。本文是将向大家介绍到底什么是DevOps，DevOps的初衷到底是为了解决什么问题？它能够如何实现？能够带来哪些价值？来让大家对DevOps有一个全面的了解。

---

一、Devops是什么

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

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

二、Devops概念提出

1. 单体架构+瀑布模式

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

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

2. 分布式架构+敏捷开发模式

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

多人协同开发问题:

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

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

多机器问题:

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

公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。

但是这个时候也不是 DEVOPS，而是DEV+OPS，这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。

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

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

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

3. 微服务架构+DEVOPS