W020170419519226630521

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

之前我在用友也是在做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。这个是高效运维社区现在正在做的DevOps Master的认证培训,也是从欧洲的一个相当于非常强的一家机构引进来的培训课程。当时我去参加这个培训之后,对整个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的服务来做,不是说自己去搭一个。别人的技术一定比你牛,别人把这个东西做得很可靠,而且很多人支撑这样,所以你只要快速把业务实现出来。这是乐视自己的,做了一个Le Engine,这边还没有用,用了一些其他的服务,比如CDN,我们有全球研发中心,刚刚提到,一个包就10G,每天有很多软件包,需要同步到美国、印度,这时候用他的CDN分发,包括读数据库这块,我们不再自己去运维数据库,我们自己把MySQL做一个高可用的集群,难度是有的,运维成本非常高,所以我们采用云服务。

这个是云原生基金会,他们整理出来整个的云原生的全景图。在每个领域我们基础设施,还有编排、应用等都会有这样的一些工具平台在里面。刚刚提到12因子,我本身是做持续交付,这个东西被认为是非常重要的一块,我们要按照12因子设计出来的应用架构就符合云原生架构的应用模式。基准代码,一定大家有一个共同的代码库,在开发环境、生产环境、测试环境、预发布环境,我们配置做部署旧好,因为我们的代码加上配置,就形成真正在线上应用的版本。这里面提到构建、发布、运行,一定要严格走这样的过程,而不是说大家直接倒出来一个东西就完了,包括后端服务,一定要使用更多的SaaS服务来做这件事情。相信很多做技术的同事都会有这种感觉,什么东西都要自己来一把,尤其是很多大公司更是这样,一定要自己做,没有那个必要,大家去使用更多的后端服务就好了。

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

关注中国IDC圈官方微信:idc-quan或微信号:821496803 我们将定期推送IDC产业最新资讯

查看心情排 行你看到此篇文章的感受是:


  • 支持

  • 高兴

  • 震惊

  • 愤怒

  • 无聊

  • 无奈

  • 谎言

  • 枪稿

  • 不解

  • 标题党
2017-07-13 09:59:00
云资讯 【独家】微软Azure执行副总裁:将提高云原生应用上的投入
独家获悉,微软也将提高云原生应用上的投资。关于Azure Stack,以及不断变化的开发者平台,微软Azure执行副总裁 Scott Guthrie接受记者专访。Azure在英国地区的数据中心增 <详情>
2017-04-25 14:04:26
云资讯 华为技术有限公司首席架构师曾正阳:华为软件开发云助力企业DevOps转型
软件企业竞争已经从单一产品竞争变成生态联盟竞争,软件需求方和提供方他们之间需要做更好的协作,以便于我把握需求、质量以及风险把控,他们需要有统一的联系平台。同样软 <详情>
2017-04-25 11:54:01
云资讯 中信银行云平台架构师周海鹏:十诫 - 银行容器云建设若干问题
第一个是银行怎么能够去做容器,因为跟很多的银行同事沟通过,他们有的人POC很长时间,但是找不到一个切入点,没有上线。第二点,今天不会一直说容器的好话,因为确实容器 <详情>
2017-04-25 11:39:46
云资讯 云霁科技资深顾问张辉:金融云平台最佳实践探索
关于云,传统的IT管理,更是一种自下向上由IT基础服务向上提供资源的模式,在云时代尤其金融行业,我们转变我们的视角,不再只关注底层,而是从业务层、上层关注底层,所以 <详情>
2017-04-25 11:25:39
云资讯 成都精灵云科技有限公司CTO乔融:金融业容器云建设的创新型解决方案
金融云的监管机构要求在十三五规模末期所有的互联网相关业务必须上云,传统业务至少50%上云,这是一些政策要求,还有外部因素,首先就是互联网,比如阿里、京东这些对传统 <详情>