文章目录
前言
最近有一门课，中间有一部分内容有关于敏捷开发模式，正好结合我最近在看的一个概念——DevOps，来阐述一下软件项目开发的一些观点和概念。
1、DevOps的历史由来
为了有一个完整的叙事逻辑，在此再简述一下早期软件开发：
- 早期程序员对所要开发的软件的所有环节都有透彻的了解，从规格说明书编写、到软件开发、到测试、到部署、再到技术支持。
- 随着业务的扩大，程序员群体内部开始分化为：软件工程师、网络管理员、数据库开发者、网页开发者、系统架构师、测试工程师等等。而网页开发者又能很快进化成后台开发者，前台开发者，PHP开发者，Ruby开发者，Angular开发者等等。
分工之后的传统的软件开发流程是这样的：
- 软件开发人员编写代码，然后将代码交给QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去布署。所有的这三个阶段，即开发，测试，布署。早期所采用的软件交付模型，称之为“瀑布（Waterfall）模型”。
只是，这种模型比较理想化：
- 适用于用户需求非常明确、开发时间非常充足的项目。大家按部就班，轮流执行自己的职责即可。
- 但是，项目不可能是单向运作的；客户也是有需求的；产品也是会有问题的，需要改进的。
- 于是，软件开发团队引入了一个新的概念，那就是大名鼎鼎的——“敏捷开发（Agile Development）”。
敏捷开发在2000年左右开始被世人所关注，是一种能应对快速变化需求的软件开发能力。其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点（有关于敏捷开发的大致定义我就不赘述了，相信大家都有一个概念）：
- 敏捷开发虽然大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈。
- 对于做运维的人来说，他们的核心诉求就是“稳定压倒一切，天生排斥“改变”。（深有体会…原来做开发的时候还和运维吵过架2333）
- 开发人员（Dev）和运维人员（Ops），一个跟随客户需求经常迭代版本，一个运维老版本讨厌版本迭代，而DevOps就是用来解决这一问题的工具/思想，用于协同敏捷模式下的开发和运维。
最后补充一下，DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会，为了在Twitter上更方便的传播，由DevOpsDays缩写为DevOps。
2、什么是DevOps
从字面上来理解：
- DevOps 只是Dev（开发人员）+Ops（运维人员），是指“开发运维一体化”，使得运维步骤能跟得上原来敏捷开发的节奏，促进开发和运维人员的沟通，增进彼此的理（gan）解（qing）。
其目的是：
-
通过自动化“软件交付”和“架构变更”，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。使项目内部信息能及时反馈、迭代和进行敏捷开发，提升软件交付的质量和效率。
-
简单地说，就是主要针对运维人员提供了一系列工具和思想（比如说持续集成、持续发布工具…），让其配套开发人员的快速迭代。
具体地说，用来帮运维人员解决以下问题：
- 产品在目前的底层平台上无法运行，因为这个平台（太古老了，空间不足，不支持某某版本）
- 这款产品的体系结构跟我们的（存储，网络，部署，安全）模型不匹配。
- 这款产品的（报告，安全，监视，备份，服务提供）我们搞不懂，或者由于产品的版本迭代过于频繁，学习难度大 ，所以没法把它上线发布成实际可用的产品。
但随着DevOps 发展，我发现广义的DevOps 其实是一种软件研发管理的思想、方法论，他追求的是一种研发协作的状态，可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 广义的DevOps 的范畴。（不过在此不讨论广义的DevOps）
总而言之，个人理解，狭义的DevOps = 敏捷开发 + 敏捷运维。
3、DevOps的优势
DevOps 通过大量工具（后面会提到）可以实现高度自动化，制定一条从开发到运维上线的流水线，最大程度地摆脱人工的不稳定因素，实现标准化，甚至用数学语言进行整个过程的精准描述（因为标准化，我猜想甚至能够实现形式化的软件开发方法，哈哈，也算是联系之前的那次 形式化软件开发方法 的论文），实现企业生产力升级。
比如具体到功能，可以做到：
- 持续的集成与开发，实现从开发测试、上线运维的一体化自动流程；
- 智能预警帮助用户自动监控集群运行状态，快速定位到问题具体发生的位置，及时通知用户以快速解决问题等。
- DevOps 另外一个好处就是会改善公司组织文化、提高员工的参与感，不仅是开发，运维人员以及客户都可以参与整个软件项目。
4、DevOps工具
-
这一段时间在网上大致看了看DevOps的相关文章和博客，感觉现在大家在DevOps领域最关注的，或者说一般提及DevOps，说的往往还是在面向运维人员的工具。
-
当然，目前也出现了一些集成这些工具的DevOps平台，不过个人感觉这些平台都没有打出很好的知名度，在网上的评价也过少，还需要时间的检验，所以就不列举了。
-
而DevOps工具，一般涉及编码、构建、测试、打包发布、配置、监控等方面。大致可以分为以下几类：
（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可以直接为用户提供开发运维所需要的各种硬件环境以及一部分运维工具，可以让用户直接远程登陆+直接进行开发。（再往深了说就是公有云相关问题了，在此不赘述）
6、DevOps的应用前景
虽说 DevOps 优势多多，但实际情况却是说的人多，做到的很少（至少在国内，我看起来是这样）。究其原因，在于：
- DevOps 并不是简单地将开发部门和运维部门合并，更是企业文化、组织结构的变革，是通过自动化的基础设施和自动运行系统测试来加强开发部门和运维部门之间的协作和沟通。
- 对于传统企业，特别是大型分布式组织，在整体意义上的 DevOps 成功往往是不可能实现的。因为 DevOps 要求深层次的文化和组织变革，要改变的太多太多。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
