专家观察 | 景韵：“云在DevOps中的典型运维场景与实践”

《专家观察 | 景韵：“云在DevOps中的典型运维场景与实践”》要点：
本文介绍了专家观察 | 景韵：“云在DevOps中的典型运维场景与实践”，希望对您有用。如果有疑问，可以联系我们。

由工业和信息化部指导,中国信息通信研究院主办,业界知名组织云计算开源产业联盟(OSCAR)承办的2017全球云计算开源大会于4月19日-20日在北京国家会议中心顺利召开.本文为本届大会嘉宾分享的大会演讲速记内容,敬请浏览.

嘉宾介绍：景韵

公司职务：乐视致新SCM工程师

大会演讲速记

我叫景韵,来自于乐视,现在在乐视致新负责智能硬件这块软件配置的一些业务.

之前我在用友也是在做DevOps的推进工作,之前用友和阿里云有一个深度的合作,在这个过程当中有积累一些DevOps和云之间的经验或者教训,今天跟大家来一块分享一下.

今天想讲两个,一个是DevOps,另外一个是云原生应用,今天早上我看在主会场也有人提到这一块.我把DevOps一些核心的东西提前跟大家剧透一下,让大家更容易吸收.

首先想问一下,在座的听说过DevOps的有吗?看大家都比较腼腆.现在国内的很多大型企业、小型企业都在做DevOps.我之前在内部讲这个.

我们了解DevOps的人都会听说过DevOps年度报告,这是2016年最新的数据,我们在乐视内部讲DevOps时候一定会给大家提这个.

现在很明显,大家可以从图上的数据看到,一个叫高绩效,中等绩效,一个是低绩效,很明显大家能看到差距是非常大的,包括这种部署频率.

部署频率和交付时间缩短很明显,比如我之前在用友,可能一年会部署一次,但是现在不一样,在线服务的一线会部署很多次,需求交付到我们手上之后,别人可以很快去交付,包括市场的变化,还有用户的需求的变化都会影响到我们最终交付.

后面是变更失败率和故障修复时间,这块有一个非常明显的感受,我们在处理一些故障的时候,分分钟都有金钱上的内容,比如我们做互联网P2P的,他宕机一分钟就会有多大的损失.

为了帮助大家更容易理解DevOps,我认为DevOps起源于敏捷,但是它高于敏捷,我们可以从三方面.

从最开始瀑布模式,瀑布模式可以看到开发、测试和运维,这块是最终一个价值交付的时间点,在整个过程当中价值是没有交付的.后来变成敏捷这种模式,敏捷之后开发测试相亲相爱在一块,但是价值的交付依然是在最后的时间点.没有价值真正交付到线上的,这是我们所说的DevOps需要改变的内容.

我们在DevOps下,开发、测试和运维是在一起的,我们要共同为业务去负责,这块大家可以看到每一个迭代我们都一定要做上线,甚至一个迭代当中我们要去做多次的上线,就是为了把我们的价值更快的交付出去.

通过刚刚那个例子可以了解到整个DevOps从敏捷起源,最开始也是我们的IT运维工程师希望通过敏捷的工程方法去解决运维的问题,所以提出了敏捷运维的概念,逐渐演化,最终形成DevOps.

大家可以看到这是维基百科上官方的概念,非常抽象,涉及的角色非常多.关键词是沟通、协作与整合,我们在提DevOps的时候,很多时候我们会去提DevOps像一种文化,就是因为更多强调大家相互之间的沟通和协作,目的很清晰,就是为了更快速的交付产品、软件和服务.

下面我们具体理解一下,我们说DevOps的时候,刚刚大家也看到,它什么东西都有,都在做,这就是说DevOps是一个集大成者,一定要去理解在整个的软件工程.

我们之前提到软件危机之后,大家在总结一个软件工程的疑虑,大家希望通过工程的方法解决我们的软件危机.

日本丰田企业有一个GPS丰田的制造系统,这里面DevOps也会去借鉴GPS当中的经验,从GPS这块发出了精益这块的内容,精益衍生出精益创业.

我们提到TPS,因为它是在生产制作行业,我们把GPS当中自动化、看板这些应用到软件和互联网行业,我们说它相当于DevOps一个具体的应用.持续集成,一旦遇到问题一定要停下来,修复它.

精益具体的事项,包括这后面精益创业里提到要度量、学习的过程,这个就会把它的工程化,相当于我们要去使用它当中的一些实践.

DevOps要解决的是打造一条服务的供应链,通过这条供应链帮助我们团队交付真正业务的价值.敏捷,解决了我们研发测试这个环节,还有前面产品这块的内容,包括需求怎么去写,怎么去拆分的内容.敏捷应用到端到端,它不仅仅是到这个包打出来就ok了,一定要部署到线上.还有ITIL和ITSM.

这个是高效运维社区现在正在做的DevOpsMaster的认证培训,也是从欧洲的一个相当于非常强的一家机构引进来的培训课程.

当时我去参加这个培训之后,对整个DevOps的知识体系有更全面的理解.我之前一直直接整个DevOps只是在这个环节,但是现在不一样了,为什么要延伸到这,要有敏捷,一直要延伸到前面,就是说整个DevOps一定要为业务负责,不仅仅是在工程领域.

这里可以看到整个交付的生命周期的过程,整个过程映射到不同的环节,这块一定是训练有素的敏捷,包括现在有很多同事专门在做校验,包括之前在用友也有专门校验的团队.持续交付就是我之前在用友重点攻破的内容,由于会使用全开源的技术,去打造一条持续交付的链条出来,为了让我们的问题更快的去暴露,更快的去把一个质量跟高的包打出来.

在之前没有做这块,很多时候由我们手工去做的.很多时候在做现场的时候,完全是由我们的开发人员自己把这个包打出来,大家可以想象这个质量会有严重的问题.

下面是整个的知识基础,精益还有TPS这块,包括自动化的内容.

用心的同学可能会看到上面缺了一块,开发之后直接是部署,为什么没有测试,当时我们在学习的时候,明确强调了,我们的测试是一种能力,要嵌到每一个环节,要把测试融入到整个开发过程当中去,不仅仅是到最终部署然后测试这么一个过程.

我们现在的流程是,因为我们做智能硬件,大家可能说这个过程是比较复杂的,我们的一次编译可能都需要一个半小时的时间,而且在过程当中可能会产生大概200G左右的文件,打出来包也在10G以上.对我们来说失败的成本是非常高的,所以我们要用内建质量的方式.

在编译的环节,我们要把很多的质量检查的东西做进去,包括我们后来做一些扫描,还有编译过程当中做的findowner的机制.在做需求的时候,可能测试也要帮助产品经理去分析一些问题.

DevOps能力模型,研发运营一体化.核心的要有能力共享,要有内建质量,自动化,还有反馈.这里面要提一下责任共淡.

开发和测试,质量非常重要,一定要把它做起来,而不是说仅仅是CM的工作、测试的工作或者开发的工作而已,大家共同承担.可视化.

整个你在做的过程中,一定要把你整个的过程还有你的质量都要可视化出来,过程比如说使用看板,看板接入到运维的环节,可以把很多东西和整个的交付链条清晰的看出来.包括质量,度量代码质量,还有通过专门的报告去度量代码的功能和质量.敏捷研发大家很熟悉,持续交付,技术运营,比如做监控预警,去做日志的管理,去做自动化部署.

前面把DevOps的一些基础的东西给大家做了一个简单的介绍,DevOps本身是一个比较大的概念,涉及到的东西也非常多,让大家有一个整体的了解,知道它有什么内容.这块还是想跟大家提,DevOps虽然非常大,但是大家可以从自己手上的工作开始做起.

过两天会去深圳GOPS大会,通过绞杀者的模式,为什么叫绞杀者,热带植物有一种绞杀的现象,种子落在树上,它可以逐渐长出寄生根,把原来的树咬死,形成新的树木.核心的意思是从大家的工作当中入手,从持续交付去做,更多的往我们的运维侧做一些工作,能把一些包括我们的质量和编译的信息,更多的延伸,让我们开发更多的了解.

后面讲一下从DevOps角度怎么看云计算.从我的角度认为,云能带来的对DevOps的两个维度.

一个是快速构建应用,因为DevOps核心的是要帮助我们的业务实现,尤其是中小企业或者刚刚初建的企业,可以开素构建一个应用,build完之后去做度量,知道客户到底买不买账,然后我们再反过来做学习的过程.

快速构建应用,之前在用友做的时候,大家刚开始用阿里云的时候习惯的使用他的ECS,直接使用他虚拟机,包括数据库都搭载在虚拟机上.其实我不赞同这种方式,需要更多使用云服务,包括也有很多研发云这样的内容,可以很快定制出来一个移动端的App,包括像腾讯里做云服务的测试.还有持续交付这块也有很多的云服务.

运维这块也有很多云服务,大家都知道做DevOps这块有个叫老王的人,非常厉害,他们自己开发的DevOps的产品,也有云上的服务,很容易帮助我们做快速的构建应用,包括运维的过程都会有.

规模化,有个例子,滴滴在做了一段时间之后,尤其是在打价格战的时候,当时预估只有10%的用户增长,后来500%,整整50倍的增长.现有的这种技术能力已经没有办法做支撑,联系到阿里云做了一个7天7夜快速的重构,把整个滴滴的架构搬到了云上,实现了非常快的规模化.

包括新浪微博做Docker和阿里云集成的时候,也是基于这样的考虑,因为现有的机器已经没有办法再做,甚至我们的机房已经没有任何的位置,这时候需要去使用云的一些能力去做到快速的规模化.

这是我自己结合我们的经验总结出来的DevOps与云典型实践,并不成体系,我基于传统的IaaS、CaaS、PaaS、SaaS的模式.

第一个,在IaaS层或者CaaS,我们有一个非常基础的实践,基础设施即代码.在美国有一个竞争对手,《纸牌屋》就是他们出的,他们云计算用得是炉火纯青的一家公司,DevOps也是用得炉火纯青,交付速度非常快.他们就是使用阿里云,在每一次应用部署的时候,他不是在他的CaaS当中重新再去部署一个应用,而是完整的替换,这里面节使用到了基础设施即代码这块,他使用了亚马逊的AMI这样的技术,通过文件去定义镜像是什么样的.

包括之前看过基于AWS其他的一些实践.包括我们现在研发,安卓编译的效率对机器的性能要求非常高,我们在提供这种虚拟化的研发环境,在虚拟化的研发环境当中,我们通过OpenStack的基础镜像,加上ansible,把整个开发环境定义出来.整个安卓系统要基于芯片,类似于高通芯片有很多型号,这样我们完全把它版本化,可以很容易研发出来任何版本的开发环境
.

同时,刚刚提到不可变基础设施,他不会在一个虚拟机里部署应用,是把虚拟机直接砍掉,然后直接部署一个新的.

PaaS这块,后面有一个云原生应用,包括12-Factor.SaaS刚提到了,这里可以快速帮我们实现业务的交付,包括研发云、测试运、运维云还有持续交付云.这里要提到后端即服务,为了快速帮助研发,帮助产品去定义出来一个他们自己的产品,包括即时通讯这样的服务,还有其他的一些消息服务之类的.后面是Serverless.

讲一下云原生应用,一定要把自己的应用往云上做设计,你不是要成为像BAT这样的规模,那你把你的应用长在云上,没有问题.

这是一个AWS的架构,有智能路由、负载均衡、应用服务其,后面还有具体的缓存,还有存储、CDN、监控预警、消息服务、NoSQL、邮件,所有的都是基于AWS的服务来做,不是说自己去搭一个.

别人的技术一定比你牛,别人把这个东西做得很可靠,而且很多人支撑这样,所以你只要快速把业务实现出来.这是乐视自己的,做了一个LeEngine,这边还没有用,用了一些其他的服务.

比如CDN,我们有全球研发中心,刚刚提到,一个包就10G,每天有很多软件包,需要同步到美国、印度,这时候用他的CDN分发,包括读数据库这块,我们不再自己去运维数据库,我们自己把MySQL做一个高可用的集群,难度是有的,运维成本非常高,所以我们采用云服务.

这个是云原生基金会,他们整理出来整个的云原生的全景图.在每个领域我们基础设施,还有编排、应用等都会有这样的一些工具平台在里面.

刚刚提到12因子,我本身是做持续交付,这个东西被认为是非常重要的一块,我们要按照12因子设计出来的应用架构就符合云原生架构的应用模式.基准代码,一定大家有一个共同的代码库.

在开发环境、生产环境、测试环境、预发布环境,我们配置做部署旧好,因为我们的代码加上配置,就形成真正在线上应用的版本.这里面提到构建、发布、运行,一定要严格走这样的过程,而不是说大家直接倒出来一个东西就完了,包括后端服务,一定要使用更多的SaaS服务来做这件事情.

相信很多做技术的同事都会有这种感觉,什么东西都要自己来一把,尤其是很多大公司更是这样,一定要自己做,没有那个必要,大家去使用更多的后端服务就好了.

推荐几本书,《精益企业》,非常好的一本书,之前老王同学极力推荐,里面包括了持续交付的内容,包括企业应该搜查探索的还是发展的过程.《凤凰项目》,之前高效运维还有沙盘定制版,这里面把整个IT交付的过程描述得非常清晰.还有《DevOps Handbook》,这是DevOps之父写的.这个叫《迁移到云原生应用》,这里面12因子也做了描述.

文章来自微信公众号：云计算开源产业联盟

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4152.html