学了敏捷,但你还不知道DevOps,就Out了「管理有度5」(devops与敏捷)

当你看敏捷的时候,不经意间出现了Devops这个词,你还在好奇,这是什么的时候,发现规模化敏捷也出现了,这个时候如果你还发现自己对这个词很陌生,那说明你的知识该补齐了,毕竟他们如果总是频繁出现,说明他们的相关性很高。

咱们以前也分享过一些DevOps的文章,不过很多人对DevOps的基础还不太了解,今天就给大家做一些介绍。

学了敏捷,但你还不知道DevOps,就Out了【管理有度5】

图解DevOps流程体系全景图–构建敏捷 持续交付的体系平台

一文全面精通DevOps

DevOps平台架构图实例(多图)

其实不只是敏捷,在CMMI、ITIL都在提到DevOps,说明我们真的很有必要对它进行一个系统性的了解了。

CMMI中提到关于Devops

1、以价值为导向

2、开放式框架

3、构建项目的敏捷性

4、DevOps

学了敏捷,但你还不知道DevOps,就Out了「管理有度5」(devops与敏捷)

图 CMMI

ITIL中提到关于DevOps

1、以价值为导向

2、Lean精益

3、Agile敏捷

4、DevOps

学了敏捷,但你还不知道DevOps,就Out了「管理有度5」(devops与敏捷)

各类管理体系其实都在走向融合,而且都需要DevOps的支持,所以你还觉得自己不需要认真了解下它么?

如果你想快速的系统性的了解DevOps,可以先阅读以下几本书:

《凤凰项目》

《持续交付》

《独角兽项目》

凤凰项目 一个IT运维的传奇故事

《DevOps精要》

如果你报考了DevOps Master认证,那你《EXIN DevOps Master WhitePaper》是必读的。

什么是DevOps

DevOps是对敏捷软件开发与精益生产思想的演进,应用于IT端到端的价值链中,使得业务基于现代信息技术,并通过文化,组织与技术变革来获得更大的成功。

这是《DevOps精要》中关于DevOps定义,定义都有其严谨性,所以往往看完定义让我们摸不着头脑。

DevOps其实是英文单词Development(Dev)和Operations(Ops)的组合,为什么要把这两个词组合到一起,最初创造这个词的人目的就是期望开发和运维能够紧密的合作,随后逐步的被扩展和衍生,下面这个“DevOps能力环”是对这种打破部门墙,进行顺畅交付的一个非常经典的一个表达。

它强调了IT专业人员(研发,运维,测试)在应用和服务生命周期中的协作和沟通;强调整个组织合作以及交付和基础设施变更的自动化,从而实现持续集成、持续部署和持续交付。

学了敏捷,但你还不知道DevOps,就Out了「管理有度5」(devops与敏捷)

DevOps能力环

DevOps的发展历史

我们为什么要了解其历史,如果我们只是想用DevOps的一些工程实践,大可不必,但是如果你的团队还对这个概念很陌生,他们不知道为什么要用DevOps,如果是这样的话,我们还是有必要花几分钟来了解下它。

DevOps起源于敏捷,是在2008年敏捷论坛上被提出的,所以现在很多人会认为DevOps是敏捷的一部分,对于到底是谁属于谁,谁包含谁,这些观念大家不必纠结,各大体系都认为自己包括别人。

敏捷认为它包括DevOps,而DevOps认为自己是它的衍生。

学了敏捷,但你还不知道DevOps,就Out了「管理有度5」(devops与敏捷)

DevOps的概念在2010年的《What is DevOps》这篇文章中得到了较为完整的描述。DevOps在2013年之后被业界快速接受,源于相关技术的同步发展,2013年,dotCloud公司推出Docker项目,同年,Google推出开源项目Kubernetes,提供了以容器为中心的不部署、伸缩和运维平台,2015年云原生的概念也逐步成熟,他们的发展助推了DevOps的快速发展。

大家可能还听说过DevSecOps,Sec是不是安全,你猜的没错,就是安全和合规性,这是在2016年开始逐步推出的一个理念。

关于历史的部分就讲到这里,大家感兴趣的可以再做进一步的了解。了解了概念、历史之后,我们再来看看关于DevOps的整体框架,也就是知识体系部分。

DevOps的知识体系

在来看知识体系前,非常想要先给大家看一张图,DevOps的道法术器,有助于大家更好的理解也应用DevOps。

学了敏捷,但你还不知道DevOps,就Out了「管理有度5」(devops与敏捷)

图1 DevOps的道法术器

“道”就是价值观,DevOps的出现核心是为商业价值服务的,通俗点来讲就是降本增效。

“法”是实现价值观的战略,DevOps这个词的组成的两个部分开发(Dev)和运维(Ops),还包括测试(QA)的紧密协作就是DevOps的法,也就是拆除部门墙的这一概念。

“术”是战术、技术,系统应用指导原则。

“器”是指具体的工具了,利用工具提升开发、运维、测试的效率和质量,或者从另一个维度来说,运用工具以实现持续构建、持续集成、持续交付。

道、法、术、器自上而下是系统思考的层次,自下而上是解决问题的层次。接下来我们就来看看DevOps的知识体系,下图就是知识体系的三个支柱和一个基础。

学了敏捷,但你还不知道DevOps,就Out了「管理有度5」(devops与敏捷)

图2 DevOps的知识体系

三个支柱分别是指规范敏捷,持续交付,IT服务管理,为什么DevOps是以这三部分作为支柱呢?

1.规范敏捷

为什么是规范敏捷,这一点很好借,首先从他的历史发展来看就是来源于敏捷的,他想要发挥作用是建立在良好的敏捷转型基础之上的,如果一个团队从需求、开发、测试、到最终发布需要至少3个月的时间,这个时候其实还没达到规范敏捷,这个时候想要应用DevOps可以暂且缓一缓,优先要考虑先让团队“敏捷”起来。

规范敏捷包括如下这些特点:

· 速度稳定(Stabilized Velocity)

· 适应变化(Adaptability for change)

· 总是能发布优质的无错误代码(Always release high quality bug free code)

另外,还有一个非常重要的概念,就是DoD(Definition of Done),完成的定义,这一点团队的每个人都必须非常清楚。

2.持续交付

从图2上可以看到,敏捷位于整个需求端到端交付的从计划、需求、设计,到开发的这一部分,而持续交付链接的是开发到部署的这一些列的过程。

那持续交付的定义是什么呢?

持续交付是指实现自动应用程序的构建、部署、测试和发布的流程。自动化是为了能够建立一个可重复、可信赖、和可预测的发布release,将一些重复的,易出错的过程通过自动化的方式沉淀到流程中,以降低可能由于人为导致的错误,同时减少工作量和提升质量。

持续交付里面有一个非重要的概念,部署流管线(Pipline)就是一套将代码从版本控制工具最终交付到用户手中的自动化流程。一般团队中一个产品会有一个部署流水线,不排除实际中一个团队有多个产品,公用一套部署流水线。

3.IT服务管理

软件交付了就代表工作结束了吗?当然不是,发布上线后要有持续的进行运营管理,保证服务的连续性和高可用性。

如果服务无法按照业务的要求保持连续性,或者无法在出现问题的情况下做到及时的恢复,对业务的正常运行会带来问题。

4.以TPS(精益管理)理念为基础

如果要追本溯源,无论是敏捷还是DevOps,最早的理念都是来自于传统制造业的精益生产实践。

《凤凰项目》中神秘的角色带主人公去参观的也是一个制造的流水线。TPS包括JIT(Just In Time)和自动化,想要做到JIT需要建立一个单件流(one-piece flow),这个单件流需要尽可能的实现自动化,并能够在出现问题时及时停止。

总结

本文从什么是DevOps,DevOps的历史,以及DevOps的知识体系三个方面对DevOps进行了介绍,看完了上面的介绍,不知道大家是不是也对DevOps也有了一定的认识呢,欢迎互相交流。

近期热文:学了敏捷,但你还不知道DevOps,就Out了【管理有度5】

  • 一文搞定PMO如何推动流程规范的落地及常见问题如何解决?【管理有度4】
  • PMO和项目经理如何建立组织影响力【管理有度3】
  • 如何做好项目干系人管理的实战案例分析?【管理有度2】
  • 敏捷项目中如何做好进度管理及其步骤方法【管理有度1】
  • PMO&项目经理如何高效解决问题看这篇文章就够了

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年5月31日 上午10:43
下一篇 2022年5月31日 上午10:45

相关推荐