景韵：谢谢班长。我叫景韵，来自于乐视，现在在乐视致新负责智能硬件这块软件配置的一些业务。
之前我在用友也是在做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因子也做了描述。
热门专题
