vlambda博客
学习文章列表

敏捷,DevOps,傻傻不分清楚


前言

敏捷是什么?DevOps是什么?两者有什么区别?

持续集成不是XP里面的么,怎么DevOps也有持续集成?

我们之前在做敏捷转型,现在又开始DevOps转型,到底啥情况?


总觉得与其去纠缠一个定义,不如踏踏实实做点儿事情。

没必要太纠结,因为两者都在演进,两者也越来越像,否则不会有这些疑问。

原本没想写这个话题,客户问起也只是简单说明。

只是最近不断有人问起,也看到有一些误导性的言论,所以也许还是有必要说说自己的观点。


这个话题注定讨论不清,也注定会有不同的意见;

所有文字仅代表我一家之言,没必要扣什么帽子;

我本人是先做敏捷后做DevOps的,这是我的知识背景;

欢迎讨论,如果初衷是好的话,道理越辩越明

恕不奉陪,如果是以混淆视听为目的论战。

观点

先说我的观点:

  • 敏捷与DevOps初衷,目的是为了解决问题,不是为了树碑立牌,更不是为了占领地盘。

  • 两者并非泾渭分明,也没有一条线能够划出来,说哪边是敏捷,哪边是DevOps。

  • 讨论敏捷与DevOps,目的是为了了解两者之间的内在联系,而不是为了划清界限。

  • 常常在讨论的,是狭义的敏捷与DevOps概念,而广义的敏捷与DevOps,已经趋同。

  • 两者都是试图去解决相同,或相近的问题,只是革命尚未成功,同志还需一起努力。

  • 傻傻不分清楚,是不想分太清,没必要分清楚,难得糊涂。

狭义的敏捷和DevOps

狭义的敏捷与DevOps,也许是你想听到的两者区别。

强调一下,这里说的,注意是狭义而不是狭隘;有狭义就有广义,如果你坚持固守狭义的概念,会不会有点儿狭隘了呢?


传统的敏捷是为了解决第一个gap,即业务与开发之间的鸿沟。通过敏捷宣言中强调的个体和互动、可工作的软件、客户合作、响应变化,以及12条原则中的尽早的以及连续的高价值交付、自组织团队、小批量交付、团队节奏、可改善可持续的流程、保持沟通等,以及包括Scrum、Kanban、XP在内的众多管理和工程实践,来实现开发与业务之间的频繁沟通,快速响应变化。


而DevOps的出现,是为了解决图中的第二个gap,即开发与运维之间的鸿沟。前端的敏捷的确是快了,却发现因为Dev与Ops之间的隔阂,无法真正的将价值持续的交付给客户。

开发侧很快,运维侧太稳,这个就是我们常说的开发与运维之间固有的、根因的冲突,即下图中的混乱之墙。开发(尤其是“敏捷”后),求的是快速响应变化;运维,求的是稳定、安全和可靠的服务;更重要的,两者的KPI度量指标,绩效考核激励机制不同,决定了如果为达成各自的局部目标,势必存在无法调和的根因冲突。

DevOps的出现,就是为了打破开发与运维之间的部门墙,从这点上来说,我支持DevOps是敏捷在运维侧的延伸这一说法。只是,敏捷与DevOps,都已经不再是原来的那个敏捷和DevOps了;世界变化太快,问题域发生了变化,解决方案域自然也要随之变化。

敏捷,DevOps,傻傻不分清楚


广义的敏捷和DevOps

敏捷的好处是,有一个敏捷宣言,宣告其诞生;敏捷的缺点,也许也是因为有敏捷宣言;敏捷宣言并不应该被拿来约束和限制敏捷的范围;敏捷宣言也说拥抱变化,宣言诞生于2001年,时至今日,应该也当然会与时俱进,只是后来再没有这样的一个标志性的事件来做声明。

DevOps的不好之处,是没有一个明确的定义;DevOps的好处,却也正是因为没有一个明确的定义做限制,所以拿来主义,一切好的东西,都可以为我所用。

DevOps是个筐,什么都可以往里装,敏捷又何尝不是呢?(这里全是褒义)

敏捷,DevOps,傻傻不分清楚

我是2012年在IBM接触到DevOps的概念的,IBM对DevOps有D2O和E2E的概念,D2O,Dev to Ops,即经典、狭义的DevOps概念,解决的是Dev到Ops的鸿沟;E2E,End to End,即端到端、广义的DevOps,是以精益和敏捷为核心的,解决从业务到开发到运维,进而到客户的完整闭环。

还有DevOps的6C概念,即Continuous Planning, Continuous Integration, Continuous Testing, Continuous Deploy, Continuous Release, Continuous Feedback,事实上,也是端到端广义的DevOps。

敏捷,DevOps,傻傻不分清楚

维基百科上的总结,DevOps的出现,有四个关键驱动力

  • 互联网冲击要求业务的敏捷

  • 虚拟化和云计算基础设施日益普遍

  • 数据中心自动化技术

  • 敏捷开发的普及

业务敏捷,开发敏捷,运维侧自动化,以及云计算等技术的普及,几乎打穿了从业务到开发到运维(当然里面还有测试),所以虽然字面上是Dev到Ops,事实上,开玩笑的说,已经是BizDevTestOpsSec了,即从狭义的D2O,前后延伸到E2E,端到端广义的DevOps了。

敏捷,DevOps,傻傻不分清楚

能力成长模型

敏捷,DevOps,傻傻不分清楚

DevOps能力成长模型,是Nicole Forsgren博士,Jez Humble以及Gene Kim三位大师,基于多年DevOps现状报告的基础上,汇聚出来的能力模型。(上图是刘征老师基于Accelerate一书,以及多年DevOps现状报告的基础上,二次创新,汇总出来的模型)

从能力模型上来看,所有的连线汇聚点,也就是最终的目的,是组织效能。软件交付和运维效能,是敏捷与DevOps共同的目标。

其中持续交付是狭义DevOps的核心理念,横跨了架构、开发、测试、运维等角色;持续交付的核心开发实践,也涵盖了架构管理,版本管理,分支策略,测试自动化,部署发布,运维监控,信息安全,团队授权,数据库管理等多个维度,其中不乏传统我们常说的敏捷相关实践,尤其是下图中XP极限编程的很多实践,半数以上在DevOps里都能找到。


能力成长模型,除了持续交付,还包括精益领导力、精益产品开发、精益管理、组织文化与学习氛围。DevOps已远远不是CI/CD那么简单,CALMS原则,也横跨了文化、管理、精益与技术。

敏捷宣言的十二条原则,SAFe的九大原则,以及DevOps的CALMS原则,也是彼此相互融合。SAFe有借鉴DevOps的理念和方法,DevOps又采纳敏捷的思想和实践,大家又都以精益为思想核心。到底谁包含谁,谁比谁大,彼此的界限在哪里呢?

小结

方法也好,实践也好,其价值应该由客户价值来体现。对客户而言,需要解决的问题,是端到端的,是全局而不是局部优化;

所以,是什么,不重要;能解决什么,要解决什么问题,很重要。


DevOps的核心,是精益与敏捷的思想和原则,所以你说到底是敏捷包含了DevOps呢,还是DevOps包含了敏捷呢?我觉得没必要纠缠,两者原本已经无法区分,也无需区分。

敏捷也好,DevOps也罢,能抓住耗子就是好猫。具体应该叫什么,你为什么要那么纠结?


DevOps是集大成者,是各种好的原则和实践的融合;敏捷又何尝不是如此,2001年的17位雪鸟大师,各自在践行着不同的敏捷框架和实践,敏捷宣言和原则,原本就是一次融合;2003年Mary Poppendieck和Tom Poppendieck的精益软件开发方法,即便是已经有敏捷宣言的前提下,不也一样纳入敏捷开发的范畴么;敏捷也是在不断前行,DevOps与敏捷殊途同归,是同一问题的不同分支,最终汇集到同一个目标。


一个好的方法论,应该是与时俱进,兼容并蓄的;应该是开放的,演进的而不是固化的。

方法论如此,学习和实践方法论的人,更应该如此,以一颗开放的心态,接纳一切合理的存在。


参考资料:

  • ”http://www.slideshare.net/JrmeKehrli/devops-explained-72091158“

  • “DevOps能力成长模型”

  • IBM DevOps资料

  • 维基百科

关于作者

姚冬 资深DevOps与精益/敏捷家,软件工程专家;中国DevOpsDays社区核心组织者之一;Exin DevOps Professional认证讲师;凤凰沙盘认证讲师;SAFe SPC规模化敏捷咨询师;认证Scrum Master, SAFe Agilist;曾任IBM DevOps产品线大中华区技术总监,金融行业Technical Leader;现任华为云软件开发云首席技术布道师。