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

文章目录

6、DevOps的应用前景

前言

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

1、DevOps的历史由来

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

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

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

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

但是！

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

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

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

2、什么是DevOps

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

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

我从字面上来理解：

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

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

3、DevOps的优势

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

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

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

4、DevOps工具

（1）监控工具

（2）性能分析/APM工具

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

（4）日志分析工具

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

（6）IaaS集成工具

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

6、DevOps的应用前景

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

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

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

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