【软件工程】DevOps的研究和解读

前言

最近学习了一些关于敏捷开发模式的课程，正好结合我最近在看的一个概念——DevOps，来阐述一下软件项目开发的一些观点和概念。

1、DevOps的历史由来

为了有一个完整的叙事逻辑，在此再简述一下早期软件开发：

• 早期程序员什么都给会：对所要开发的软件的所有环节都有透彻的了解，从规格说明书编写、到软件开发、到测试、到部署、再到技术支持；
• 随着业务的扩大，程序员群体内部开始分化为：软件工程师、网络管理员、数据库开发者、网页开发者、系统架构师、测试工程师等等。而网页开发者又能很快进化成后台开发者，前台开发者，PHP开发者，Ruby开发者，Angular开发者等等。

分工之后的传统的软件开发流程是这样的：

• 软件开发人员编写代码，然后将代码交给QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去布署。所有的这三个阶段，即开发，测试，布署。早期所采用的软件交付模型，称之为“瀑布（Waterfall）模型”。

只是，这种模型比较理想化：

• 适用于用户需求非常明确、开发时间非常充足的项目。大家按部就班，轮流执行自己的职责即可；
• 但是，项目不可能是单向运作的；客户也是有需求的；产品也是会有问题的，需要改进的；
• 于是，软件开发团队引入了一个新的概念，那就是大名鼎鼎的——“敏捷开发（Agile Development）”。

敏捷开发在2000年左右开始被世人所关注，是一种能应对快速变化需求的软件开发能力。其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点（有关于敏捷开发的大致定义我就不赘述了，相信大家都有一个概念）：

但是！

• 敏捷开发虽然大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈；
• 对于做运维的人来说，他们的核心诉求就是“稳定压倒一切，天生排斥“改变”。（深有体会…原来做开发的时候还和运维吵过架2333）；
• 开发人员（Dev）和运维人员（Ops），一个跟随客户需求经常迭代版本，一个运维老版本讨厌版本迭代，而DevOps就是用来解决这一问题的工具/思想，用于协同敏捷模式下的开发和运维。
  

而这些年DevOps逐渐火了起来的原因，我认为是因为以下原因：

1. DevOps中的一些关键步骤，例如自动化运维（基础设施搭建）等等，在原有的技术条件下难以实现，随着云计算、Docker、IaaS这些概念、工具的星期，为DevOps提供了技术支持；
2. 大公司本身没有追求小而快开发模式的动力，而国内的小公司在前些年往往都属于野蛮生长的时代，对于软件项目开发没有足够的关注，其关注点可能还是在业务方面。现在随着市场的成熟，人们对于软件项目开发的关注度也在逐步提升。

最后补充一下，DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会，为了在Twitter上更方便的传播，由DevOpsDays缩写为DevOps。

2、什么是DevOps

首先，至今为止都没有一个权威的定义来说明什么是“DevOps”，所以接下来我将从一些角度来尽可能地描述DevOps是什么。现在，我们先来看看维基百科对 DevOps 的定义。不过，估计也没谁能看懂这到底是在说什么。

DevOps（开发 Development 与运维 Operations 的组合词）是一种文化、一场运动或实践，强调在自动化软件交付流程及基础设施变更过程中，软件开发人员与其他信息技术（IT）专业人员彼此之间的协作与沟通。它旨在建立一种文化与环境，使构建、测试、软件发布得以快速、频繁以及更加稳定地进行。

我从字面上来理解：

• DevOps 只是Dev（开发人员）+Ops（运维人员），是指“开发运维一体化”，使得运维步骤能跟得上原来敏捷开发的节奏，促进开发和运维人员的沟通，增进彼此的理（gan）解（qing）。
  

但随着DevOps 发展，我发现广义的DevOps 其实是一种软件研发管理的思想、方法论，他追求的是一种研发协作的状态，可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 广义的DevOps 的范畴。（不过在此不讨论广义的DevOps）

总而言之，个人理解，狭义的DevOps = 敏捷开发 + 敏捷运维 + 全过程标准化（最好自动化）。

3、DevOps的优势

DevOps 通过大量工具（后面会提到）可以实现高度自动化，制定一条从开发到运维上线的流水线，最大程度地摆脱人工的不稳定因素，实现标准化，甚至用数学语言进行整个过程的精准描述（因为标准化，我猜想甚至能够实现形式化的软件开发方法，哈哈，也算是联系之前的那次 形式化软件开发方法 的论文），实现企业生产力升级。

比如具体到功能，可以做到：

1. 持续的集成与开发，实现从开发测试、上线运维的一体化自动流程；
2. 智能预警帮助用户自动监控集群运行状态，快速定位到问题具体发生的位置，及时通知用户以快速解决问题等；
3. DevOps 另外一个好处就是会改善公司组织文化、提高员工的参与感，不仅是开发，运维人员以及客户都可以参与整个软件项目。

4、DevOps工具

• 这一段时间在网上大致看了看DevOps的相关文章和博客，感觉现在大家在DevOps领域最关注的，或者说一般提及DevOps，说的往往还是在面向运维人员的工具。

• 当然，目前也出现了一些集成这些工具的DevOps平台，不过个人感觉这些平台都没有打出很好的知名度，在网上的评价也过少，还需要时间的检验，所以就不列举了。

• 而DevOps工具，一般涉及编码、构建（构建就是maven这种帮助我安各种包，版本检测之类的工具，写过Java的人应该知道）、测试、打包发布、配置、监控等方面。大致可以分为以下几类：

  1. 监控工具
  2. 性能分析/APM工具
  3. 批量+自动化运维工具
  4. 集中日志分析工具
  5. 持续集成/发布工具
  6. IaaS集成

（1）监控工具

• 比较老牌的就是Zabbix,Nagios，用Zabbix的感觉是最多的。国内的有小米开源的OpenFalcon；
• 这类监控工具一般是对服务器、服务（中间件，数据库）做一些常用指标的监控。

（2）性能分析/APM工具

• APM很多时候被认为是监控的一个细分领域。但在现代复杂分布式系统架构下，APM工具往往更能准确、直接的帮助用户定位到性能瓶颈，比如哪一个URL访问慢、哪一个方法执行慢、哪一个SQL执行慢；
• 在以往要想拿到这些数据，往往得需要比较资深的架构师、DBA一起合作才能拿到这些数据，而定位瓶颈的效率往往还不太高。现在通过APM工具能让普通技能的运维人员，也很高效的定位到这些深层的问题；
• 现在商用的APM工具不少，国外的有Newrelic，国内知名的就有听云、Oneapm、透视宝这些。开源的也有Pinpoint（naver开源）、Zipkin（twitter开源）、CAT（大众点评开源）。

（3）批量+自动化运维工具

• 这里就比较多了，知名的有Puppet（基础架构构建）、Ansible、Chef、Saltstack，这些工具的目的是让用户极容易配置和维护数十台、数百台、乃至数千台服务器。通过自动化和协调技术简化任何基础设施的日常运行和维护难度。

（4）日志分析工具

• 在一个服务器比较多的环境下，如何集中的管理和分析、查询日志，已经变成一个比较强的需求了。在开源领域，比较知名的就是ELK这一套工具了，涵盖了日志采集、上报、搜索、展现这一类基本需求，现在比较多的上规模的企业都用这个；
• 核心实现机制都是通过一些日志采集代理（类似Filebeat）去爬日志文件，将最新的部分提交到采集服务端，后端再对接搜索引擎，能支持很快速、准确的搜索即可。

（5）持续集成/发布 工具（个人感觉这个是DevOps中比较重要的部分）

• 部署应用程序是运维的一项重要工作，发布部署的频率从原来的的几周部署一次，到后来的一天部署十几次甚至几十次。这样手工部署就完全不能满足需要，于是就要把整个流程自动化，这就是持续集成、发布；
• 例如Jenkins、GitHub这种软件；
• 集成打包的过程其实一般都比较简单，配好版本库和打包脚本就行；
• 但发布的过程就比较复杂，有些是全量发布，但也有非常多的IT团队采用增量发布。这个方面如果想用工具，还是得先分析清楚现有的发布流程，手工情况下怎么做，哪些能通过自动化工具来完成；
• 不严谨的讲，在我看过的资料中，很多时候，CICD工具是DevOps的核心部分。

（6）IaaS集成工具

• 最近两年的公有云推广比较迅速，很多新的服务器采购都被导入到云上去了。现在主流的公有云（阿里云、腾讯云、华为云…）都提供了比较完备的API，基于这些API也可以做一些针对基础资源的自动化操作，比如游戏行业的快速开服；
• 补充一下：IaaS是云计算的概念，与其对应的还有PaaS和SaaS，分别对应这在基础设施上的云服务、开发平台上的云服务和软件云服务（比如Office365），IaaS可以直接为用户提供开发运维所需要的各种硬件环境以及一部分运维工具，可以让用户直接远程登陆+直接进行开发。（再往深了说就是公有云相关问题了，在此不赘述）

最后，附上一张DevOps工具相关图谱，并圈出了我认为比较常见的工具（或者说我认识的…）

6、DevOps的应用前景

虽说 DevOps 优势多多，但实际情况却是说的人多，做到的很少（至少在国内，我看起来是这样）。究其原因，在于：

1. DevOps 并不是简单地将开发部门和运维部门合并，更是企业文化、组织结构的变革，是通过自动化的基础设施和自动运行系统测试来加强开发部门和运维部门之间的协作和沟通；
2. 对于传统企业，特别是大型分布式组织，在整体意义上的 DevOps 成功往往是不可能实现的。因为 DevOps 要求深层次的文化和组织变革，要改变的太多太多。

所以，至少在国内，我认为DevOps这个概念还有很长的路要走，目前为止，不论是知名度还是项目的实践，都远不如他的前辈——”瀑布开发“、”敏捷开发“成熟。

但是！随着一些新技术的普及——例如容器技术、IaaS等，会更加促进DevOps的发展：

• 因为DevOps有在测试、发布环境上保持标准化、规范化的需求，而容器——Docker的作用就是批量创建运底层运行环境（换句话说，docker其实就是轻量化的虚拟机），这一点和DevOps的宗旨相重合。
• 同时随着云环境的成熟，可能未来企业会完全在云端完成开发到上线的全过程（类似于买远程服务器一样，我可以用鼠标点点就可以配置若干主机，用鼠标滑轮选择拓扑结构，而小公司可能需要真正的去插拔网线，才能实现同样的功能），有了网络这个新工具，也能更好地促进不同功能团队之间的协作，暗合DevOps的思想。