武汉是我国重要的科研教育基地，普通高校和本科院校数仅次于北京。10月29日，清晨的武汉下着淅沥沥的小雨，为已入冬的城市平添了几分寒意，但是在光谷万科中心却有那么一群人冒雨因华为HDG而聚到了一起，他们就是乐于求知的开发者。
这已是华为HDG的第七站，也是演讲与分享时间最长的一站。讲师演讲的精彩，开发者们提问更是踊跃，交流与分享高潮不断。他们究竟聊了些什么呢?
演讲中谈到DevOps，华为软件开发云高级架构师曾正阳表示：“DevOps给开发者带来研发模式的革新，开发人员和运维人员协同合作，确保软件高效交付的同时可以促进产品更快的面向市场，更快的得到反馈，提升软件迭代周期。”
以下是他的现场演讲实录：
大家下午好。自我介绍一下，我之前在京东做了很多年的云计算，后来来到华为做同样的事情，DevOps要把比较成熟的工具跟方法论以及整个流程搬到整个云上面去，所以我们做的事情都一样，所以今天给大家分享一下。
下午的议题分为这几个阶段：第一点讲一些概念，可能是DevOps、CD、CI，可能大家对这个概念看的比较多了，但实际上它官方的或者大家理解正确的是什么意思，有点疑问。第二点这边做一些澄清，业界谈到IBA或者亚马逊他们怎么做的。第三点比较重要的一些点。第四点华为内部怎么做开发、DevOps，为什么要做DevOps。第五点在外部也有一个DevOps的供应链，已经在华为供应链上面承载了。大概这几块，第一大家看到风格，满屏的风格是典型的华为风格，这是大头制。之前一般写拼音不这么写，就写一句话，来到华为之后受到这个影响，所以屏贴满了，也没改。
先讲一下概念。什么是DevOps，因为网上资料太多了，我们截取两个最重要的，一个是维基，一个是Gartner。这两个是比较权威的，他们怎么讲。维基里面讲是个过程方法和系统总成，所以它是一个总称，是一个联合的东西，它能够促进运维跟开发之间的一些沟通协调。Gartner怎么讲，它其实有一样，它基于里面的一个敏捷宣言，基于敏捷，从敏捷出发的，从开发的敏捷走到运维敏捷，基本上这样一个概念，所以两者我觉得核心是一样的。看看他们三个专家怎么看，第一个是DevOps名词发明者，他提出DevOps这个词。他觉得DevOps是打破开发和运维之间的一个孤岛，我们一般做开发，开发就开发，运维就运维，两个是一个部门强，所以两边打架扯皮还是比较严重的。DevOps提出来一个实践，他打破了两个部门之间的一个障碍，起到一个互相协作。
第二个人说DevOps能够提升入组频率，重点是要聚焦在我们更快地把某个功能、某个产品上到生产环境，然后让用户能够快速地反馈，从而提高这个交互的效率。
第三个人讲的是如果没有开发和运维之间的集合配合，持续交互变得非常难。什么意思?这个人是《持续交互》的作者，他的理解有点偏颇了。怎么讲?DevOps是CD的前景，因为他是CD书的作者，所以他提出来DevOps是CD的一部分。但是我觉得在日常概念里面，CD跟DevOps涉及到什么样的关系，一会儿会讲到。
第三部分讲到行业的的观点。还有人提取了三个：亚马逊、微软、IBM，提取的差不多，大家看一下就知道了。后面有讲到他们三个公司是用什么样的工具链、什么样的流程来去承接他们的理论，所以概括起来什么是DevOps，它就是一种文化，流程和工具的补充。我们讲的这个文化怎么去改变?每个公司都不一样，所以没有标准这个文化要怎么做，流程每个公司不一样，跟业务相关的。这个工具能够帮助DevOps，能够推动这个DevOps的开发。工具链整合是可以到处分享，但是文化跟流程是属于内部的一部分，可能要改进一下。这是一个统称。它从敏捷的开发走向敏捷的运维和敏捷的业务，这个都会讲到。
为什么是这三个呢?首先是从敏捷的开发再到敏捷的运维跟敏捷的业务，它们三个是什么关系?大概先讲概念，有点不是那么形象，我们看看，讲一下历史。DevOps的起源，基本上从2009年开始，很多专家提出促进的一些活动，比如一天要部署10次，以前都是一个星期、两个星期或者一个月、两个月，甚至产品大的半年布一次。它要求一天布10次，这个怎么做到呢?肯定要从DevOps两方面要考虑的。下面还有精益之类的，所以DevOps是一个从敏捷开发，它起源是敏捷，敏捷开发越来越快，交互结构越来越快，运维怎么办?要促使运维，每年开发快了之后，运维太慢了，所以会从开发促进运维，迫使运维加快脚步，让运维做的更好，所以做敏捷的运维。
敏捷的业务怎么讲?敏捷的业务是你开发快起来，运维也被你逼得快起来，之后能把一些特性、功能更快地上到生产环节，供用户来用，供用户来提供一些反馈的意见，所以它的业务就能够很快地回到业务建议，包括一些Buy、产品的形态的一些问题都会很快地反馈到研发那边，促进更快地业务开发，所以上一节也讲到从敏捷的开发到敏捷的运维、敏捷的业务，具体要怎么做呢?开发跟运维之间是怎么去合作，简单地说开发跟运维一定要协作，他们到底怎么协作呢?比如说DevOps，大家都缺工人，我直接把所有的工作扔给开发，开发自己做运维，做的也不对。运维丢给他以后不管，这个图就讲到开发跟运维怎么去协作。第一研发要把产品交付给运维，要传递一个产物，交付件或者是软件包，交给运维，更好地促进运维气氛，包括部署、监控、反馈、系统的一些迭代。同时运维也要反馈回来。以前我们基本上是开发者开发一款软件包，就扔给运维，全部不管了，有问题运维打电话，你这边出问题了，赶快解决，所以这两边几乎不干涉。这边运维必须要反馈给研发，因为研发在线上的一些问题，用户反馈连接问题，比如说PBS太低了，还说页面太乱了，还是其它的问题，运维要及时反馈给研发，这两个是互相反馈的。这是一方面。
另外一方面，他们既能互相传递，就是开发者把整个业务要到运维，到运维之后一开始就会参与到业务的开发当中，整个业务的架构和初期的架构会怎么去搭合理。运维从一开始就要参与到研发过程当中，从研发的角度来说运维有些规范，肯定要提前去遵守，这是运维传递给研发的，你要根据我的一些要求来做，这样应用不会那么容易挂了，容易规范。在前期提供脚本、检查脚本，这个在目录的什么结构，定一下规范，这是运维传给开发的一些技能，所以两边互相参与的。这样的话DEV和OPS两者目标是一致的，以前开发跟运维目标不一样，开发要尽快，我要快，运维是我要慢，我要维稳(保持稳定)。DEV之后有一个文化，这个文化怎么驱动呢?我们要把他们两个弄在一个团队里面，他们的目标是一致的，这样的话目标一致，做事情比较好办了。
它们之间前后有什么区别?以前做的开发基本上都是计划比较多，计划比较长，像半年、一年，这都是很常见的。会议也多，每天一堆会议，会议要去做什么?要去猜测用户的行为，猜测用户需要什么，所以都是猜测，以假设为依据，专注于计划，缺乏一些合作，组织也不灵活，运维是运维，可能开发、运维、测试和其它部门，分布在不同的部门，所以组织不太灵活，最关键是流程，流程特别复杂。要从一个开发到上线开展要通过不同部门的审批，开一次会领导审批。
用了DevOps之后，流程简化了，文化的整改，能做到这些。DevOps之后把文化和流程统一之后，会议肯定少了，交付也快，关注用户的交付价值，同时团队也比较专注，比较灵活，不像以前那么死了，基本上这是不同。
我们一般讲到CD、CI、DevOps，他们到底是不是一样，是不是互相包含一些问题。这边讲到2个CD，CI到开发、运维、测试、部署到验证这几部，这是CI的范围。CD就是持续交付，持续交付跟持续部署的区别在最后一步，你是不是自动化到生产环节，所以交付到验证之后可能会手动地，经过一系列流程，后面就不管了，怎么交付到生产上去就不管了，只是初步出了这个软件包满足要求就截止了，这是Devlivery的一个范围。持续部署就要全程自动化，这是持续部署的含义。DevOps跟它有什么关系呢?DevOps实际上是一个环，但是它们三者，DevOps跟2个CD是一个活动，一步一步地，DevOps是个活动，一个流程的环，它从研发到部署之后，它通过操作监控，要把这些意见、用户日志反馈到研发，研发再从中间提取一些需求，来进行新一轮的迭代，所以它不是一个单向的，这边相当于是一个单向的。所以它们之间其实没有任何的包含关系，它们之间的概念不一样，包括CD、CI是一个活动，DevOps是一个文化流程，统一的一个简称。第一页讲到(14：50)的作者，他认为DevOps是CD、CI运转，这样显然是不合理的。
讲到DevOps的收益，讲前面两个，第一个收益占前两者一个是提升软件的部署质量，一个是更迭软件的发布。为什么提升部署质量呢?很多人认为运维布得越少，可能错误也少，布得越多难道错误越少吗?这个怎么去算出来呢?刚才讲到敏捷的开发会促进敏捷的运维，以前因为布一次基本不会出现问题了，运维也不会出现什么问题。一天布10次之后，运维整个系统和工具是不是要做一些调整和改进呢?从这个层面来说，运维的能力是越来越强，对敏捷的开发促进越来越强，这样普及量就会越来越高。
下面采用DevOps的原因，就是更快交付跟部署，减少停机。为什么减少停机呢?我们一般的做法一个月、两个月升级一次，升级一次意味着一两个月它的功能颗粒度很大。没法做到不停地升级某一个大的产品，它可能是一个大的产品，可能是一级一级升级，我一般是半夜升级，他会影响，但是影响是最少的。平均的话，如果有跨时区的、国外用户怎么办，肯定会受影响。
总结一下，开发跟运维之间一些合作，更快地交付更可靠的软件，简单来说就是又快又好，怎么样做到又快又好?甚至DevOps很重要20%是技术，技术是文化。这个文化刚才讲了，文化每个公司各异，但是技术是目前无形的，特别一些工具都会有DevOps，但是它比较零散。一般都会把这些开源的或者已有的工具拼装起来，整个流程串起来，实现一个完整的工具链。这是讲到DevOps的共赢和收益。
前面讲的DevOps的概念，还有它的好处，后面讲到华为为什么会引进DevOps，这是有原因的。第一，业务形态发生变化，我们现在新出现的互联网的一些浪潮和云计算、终端像手机的消费者产品，这个业务发生变化了，商业模式也发生变化了，以前是运营商那边开发一个产品，运营商自己来管。现在商业模式变化，运营商其实不想管那些，他要求我们跟华为一起管业务。如果运营商自己来管，他发现问题，再反馈给华为，华为再市场上研发到后面开发，他们有一个联合运维。联合运维是什么概念?华为跟运营商一起来运维这个系统，如果出现问题就很快地去发现问题，做一些落实。商业模式也发生变化，另外我们研发的模式也发生变化，包括一些IPD，现在是敏捷，包括协作很多，这些因素决定了我们要有DevOps来算周期，快速有业务价值，把用户体验快速地带回来。
这里讲到华为为什么会用DevOps。这是业界的典型的解决方案，刚才也讲了，这个是讲了，华为还没有讲。刚才讲到三个公司的解决方案，IBM有一个Bluemix，可能大家比较熟，它是把工具链服务化，做一个共有云。Bluemix前两年比较火，最近没关注到，在国内可能并不怎么样，在国外特别火。微软是新起来的，他们自己就围绕着Visual Studio、Windows那一套，围绕着Windows系列来做一个自己的生态系统。亚马逊怎么做呢?亚马逊没有特别强调DevOps这个词，但是会把内部的服务会产品化提供出来，提供在云上让大家用。它最初刚开始提供的一个服务加S3，S3是一个整组。
微软的做法基本上跟亚马逊差不多，把他们这些服务全部聚焦过来，我们重新做了一套，后面会讲一下华为的工具链怎么做的。咨询公司不看了，没有差异。
这边总结关键的实践，马上过一遍，第一个倒过来讲，第一个是环境，这个很重要，因为要完整的DevOps，为什么小公司做不起来呢?小公司就是觉得自己是不够的。最重要是基础设施即代码，什么意思呢?我们底层一定要虚拟化，能够很快地做一些升级、数据库，很快地做一些扩容、减容，这些都是云化要支持的。另外它DevOps的前提的出发点，前面一个前提我们要把这个服务化。因为我们刚才讲到一个产品要一年、半年再发布，很多机遇都失去了。为什么华为手机更新这么快，两三个月一个手机出来了，必须要快，不快市场就失去了。我们要把这个产品拆成各个服务，然后再把各个服务成各个微服务，每个微服务单独进行一些DevOps小批量的发布、升级，尽量把它B型化。所以现象6个第一个是小批量的发布越来越多。
大任务分解成可以迅速完成的小任务，微服务化的架构模式进行敏捷交付，细粒度持续向生产环节发布。亚马逊怎么做，亚马逊提供了一个面对供应链可以自己能够实现工具链，每一个服务都是单独的流水线，流水线从构建、测试、发布都是单独的。服务跟服务之间没有任何的耦合，这是服务间的一些关系，另外拆开之后它不能耦合，如果一耦合的话还是做不到并行。如果耦合，每次发布还是要把各个服务做成整体的包往外发，这样不大好。这是服务之间的。
服务内部一样的道理，因为你要把这些需求分成一个迭代，一个小迭代，滚动地去做一些开发，这是小批量的，把任务尽量细化，尽量能够做一些频率的开发。这个部署自动化很重要。部署自动化以一致的方式自动化将应用部署到各个环境，什么意思呢?一次打包，随处部署。我们经常碰到什么情况呢?你测试完、开发完、生产完以后，可能要打包，它们之间的配置都不一样，所以要重新打包，这样就违背了这个概念，我们要一次打包，能够在各个环境里面，α、β、γ各个环境里面部署，一次打包，多次部署，而且还不能做一些手动修改配置，你可能做一个配中心或者一些其它手段，用黄金变量去解决问题。为什么会这么多环境呢?包括功能测试、集成(25：30)这些环境，就是最快地测试先做完，比如说你到α环境，功能测试好，测出来有问题，立马就能够做一些回稳，这样能够避免到生产之后发现问题。每一个环境都有它的意义，等会讲到三个环境特别是什么意义。这是自动化部署，我们会讲到α、β、γ，还有(26：00)这上面几个概念应该是华为内部的一些说法。
灰度发布。灰度发布，大家应该都比较清楚。一个新版本上了之后，100台机器全部上100台机器，如果有问题，全歇台了。昨天我上1%，1%上去之后第一分析流量会少一点，比如100台先升1台，整个启动流量是有限的，所以会观察产生的数据、日志是否能符合你的预期，技术判断来不断扩展你的范围。如果你看到1%，可以指挥1%，不用备份整个系统，所以DevOps基本上基于用户来发生的，根据功能、兼容性、并发和性能选定发布批次的范围，来做一些平滑的发布。
这个分为两种，一种是灰度部署，一个灰度发布。灰度部署就是在部署的时候不是一下分布的，而是一台一台，或者先10台，后20台、50台这样部署。部署之后你要对外面开放有一些策略，发布一些策略。所以说这个灰度发布的测验引擎也是比较重要的，所以我们作为DevOps的灰度发布没那么简单，你要做一个灰度发布引擎，做一个自动化的部署系统。
监控也必不可少，有三个等级，第一个是那些比较基本的，但是要做到分级监控，应用监控，所以这个是应用级别监控，应用的(28：00)监控。另外你要做一些核心功能的结构，比如说支付的。支付里面占的比重比较大，对支付的功能做一个重点监控，这是监控的范围。
(图)这是讲到运维。监控讲完之后肯定是个数据反馈，你要把线上的问题反馈到研发区，怎么做呢?你要把生产环境用户行为，服务它本身的一些业务日志全部采集到，采集到以后，后台应该有一个大数据平台来做一些分析，做一些汇聚，分析出这些原因，比如用户哪个页面点得最多，用户在论坛里面反馈的这些问题和关键字，比如说页面太慢、太丑了或者怎么样。做一些大数据的分析，产生一些报表之类的，或者去挖掘用户潜在的一些预期，可以通过大数据平台来分析的，这个是要反馈给研发的，所以这块运维必须要做。监控要反馈，运维不只是部署，部署完了后面还有反馈，所以这是讲到比较重要的一些实践。
下面讲到华为的解决方案，特别是内部的，内部有一个DevOps工具链完整的。它分为两大块，被理解为是一个研发区的流水线以及生产区的流水线。研发区的流水线提到α、β、γ三大块。生产区到外面去了，因为华为内外的网络是隔离的，所以要分内部和外部。中间解决从研发到生产，中间是流程，刚才讲到DevOps作为三块：文化、工具、流程。(图)这个图一个是工具，一个是流程，比如要数据库、专业链、监控，把这些勾起来，勾起来就会产生一个代码的框架模板。每个产品线都不一样，先生这个产品线的框架模板，比如说这个产品是基于MIC来改造的，可能里面一些都改，你有自己的框架，要针对自己的框架之后自动提到里面去，这边有一个代码仓库。你会通过IDE下来代码，进行一些自己的开发。同时这个服务的设计，刚才讲到服务的框架，服务的框架照搬亚马逊的那一套。
第二步就是一般来说我们上一个产品会涉及很多部门和合作人，今天找一个人审批，万一他请假了或者不在，或者没空，明天再找一个人不在，做了一个自动化。第一步我们会把自动化指标全部采集到，做一个参考，以前怎么做的，以前华为通过在各个系统里面去倒出质量的报告，然后做一个Word文档，做一个附件贴在那个系统里面。我们现在改了，做了自动化采集，从各个系统里面去采集出来，他们就不用去贴了，领导看了，你不知道贴出来是真的、假的。但是通过自动化采集之后，就不更改了，而且比较客观的。有一次的审核，一次审核把所有相关人叫在一起，我们开一次会就够了。这样每一个指标的采集自动化有一次会议就没了，没了之后就会说明这个版本符合效果。往下的话就是一个变更管理，因为上到生产环境，生产环境跟运维页面式开发的，这边是运维，运维要什么时候操作呢?所以面临一个管理，你符合要求，不一定表示你现在就要上线，可能白天10点、11点压力比较大，可能会到下午的时候操作，所以有一个运维管理。运维管理通过之后运维才能进行操作。谷歌目前比较流行什么?谷歌SIE，它基本干这活，基本上研发跟运维衔接的一些工作，都是它来包的。这样研发流水线已经完了，通过流程的自动化到生产环境。
生产环境的流水线通过一个消息机制来判断，第一变更管理通过，第二你的包到位了，包会到版本仓库里面去，按照这两个到位就会自动触发生产环节流水线。生产环节流水线就比研发复杂一点，刚刚那个图1%、30%、100%会不会去发布?不像前面可能是自动的到每一步，如果测试之后就会自动的。生产环境可能手动的，1%之后你会看一下可能手动的流程，你去页面看一看，点一点也好，如果你觉得没问题，是自动的，这是可选的，一直到生产环节，生产环节用的比较多，1%、10%、30%、50%、100%。完了之后它有一个(37：15)所以生产环境一直在监控服务的SOA，包括它的KBS、TP99、成功率和监控。监控完之后会自动提单。比如我在生产环境自动化测试发现一个问题，它会自动提交到一个工单系统，工单系统SIE看到之后，它觉得这是个问题，就会把这个问题反馈到需求跟管理第一个环节，所以就把整个缓冲起来，这也是SIE的数据分析，刚才也讲到一些数据分析来作为新一轮迭代需求的一个输入。只能这样讲，没有产品的截图，大家如果要了解比较细的话，内部一些细节，包括大数据怎么做的、部署怎么做的，部署做什么，使用什么开源工具，这些点跟(38：25)站业界或者跟其它公司有区别的地方就是(38：32)跟亚马逊，亚马逊的Bluemix不是统一的。华为内部产品线比较多，所以我们服务商界有一个扩展功能就是用户产品线可以自行定义它的框架，提供统一的框架，上他们可以做一个插件。
部署系统也一样，整个华为公司不可能只用一个部署系统，所以部署系统对接行业不同的服务系统，包括虚拟机、容器、特别的，都会在这个平台支撑。所以底层会华为的实际情况密切相关的。当然底层还比较重要，底层是提供云化的。基本把整个线弄完以后，华为要适配各种各样的产品线，同时还要从页面上要保证用户进来，他觉得是一个产品，也就是部署系统，你听到这个DevOps整个系统，我选任何一个部署系统它的页面都是一样的，它的配置都是一样的，所以能够做一些抽象化。这也是这个平台的优势。
讲到内部的一些东西。内部我大概统计了一下，一共有16个独立的服务。每个服务有十几个微服务，加起来可能有两三百个微服务，来组成这样一个大的系统。这是内部的，所以拿不出来，我也没办法。华为为什么有区别呢?华为内部的业务更复杂，产品可能更多，对外稍微聚焦一点，它聚焦在开发上，包括它的实现方式不用考虑兼容系统，比较纯粹。基本8个方面，通过项目管理、IDE管理，IED管理就是项目管理、配置管理、代码检查、编译、构建、测试、部署、发布。8大作用目前已经正式对外公测，所以大家可以上到软件开发上面做一些体验。
(图)上面讲到一些部门，刚才已经涉及到了。这也是一样，从这条链开发环境、测试环境、类生产环境、生产环境都可以在华为企业云上面来承载，同时不光有这条链，这条链让你开发之后，这个平台还有企业云作用，包括你的存储、RDS，如果需要容易容器的话，上面也有。所以它形成了一个开发者，基本啥都不缺了，这是一个状态。
DevCLoud到底怎么用?我们有一个Wed客户端和移动端、IDE，我们一般都用本地的，但是本地的只能做一些配置，比较方便。如果换台机器，换到别的机器，到另外的环境怎么样，所以我们这边提供的Cloud IDE，同时你有自己的IDE把这个插件放到自己的IDE里面去，能够方便地跟这些系统进行交互。IDE插件跟他们对接，我们这样提供了一个API，有这个渠道，这个就是体验。现在我们开发的公测阶段，大家可以体验一下，还有一些奖励。
现在项目管理和配置管理，配置管理就是DITER(音)。它体验有些限制，比如说项目管理。项目管理目前支持免费的5个人，还有DITER(音)免费的话是600兆，后面还有一些测试、编译，还有其它的要求，可能免费的话有些限制，但基本上够用，大家可以试用一下。
(结束)
