Home | 简体中文 | 繁体中文 | 杂文 | 打赏(Donations) | Github | OSChina 博客 | 云社区 | 云栖社区 | Facebook | Linkedin | 知乎专栏 | 视频教程 | About

1.4. 软件工程的历史与进化

传统软件工程学出现的年代互联网还不普及,主要是单机运行的软件,或者C/S结构的软件,其特点是开发周期长,迭代慢,每半年或者一年交付一次。流程主张:

		
需求->设计->开发->测试->交付
		
		

进入互联网时代,已B/S为主的软件,交付周期缩短到一个月,在传统软件工程做了改进,放弃了瀑布开发模式,提出了快速迭代,螺旋上升,管理上也逐步完善。出现了软件项目管理,CMM5软件开发成熟度模型。

互联网快速发展,使传统软件企业面临挑战,理论上互联网应用程序没有稳定版,新的特性源源不断加入,如果出现稳定版就意味着企业停滞。

互联网企业面临的问题是

  1. 需求频繁变更,一天一个想法,需求尚未成熟就开始投入开发软件生命周期短,以各种活动为例,很多功能是一次性的,软件生命周期可能是几周,几个月。
  2. 频繁交付新特性,不能像传统软件一样几个月甚至几年升级一次,我们需要应对互联网快速变化,可能需要每周升级一次,甚至每天升级数次。
  3. 随时可能回撤,随时做好回撤准备,要支持版本的任意切换
  4. 多项目并行开发,并行开发还会产生耦合依赖,升级顺序限制,集成测试更复杂。

随着Web 2.0 和 云计算思想的提出,软件也在发生变化,软件运行不在限于一台物理机,而是多台服务器的集群中,传统的模块或原件,被独立部署在世界各地。

软件的开发面临前所未有的挑战:

  1. 异构平台,软件不限于那种操作系统,例如Unix,Linux,As/400,windows,Mac
  2. 语言混合开发,不在紧紧使用一种语言开发软件。每一种语言都有他所在领域的优势。
  3. 分布式,软件再也不是只运行在 一个CPU下,软件被分成很多模块被分布式部署到多台服务上。

这时便出现了极限编程,敏捷开发….等等,同时诞生了新的岗位“产品”,新的思想不断提出,但是仍然无法解决面临的问题。

  1. 产品部:需如雪片飞来,需求堆积如山
  2. 开发部:版本延期,质量问题频发,疲于奔命修复 BUG,刚修复了一个, 又出现新的 Bug
  3. 测试部:手工测试,升级后问题爆发,测试环境通过,到生产环境就出问题
  4. 运维部:环境不统一,每次部署都是一场灾难,配置易出错,回撤时间长,
  5. 团队现状:加班严重,效率地下,每天奔波救火

测试环境无法重现,开发人员直接在线上修改代码,跳过测试直接将代码交给运维升级

运维事故严重影响运营和广告投放

人员流动导致代码丢失

问题的原因在于,他们紧紧从各自部门的角度解决问题,同时 KPI 考核也不合理:

  1. 产品从产品的角度解决产品遇到的问题。
  2. 开发从开发的角度解决开发遇到的问题。
  3. 测试从测试的角度解决测试遇到的问题。
  4. 运维从运维的角度解决运维遇到的问题。

实际上现在的软件已经不是当年交付后一个网管就能搞定剩下的工作。同时软件开发交付周期缩的更短,一周甚至每天升级数次,遇到突发事件要做好随时准备升级。

总结这个时期实际上是: 软件项目管理 加 ITSM (IT Service Management) IT服务管理

所以聚焦微观管理解决宏观管理问题的做法是错误的,于是诞生了 DevOps。 DevOps 是多维度宏观管理学,是管理的管理。