DevOps在传统企业的落地实践及案例分享

摘要

在传统支撑模式无法满足业务价值快速交付要求的情况下,传统企业应该如何引入DevOps能力进行突破创新,本次分享将从以下几个方面具体探讨DevOps如何与传统融合进而落地:

1.DevOps的整体框架及落地方法探讨;

2.DevOps落地关键点之一:IT元数据平台的重要性及设计标准;

3.DevOps落地关键点之二:持续交付在传统企业的融合方法探讨;

4. 电力行业案例分享。

视频内容

DevOps整体体系框架

DevOps是一连串的工程实践的有机组合,其中包括敏捷管理、持续交付、IT服务管理等等。

DevOps是关注整个业务/应用/服务生命周期的管理,把业务和IT的战略进行了对齐。

DevOps以精益思想为基础,强调自动化、拉动式、“拒绝浪费、创造价值”等。

从软件研发模式看DevOps

目前的“瀑布流”模式开发中间有很多部门墙,从研发到测试再到运维,它们中间是完全断层的。断层的理念会导致我们在研发的过程中测试和运维都无事可做,这就是一种浪费。

现在做的敏捷迭代、测试驱动开发让我们组成小team模式。这种模式以业务价值流来进行交付,要能够保证快速交付产品、模块,并且是可以独立运行的。

DevOps让团队共享面向客户的价值、共享集成目标、共享质量责任。

DevOps也让运维的作用变得更加突显,此时需要全新的思维/平台/方法论来实现Dev的软件快速交付到Ops阶段,并且能够稳定地运营。

DevOps的落地经验谈

移动互联网时代的业务特征就是快!产品的决策快、推出快、迭代快、变革快,快能抓住机遇、掌握主动。

对IT支撑也带来了一些挑战,例如快速交付产品、IT支撑可灵活扩展、更高要求的客户体验、项目时间紧、需要快速响应业务/需求变化。

无法快速响应业务激增的需求:新型互联网业务对资源需求的波峰波谷现象更突出,服务对外开放使业务量的不可预估。目前临时业务无论高峰、低峰期均需要大量的人工介入,系统灵活扩展性不足。

系统维护难度高:支撑系统X86分布式集群架构改造后,应用主机多,故障定位困难;缺乏自动化的系统处理,需要大量的人工介入,处理时间长,对维护人员技术要求非常高。

不能实现敏捷开发:需要开发人员对每台服务器进行复杂操作才能完成部署,需求测试环节需要根据业务依赖关系逐一测试,开发难度和上线效率不高,很难做到敏捷开发,快速发布,持续集成。

传统架构架构简单,运维快速定位,快速发布。但支撑内部整体目标架构没有统一的规划设计,系统烟囱式建设。

转变为云化架构后,通过核心云构建,实现资源共享,和设备资源层形成联动,实现应用的弹性伸缩。但是云化架构比较复杂,需要运维过程智能化,自动化转型。

我们如何提高产品交付给客户的速度、如何改变产品更快更好满足我们客户、如何恢复故障不至于影响我们的客户、如何更快通过我们的努力获得客户认可?

打通市场需求、开发、测试、发布、部署上线、运维等各环节,促进需求、开发、测试、运维团队更紧密地合作,敏捷开发,持续交付、自动运维,提高支持系统的生产、交付效率。

理念与价值先行

通过持续服务交付价值链打破孤岛,整合开发和运维的能力成为一个协作的团队。进行端到端持续服务交付流程的变革。对新的应用和服务,加快且缩短实现价值的时间。不影响安全性、兼容性和性能。

顶层设计、全局规划

这张图是我们产品设计的全局规模规划图,但在所有公司都适用。以后无论是做运维自动化还是DevOps整体门户化,都是有一个统一运维的门户。

从小做起,Start Small

基于某个角色、某个场景从小做起,从自己做起。基于某个系统或者某个功能域来实施导入,切忌贪大求全。

构建元数据基础平台CMDB

要构建元数据基础平台CMDB,应该是自动化的。

CMDB成为IT运营管理平台的核心元数据。CMDB数据的“鲜活性”,核心靠场景驱动。

CMDB分核心模型和扩展模型。核心模型是业务、应用、主机和程序包;扩展模型是基于这个实例的关联对象。建立以应用为中心的资源管理模型。

工具也一种文化

作业管理,一方面把运维的脚本能力可视化,另一方面也在提高运维的效率和质量。

调度管理,提供面向复杂事务的能力封装。

基于作业和调度能力,面向角色场景化收敛和归类各类能力。

好的经验,通过自动化的手段沉淀,工具化,极简管理过程。工具是真正推动变革的有效手段,自底向上的核心手段。

组织二元性

服务主管,对IT服务及时性相应负责,类似Scrum的PO。

DevOps工程师,有义务提高和维护自动化流程,构建完整的自动化过程和工具,提升效率。

把关人,负责监控IT服务的运行状态和下一步发布的进展。

可靠性工程师,监控部署过程中的服务并处理正在服务执行中产生的问题。

流程主管,领导并促进团队,这个角色类似于在Scrum中的Scrum Master。

运维交付团队。分资源交付团队、应用交付团队、运维研发团队。运维研发负责运维交付能力自动化。

开发测试团队。设立测试研发团队,负责测试能力自动化。

DevOps研发团队。负责从持续交付的角度端到端的能力集成。

服务主管、流程主管角色不变。

如上图所示,等待时间和实际所用时间相差很大,这中间的浪费非常大,这就是部门墙导致的。我们需要保证每一个运转的中心都是一直在工作的。不管是需求、开发、测试还是运维,都应该是拉动式的,因为只有他自己才知道当下处于运行状态还是空闲状态。

自动化别人,先自动化自己

自动化是一个由点到线到面的过程。要先从一个小的点切入,把自动化做完之后才可以一点一点影响到周围,进行扩散。

自动化是一个逐步覆盖更多角色的过程。做完一件事再做第二件事的时候,它们都是互相影响的。

自动化也是一个环境逐步覆盖的过程,先生产,再测试,再开发。

持续交付是最佳的DevOps实践

从上图可见,开发、测试、预发布和生产所做的事有很多都是重复的。如果能把这些自动化、工具化,重复的工作就不存在了。

还要做到标准化。从开发、测试到运维,基础环境和应用架构都是标准化的。当我们把所有的事情都做到标准化、无状态化、微服务化的时候,这些操作将会变得特别简单。并且要把整个交付的过程可视化,要知道进度到了哪个阶段。

构建面向应用的最强驱动力

CMDB系统要实现向资源管理系统的过渡,应用的变更场景最终是对资源的变更,应用的状态最终是由其资源的状态来决定的。

今天的分享就到这里,谢谢大家!

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2018-01-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏DevOps时代的专栏

传奇 Netflix:全周期开发人员 – 运维你构建的内容 | 译文

1243
来自专栏IT大咖说

DevOps与传统的融合落地实践

内容来源:2017年5月6日,王津银在“DevOps&SRE 超越传统运维之道”进行《DevOps与传统的融合落地实践》演讲分享。IT大咖说作为独家视频合作方,...

39410
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙回顾|技术债

技术债 活动时间:2017年11月23日 QQ视频分享 活动介绍:TMQ在线沙龙第三十四期分享 本次分享的主题是:技术债 有72位测试小伙伴报名参加活动! 想...

2246
来自专栏理论坞

如何做别人眼中专业的交互设计师

最近发现网上可以学习的交互知识和如何去做交互设计的内容还是比较匮乏,所以想将自己这些年做互金行业的一些交互知识经验贡献出来,希望给一些刚入行的朋友看到能有所收获...

1372
来自专栏海天一树

互联网创业技术团队需要多少人

这里所说的技术团队,指的是大技术团队,包括产品、设计、开发、测试等。互联网的产品通常会包括安卓App,iOS App,PC网站,手机H5。 最不可或缺的人,...

3275
来自专栏顾宇的研习笔记

我们如何衡量一个微服务实施的成功

本次介绍的案例来自于我曾经服务过的客户 R,到今天已经5年整了。2013年的国庆后,我加入了客户 R 的其中一个产品团队,这个团队有三个项目:一个项目做日常维护...

1251
来自专栏PPV课数据科学社区

【职场】排名前20位的大数据职位及其职责,你能胜任么?

大数据在全球范围内的IT就业市场占有越来越重要的影响。根据Gartner公司提供的数据,截至到2015年将有440万的IT工作来支持大数据,仅美国就会有...

3065
来自专栏斑斓

决策技术栈迁移的因素

一. 决策技术栈迁移的因素 那么,为何要进行技术栈迁移呢?是否是原有技术无法满足新的业务需求?对于遗留系统而言,这种情况总是存在,即需要扩展旧有系统的功能来满足...

3619
来自专栏靠谱PM

产品经理入门到提升

很早以前就想写这么一个话题了,但因为这个话题比较大,没想好从哪些方向去切入,考虑了好久还是决定写一下,因为本身也在一些互联网相关的群里,经常有人问类似的问题,所...

1733
来自专栏ThoughtWorks

企业实施DevOps的七大挑战|洞见

DevOps这个词在近年来可谓大火。从2014年底我开始给一些企业做持续交付/DevOps相关的评估和咨询,似乎每个企业都表示想要推行DevOps,或者说他们正...

2876

扫码关注云+社区

领取腾讯云代金券