在百度+当DevOps遇到AI

彭小阳

作者简介：王一男,就职于百度,现任工程效率部产品负责人一职。作为行业享有盛名的大咖，王一男行事低调，对工作热情饱满，多次受邀作为嘉宾出席各类大会，并发表了精彩演讲。

当我开始做产品以后，我更能感觉到做一个软件来讲，所有的过程包括说DevOps，一定要从业务角度出发，一定要从产品角度出发，你做出来的东西才是有意义的。做了产品经理以后，你的思路和做的纯的工程或者纯项目管理不太一样。
本次报告主要蒋在百度最近一段时间，在DevOps和AI方面做了哪些实践和事情。大概是三方面：
一、大概介绍一下百度工程效能部，来提升研发工程能力的一些方法和策略。
二、今天着重要介绍的，我们把DevOps和AI的结合分为两部分。一部分叫DevOps for AI，我们用DevOps的能力为AI的开发提供赋能，或者提供DevOps的能力。
三、更直接把AI的能力运用到DevOps本身，运用到开发、测试、运维，在这两方面工程效能部和整个百度的各个团队，都有一些实践，今天向大家报告一下。

一、百度提升研发工程能力的策略

首先，我们介绍一下提升研发工程能力的策略。无非是人（people）、技（technology）、法（process）和数据（data），共同做一些组织变革的更新或者是变化。

在百度工程效能的提升，不仅仅是工具，也不仅仅是方法，也不仅仅是教育和管理，更多是这些能力，人、技、方法的结合。
随着大数据或者是人工智能的发展，我们积累了很多、很多的研发数据。这个研发数据现在也被我们所用，反向通过数据来驱动工程能力的改进，这是我们今天给大家大概介绍的一个百度工程能力提升的策略模型。
我分别介绍一下，在人的方面，怎么样能把工程师的工程素养或者工程能力更好提升，我们刚才给大家介绍了，我们做DevOps，做敏捷，无非要提高效率和质量，为业务服务。从今以后，就要讲业务驱动，这样的话，我们DevOps能和业务结合更紧密，目标更明确一些。

在百度人的方面，我们工程效能部和百度的HR部门、每个业务线的HR BP的同学，我们都紧密配合，力争在招聘的时候，我们招最优秀的工程师。现在可能也不是特别好招了，就像后面坐的雷涛雷老师是我们招聘的优秀DevOps工程师，进入到百度。但他现在又离开了百度，优秀的工程师不太好留下。
但是，进入到百度里面以后，每个工程师自己所带的工程背景、工程文化、工程素养都不太一样，怎么能让所有工程师更好、更高效在百度的环境里做开发和做协同。
我们做了很多工程师能力的一些培养，这些培养包括工程师能力的任务模型，包括百度工程师一入职，我们会发一本小册子《百度工程师手册》，这里面详细给工程师介绍百度的工程文化、百度的工程工具、百度的工程标准以及百度的一些工程必需应知应会的标准和原则。这是在人的方面，我们重点介绍。
同时，在入职的时候，还有一个训练营。不知道在座各位同学，尤其是新的技术同学入职的时候，有没有类似的训练营。在百度，我们有为期一周的训练营，不是来培养工程师如何编程序，而培养工程师工程素养，以及如何使用工程工具（项目管理工具、代码工具、测试工具、交付工具），如何让大家在很短的时间之内学会，怎么通过工具去做持续集成、持续部署，做DevOps。
我们力争让这样一个工作法结果以后，这些工程师回到自己工作岗位，有统一的工程素养、工程素质，大家在统一协作开发的时候，效率更高。
我们和国外一些同行或者企业交流的时候，也会发现微软、Google、Amazon都有类似的工程师入职的培训，这种培训主要是工程能力。
我们说在工程能力提升、效率质量提升方面，人是最重要的。因为最终软件开发过程之中，人是最终的个体，只要把人的能力提升上去，我们的效率和业务目标才能够达成，这是第一部分，在人的方面。
第二部分，我们先说方法层次。在整个百度研发过程中，我们有300、400个团队，协同做开发，大概有12000多研发工程师，每天在写代码。

在这个过程之中，我们积累了很多工程实践和管理实践、平台治理的方法，我们过去在谈DevOps的时候，我们只谈DevOps的方法、工具，可能还会加上一点敏捷的项目管理方法和项目管理的工具。今天白老师和朱老师，都会跟我们介绍工程复用，也是提高工程效率的一个根本路径之一。只有把工程复用做得更好，整体的工程效率才能提高。
所以，在百度内部，我们不断做平台的治理，刚才白老师给大家讲了，如果说做测试，沉淀一个非常好的平台，或者沉淀一个非常好的库，是非常好的在巨人肩膀上做创新的一个基础。所以，在百度我们工程效能部，有一个特殊的团队叫做百度的平台治理，负责把百度原来400多个平台重复性非常强的，逐渐治理成为一个比较好的状态的团队。
在平台治理过程中，我们也总结了非常好的平台治理的方法。但是，大家也能看到，每一个团队或者每一个企业，也都在做一些平台治理。比如说，百度曾经平台特别多，重复平台也特别多，当时陆琪在的时候，我们梳理了一下百度，百度大概有18个同类型的报表平台。报表平台特别多，每一个业务线想要做报表数据的时候，都要做一个报表平台。
我们做这种平台治理的时候，力争让报表平台的数量逐渐下降，变成1-2个比较优质的平台。这时候当平台数量下降，有利于整体平台的复用，会带来一个问题和风险，所有业务线的需求都会向一个平台或者两个平台提供方提需求，平台的开发者力不从心，做不出来，或者做得不够快。
这个时候我们说平台的复用可能到达了一个瓶颈的状态，怎么样才能更好去让工程复用达到更好的效果呢？我们在内部推内部开源。当一个平台变成了公司级的统一平台的时候，我们会提另外一个要求，你要内部开源。内部开源以后，假设你是一个业务线，对这个平台有需求，直接贡献代码，我们给你投入，效率和工程复用能力会更高。
基于以上方法论层面上，我们总结了工程实践的方法、管理实践的方法、平台治理的方法，并且百度对外输出，在管理实践上，我们对外输出了百度方法+的白皮书，大家可以百度一下，就可以下载这个白皮书，或者上白皮书的首页看一下。

右侧全都是绿色的格格的图，叫做百度工程能力地图，从需求到最后上线，几个大的阶段里，我们需要做哪些，或者我们建议做哪些优秀的工程实践，以及每一个工程实践详细的标准已经定好了，有点像我们今天大家看到的DevOps的标准，只不过这个DevOps是一个百度通用的版本。
我们也对外输出了，大家可以搜索一下叫做《百度工程能力白皮书》，这本书是我撰写的，现在已经对外发放出来，这是方法层面。
当有了人的培养，方法的沉淀之后，我们怎么样把这些方法更好的应用人的身上，这个时候就不可避免的接触到了一个过程就是技术。那么，在这个技术方面我们更多谈论的就是研发工具，我就是研发工具的产品经理，所以我的责任就是把我们沉淀了这么多的工程实践和管理实践，更好的让大家在使用工具的时候，直接就实践起来了。
所以，在这个工具上面，我们整理了研发工具平台，把管理协同工具和DevOps工具统一结合到了一起，我们对内叫做Icafe、icode和ipipe3个平台，对外我们把它叫做百度效率云，现在已经在百度云上面开放出来了，而且现在是免费使用的，大家可以试一下。
除了研发工具，能提升整个研发的效率之外，我们还有一个工程复用的工具，这块我觉得是百度的一个特色，就是在平台治理方面，我们不仅仅是用方法推着大家走的，而是我们还用了一个平台治理的工具，这个工具我们内部叫做百度合图，它其实最开始的就是一个平台的一个黄页，就是每一个业务线的开发者，他想需要什么样的平台，他先上这个网页上搜一下，公司里面有哪些开放的平台，有哪些开放的API，然后他可以直接拿来用。
进而我们说在推动平台复用的时候，我们进而推动这个代码的复用或者代码的开源，就是当这个团队他觉得说，我想对这个平台提一些开发者需求，或者说我有一些需求想让这个平台来做，他现在可以直接点这个平台了以后，进到这个平台的源码，就是内部开源的源码里面去，直接提代码，然后去做这种协同开发。
所以，这样从平台复用，用接口的复用方式更多把它变成了一个源码级的复用，大概是这样的。大家可以看到，方法我们整理完了以后，要有各种各样的工具去支撑，这样才能把我们所说的这种优秀的实践和管理的实践、平台的实践，应用到实处去。

最后，在人、技和方法之间，其实我们由于人使用工具来落地这些方法，我们积累了大量的数据，在这些数据里面我们做了很多有意义的工作。
举个例子来讲，右侧的这个我们把它叫做工程能力地图的展示，就是每一个团队想知道目前我自己工程能力做的怎么样，我们可以把它直接展示出来，让每个团队清楚的知道我的这些工程实践有没有做，然后有没有开始做，有没有达标，有没有达到更好的标准，让每一个团队能够自主的先看到自己的一个情况。
然后根据我们刚才所说的，上面那个方法里面提供的工程能力白皮书的标准，去找到相应的研发工具，落地这个工程实践，把这个闭环做起来，让大家每一个团队自主的去做这种工程能力的改进。
除了这些工程能力的数据之外，我们还做了一些像工程师画像，平台化指数，开源贡献度这样的一些数据，去驱动你的团队来更好去做工程的复用，以及工程师这种能力的建设。
以上就是我简单的给大家介绍了一下百度工程效能部，或者在百度在工程能力提升方面主要做的一些事情，我们相信大部分在座的同学，应该都会有这样的感受，可能有的团队更偏向于工程工具，有些团队可能更偏向于管理的方法，有些团队可能更偏向于人的建设，但是百度在这边我们总结的策略，应该是把它们3个结合到一起，并且通过数据的驱动不断的去做改进。

二、DevOps和AI的结合

下面就是今天我给大家重点介绍的两个方面，就是DevOps和AI的结合方面，百度这边有什么样的一些实践经验。
首先，给大家介绍一下DevOps for AI，应该是2、3年之前开始，百度就开始艰难的在做AI的转型，到目前为止其实转型已经过半了，已经有一些的业务方向开始有一定的收入了，但是这个转型确实是很困难的。
在公司内部，你就会发现有越来越多的AI开发者团队应运而生，然后不断的在做AI产品的开发和AI模型研究，这个时候我们会发现一个比较痛苦的问题，这个痛苦的问题主要在这，就是AI的程序开发。
他的开发者和我们传统的或者普通的程序员不太一样，他们都是来自于各大高校或者是自己学习的，他们的能力更多是以数据分析为主，或者模型的建设为主，他的编码能力或者工程能力其实并不是特别的强。
所以，在这个时候我们会发现很多的AI开发，AI的产品或者AI的团队，它往往都是以实验室模式开始建立的，它刚开始是一个实验室团队，那么在实验室这个模式下面，每一个AI的开发，它的要求一般都是说你要做一些基础的研究，要做一些探索，而且要做一些通用的模型，这个过程其实是比较缓慢的。
当这个AI的模型比较ready了，或者做的比较好了，这个团队就会被赋予一些商业化的目标或者是一些市场化的目标，这个时候矛盾就产生了，由于我们很多的AI研发团队，他们都是以实验室这种作坊的形式去做开发的。
那么，当有这种市场化的要求出来了以后，就会出现各种各样的问题，这种问题主要在于说研发的交付就比较慢，这个交付比较慢主要在于整个AI的开发过程，它和我们传统软件开发的过程是不一样的。

AI开发的过程，它主要在于这样的一些流程，首先我要做数据的收集，数据收集做完了以后，要做大量的数据标注，标注做完了以后开始做模型训练，模型训练需要经过很多轮的调参，才能把这个模型训好，训好了以后然后再不断的和工程结合到一起做测试、上线，然后再做部署。
整个这个过程，和我们现在所说的DevOps其实相差甚远，无论是从效率的角度来讲，还是从质量的角度来讲相差甚远。这个时候公司就给我们提出来了一个非常明确的要求，我们怎么样能让这种实验室模式下的AI开发团队，更好的去做工程化的开发，更好的去提高他们的工程研发效率，这是我们目前面临最大的挑战。

所以，在这个地方我们再总结一下，右边这个图，就是我们经常熟悉的DevOps也好，或者敏捷也好，它是左边这条蓝线的流程，这条流程是我们从大学以来，毕业以来一直没有变过的过程和流程，就是从编写代码开始，然后做代码准入的评审，质量风险前置，然后做编译、测试，发布到一个二进制的制品库里面去，最后发布服务，最后做部署。
这是我们在座所有的同学，都非常熟悉的一个流程，而且这样一个大的过程，软件工程大概10几年、20几年里面没有发生大的变化，但是AI开发到来了以后，或者AI人工智能的程序、模型开发到来了以后，它其实部分的打破了我们交付的流程。
因为在模型训练的过程里面，右侧这个训练的过程和我们的传统的软件开发过程是完全不一样的，它的过程包括处理数据、训练模型、评估模型、调教模型，以及发布模型至仓库，当有了这个发布模型至仓库了以后，我们怎么样才能把模型和我们传统的二进制的Service制品结合到一起，并且把它对外发布出去。
因为AI的开发，最后它肯定是要部署成一个Service，用API的方式去调用这种AI的能力，或者会变成一个SDK，把它嵌到小度的音响里面去，整个这样的交付过程，在左侧蓝色线里面，其实DevOps也好，敏捷也好，已经做了大量的自动化和工程化的工作。
但是，在右侧我们会发现在国内，至少在国内的AI开发过程之中，没有很好的做工程的实践，也没有很好的做自动化的实践。举一个例子，就是我们在百度内部看到很多的AI开发工程师，他们就是自己去做数据的标注，做完数据标注以后，然后把这个数据从一台机器拷到另外一台机器里面去，然后去做这个模型的训练。
模型训练完了以后，这个模型就会存在这个机器上面去，这个模型训练完了以后，还要做模型的验证，或者叫模型的评估，然后再去拿一批数据，然后拷到这台机器上面，把原来训练的模型再去跑一遍，然后去做评估。
如果评估好的话，他就把这个模型再去拷出来，等到那个工程团队说我现在要发板了，然后去找这个模型的工程师说，现在我能拿哪个模型，这个模型的工程师会上到他的这台机器上面去，然后上各种各样的模型里面去找，你拿这个然后把它拷出来，然后传给工程的团队，让他去上线部署。
所以，整个这个过程你会发现，一旦说这个AI模型开发工程师他生个病，他请个假以后，整个这套流程就断掉了，就没有人知道说在那台机器上，到底哪个模型是他真正能做到的模型，所以整个AI开发的过程是没有任何的工程的实践，或者工程的工具来支撑的。
所以，这会导致说上线了一个服务以后，如果发现了一个问题，比如说模型的训练精度不够，你是很难从头到尾追溯回来，说这个到底是怎么训练出来的，用哪套数据、哪些指标、哪些参数训练出来的，这整个过程都是非常非常不透明的。
这个就是我们在百度，在做AI开发的时候，一段时间以前经常面临的问题，所以我们提出了这样一个流程，我们也要向DevOps开发传统软件一样，去开发AI的开发工程，或者AI的模型工程。我们怎么做的呢？
首先，我们做了一个（不是我们团队做的，AI团队做的）数据，到数据准备，生成模型，应用模型，到模型上线以后的收集，再去把数据回流，整个这一套模型训练、模型生成，以及模型的应用过程，做了一套自动化工具。

我们内部叫做AIFlow，这个AIFlow是一套完全自动化的AI模型训练的工具，这套工具可以很方便通过拖拽的方式，这是工具界面，把模型训练的过程自动化起来，并且完全每一个版本都可以追溯的。
我们应该在这一周周三，百度AI开发者大会，那个大会上做了这样一个视频，也是大概3小时时间，我们一屋子同学，我和AIFlow开发团队的Leader，我们两个给大家介绍一个完整的AI模型开发过程。
这个过程是什么呢？你可以在界面上很方便把数据源拖到上面去，很方便把你要训练的工具放在这里面，很方便把生成模型的框放在这儿，用一些简单的线连起来，点右上角的执行。这时候整个训练会自动化把数据放到工具里面训练，训练完以后，把模型产出出来。
整个左侧这一套相当于把模型训练出来，中间这一部分当模型训练出来以后，还要做模型的校验。把一套已经标注好的测试数据放在这儿，去验证这个模型训练出来以后，到底结果准不准确。并且整个结果的过程可视化出来，我们能很自动无人值守把整个模型训练过程，完全自动化出来，并且能够直接看到结果。
所以，这个效果是非常、非常好的。也就是在前天，我是第一次作为一个AI开发者给大家讲解，怎么样从头到尾开发一个完整的AI服务，并且上线部署。

这是在模型训练过程中，在模型训练右侧部分，我们做了一个工具叫做AIFlow，完全自动化、流程化、可视化出来，大大提高了整个AI模型训练的效率和效能，准确度非常高，效率非常好，并且完全可追溯。
这时候会带来另外一个问题，左侧部分用传统的DevOps工具，百度叫做效率云产品，把它完整的流程自动化了。右侧有一个新的工具叫做AIFlow，把整个模型训练的过程自动化了。
问题在于怎么样把模型和工程更好结合到一起，并且自动化部署，这一套工具到底怎么实现的？我们的做法用效率云（传统交付流水线）把模型的制品当成一个普通的制品拉过来，做自动化的集成打包，后面的部署用传统的工具流水线做上线部署。
在周三Demo的时候，除了做完模型训练以后，大家在传统流水线上一点部署，Svrvice就起来了，大家能看到新的AI应用产生了，大家可以看到整个识别的精度和识别的效果变得更好。

我们再去看一下这部分的具体怎么做的，整个模型训练的生命周期和DevOps生命周期不太一样。我们现在已经比较清楚，在整个AI开发过程中，尤其AI模型开发过程中，虽然有数据准备、开发和模型训练的过程，但是逃不出整个DevOps完整的生命周期。如果说一个AI的服务，要真正上线，或者真正快速上线，必须要经过DevOps的过程。所以，我们做了百度效率云+AIFlow的结合，这是我们大概的流程图。
告诉大家，怎么样把一个AI训练的工具，快速发布到AIFlow里面去。AIFlow产生了这样一个模型，怎么样回到流水线的制品中去，同时怎么样通过一个流水线，快速把我们工程的制品和模型制品打到包里以后，快速去部署到一个服务上，这个流程已经完全自动化了。真的可以很高效把一个AI的服务，快速开发、快速部署，大大节约了AI开发者工作的时间。

三、AI for DevOps

上面讲的DevOps for AI，主要用传统的DevOps工具和流程，我们传统的软件流程去支撑AI的开发，刚才做AIFlow和传统DevOps流水线打通的事情。
第一部分自动代码补全。我们发现随着研发数据积累越来越多，从业务角度出发，对于开发的质量和速度的要求越来越高，所以我们势必要一些最先进的技术（像AI）直接引用开发过程中，我们和北大软件学院一起合作，做了一个智能编程助手，做的事情自动代码补全。

在座各位应该开发的同学居多，大家都会用到IDE，IDE当你打开的时候，会扫描你的代码工程，当你敲代码的时候，会补全一些类和方法，把你的文字补全。
我们发现整个一个类和函数，还是需要大家从头到尾去写的，我们IDE现在只能补全到一个文字，你以前出现过的类和方法的名字，只能补全到这个程度。
目前我们通过机器学习的方法，当这个IDE插件打开一个工程以后，会通过后面的AI或者深度学习的方法，去学习代码经常怎么编写的，代码的类和方法的应该是什么样子，同时还会学习开发者经常开发这类语言的时候，开发的习惯是什么样子。
这两方面都学习好以后，当开发者再去敲代码的时候，就会变成一个选择题。为什么这样呢？当机器把代码学习的比较透彻了以后，当你再写这样一个类的时候，会把整个类的框架全都补全出来，你只不过在这个框架里稍微修改一些参数，你新的类和方法就出来了。
这种方式能提高开发效率，让开发者写代码的时候，从主观必答题变成了一个单向选择题，这样的话能大家提高开发效率。
我们在介绍的时候，把AIXcoder和效率云放到了一起，这个地方当时在开发者大会的时候，有一个展台，有很多同学用游戏手柄的方式做编程，大家还是觉得很爽。这是我们在AI和DevOps结合时候的第一点，直接把IDE做了一个AI的强化，让代码补全做得更完整。
第二部分，静态分析了。作用是能更好帮助开发者，把代码的质量更保证起来。我们经常用到的代码静态分析工具，我们发现我们经常用到的代码静态分析工具扫出来的代码固然不错，但问题很多，我们也发现误报率非常高，核心问题还是扫不到。

我们做了这样一些尝试和优化，通过智能的AI驱动，假设我们新加了一个问题的分析，做了代码扫描，会在系统和工具里，让用户去标注，这是不是误报，是不是有问题，当我们收到一些标准反馈，会自动进入到机器学习里，让机器去做优化，以便于整个代码扫描检测出的结果，让大家主观感知的误报率降到越来越低。
因为误报率不仅仅是真正扫出来的误报率，还是你的感知误报率。当扫出来代码以后，有几千个问题，大家一下就会吓傻了，代码这么多问题怎么改？如果你想让大家持续不断去修改这些代码，得让大家的主观感知误报率降到比较低，每次都能扫出来3、5个问题，而且那3、5个问题确实是真正的问题，大家就会觉得我有动力去改。
我们用了一些AI驱动的方法，让大家的主观感知误报率做得更好一些，同时我们也做了一些很深层次的研究，我们去发了一些论文，做了一个代码静态分析的持续优化工作。
第三部分，做代码搜索。每位同学在开发的时候，代码搜索是经常要做的一件事情。我们一般来讲，都是把代码克隆到自己本地，用IDE做搜索。为了让整个公司的工程复用率或者代码复用率更高，需要在整个公司范围内做全公司的代码搜索。

我们公司现在大概有7万多个代码，每个代码库里的代码很多。当每个开发的同学提交代码的时候，能不能先去搜一下，这个自己要写的代码在公司里是不是已经有了，如果有了，是不是直接引用就好了。
我们现在做的事情，能做到整个公司级别的所有代码库的索引，能做跨库的搜索。这个Web页面里，我们甚至能做到代码跳转，在这个代码里，如果引用了另一个代码库的类和方法，直接在这里面用Web页面跳过去看，这些原来只能在IDE里实现，现在在Web页面可以实现，并且把这些Web内嵌到了百度开发的代码库产品里，叫icode，icode每天能接收到几万次的代码搜索的请求，非常好返回给一些代码搜索的结果。
同时，我们也写了一篇论文，最近刚刚发表《企业级海量代码的检索与管理技术》，这是一些挺有意义的探索。
最后我们做的工程师画像，这是有业务诉求的。每个业务方都会觉得自己工程师的潜力还可以继续挖掘，还可以继续培养。我们有这样一个问题，每一位工程师现在的工程能力或者是现在的能力是什么样子，在哪一方面还需要加强，我们怎么样推荐一些更好的指导，在这个过程之中，我们要对工程师做一些刻划。

由于我们积累了大量工程师的数据，比如说编程数据、扫除代码的数据、代码评审的一些数据，以及说他评审的一些次数和评审里的一些内容，我们通过这些数据再加上一些语义分析，能对这个工程师做一些简单刻划。
比如说，对于这个工程师来讲，他的代码情况是什么样子的，定义做得好不好，代码缺陷做得怎么样，有没有善于发现缺陷。
我们举这样一个例子，有没有善于发现缺陷，我们是从所有工程师在给别人评审代码时候，我们做语义分析，这个是不是发现了问题，那个是不是没有发现问题，是不是只是一个OK，如果发现了问题，我们会给打一个标签，这个工程师确实善于发现别人的问题。
在这个工程师标签里，我们会给他这样一些标签，帮助这些工程师更好了解自己，也帮助这个团队更好去选取合适的工程师做这样的开发。同时也帮助公司给不同的工程师推荐不同的课程，帮助他们提高、提升。
再总结一下，首先介绍了一个大概的策略，然后我们重点介绍了一个DevOps for AI实践探索，提高了整个AI开发者的工程效率和开发质量。最后我们做了几个例子，把AI怎么引入到DevOps里，做了一些探索和介绍。