嘉宾介绍：徐葳，清华大学交叉信息研究院助理院长，青年千人学者，博士生导师，UC Berkeley 计算机系 PhD，曾供职于 Google。主要方向为基础架构的监控，日志等，目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017，构建灵动新IT大会上的演讲实录。
清华大学数据中心运维那点事儿
我（徐葳）显然是个科研人员，同时还管理很多行政事务等，但有些人“命不好”，就是系统管理员的命。所以花了很多时间去管一个IT系统，学院的机房、云平台，基本上夜里大家都睡了，还要登陆上去看看日志，该修点什么就修点什么，我这个人有个毛病，就是看不得机器坏了，看不得什么东西不行，就得马上修好。
清华有系统管理员，就如同我一样都有系统管理员病，很喜欢做系统管理，但他们都是白天上班，因为没有加班费，所以不好意思让人晚上加班，所以晚上一般都由我来管。
这个数据中心做的是人工智能，现在人工智能很热，科研领域清华做的非常前沿，这是最最聪明的应用，但是跑在最最傻的基础架构上。
因为曾经供职于Google，非常想在清华复制一套Google的架构，但这并非一两个人就能开发出来。所以，即便在Google，唯一不能用的地方就是系统运维领域，这是灯下黑，这也是本次讲演的主题叫：“数据中心与智能”。
今天给大家分享几个方面：
首先，数据中心运维，这是和百度合作的一个数据分析的事情，会给大家展示几个有意思的结果。
其次，讨论下现在的新架构，Deep Learning深入学习，如何维护这个框架，怎么把数据中心改造成可以进行支持。
最后，数据中心现在如此复杂，怎么能再利用一些人工智能的东西放在数据中心里帮助运维。
如何平衡硬件+软件+运维？
首先，这是和百度合作的一件事，百度有很多的机器，有个部门叫硬件运营部，他们收集了很多故障报修，各种产品线，各种不同的产品报修了硬件，硬件运维部就派人去处理一下，大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket，几年内积累了29万个，我们可以帮助它的地方是，到底什么东西坏了，拿出来看看，什么时候报修的，大概什么故障，什么部件坏了，这里有很多结果，但因为时间关系，就不挨个赘述了。
报修了一个故障，多长时间会修？如同百度这样管理非常好的公司，报修之后多长时间会有人去处理？不是说修好它，修了不一定能够修好，但至少是去修了，该换什么就换什么，硬盘报错，坏了，就换一个硬盘。
具体时长看起来会非常奇怪：平均需要42天报完错可以修，中位数的修理时间是6.1天，其中有10%的是140天之后仍然没有修，但是没人修并不代表永远都不要这个东西了，过了200天以后仍然有人去处理它，而并没有忘记。
感觉这个时间过长，到底是因为什么？因为机器太多了？又或者系统管理员太忙了？其实未必。
因为如百度、Google这样的公司，系统架构非常容错，硬件出问题是不可避免的，它坏了，既然能容错，就像四个轱辘掉了一个还能跑，为什么要去修呢？所以逻辑是有一个超级容错的系统，在运维时对故障就没有那么敏感。从好的方面来说，可以省钱，因为一次修一个也得跑一趟，修若干个也得跑一趟，因此还不如一次批量的修。
当然硬件损坏无法避免，是否能降低一些容错的复杂性呢？大家目前越来越多的都在讨论这件事，就是三者的平衡，运维的可靠性、软件的成本、硬件的成本之间的三者平衡，现在越来越重要了。
另外，不管如何运维，运维的系统都是非常重要的，任何运维都不是登到界面上去敲几行命令，然后就派出一一件事，这个都是无法做到的，所以不管如何，系统的运维，从一个地方生成这样配置的操作，从一个地方生成的部署，都很重要。
以上讲的是硬件、软件、运维，这三个部分成本如何平衡，现在这个状态下，尤其是大规模的数据中心，有可能和过去小的企业数据中心不同。
基于数人云的Docker管理环境
现在深度学习火了，每个人都想要深度学习的机器。最开始一个人要的时候，没关系，从桌面虚拟机集群拆出两台来，装上GPU，自己去用。现在这样的人多了，装了60几块GPU仍然不够，所以这种集群如何共享这60几块GPU，非常麻烦。
后面做了一个什么事情呢？找数人云做GPU虚拟化，虽然GPU支持虚拟化但太贵所以不买，买的都是消费者级别的GPU，因为便宜。当它不支持虚拟化时联合容器，所以将GPU集群上放上了Docker，又找了数人云，帮助开发一个数人云的管理系统，是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学，因此对它的印象很好。
将来的就是这样的架构，好处是解决了一个问题，即服务封装，DeepLearning这事真的不复杂，如果你玩过，会发现很简单，其实就是找一个开源的软件框架，上面有很多模型，将其下载下来，都是开源的，这些模型甚至都是训练好的，可以跑人脸识别应用，或者跑其他的什么识别应用，虽然没有专业跑的好，但也不会太差。
但它的问题在于是基于框架，尤其在中国，版本不一样，升级版本升级的特别快，随便动一个升级，其他人都烂了，而不同人就要不同的版本，为什么，因为它下的那个模型是基于某个特定版本开发的，在别的版本上跑不出来，所以在这种情况下，大家去到无数多个配置好的镜像和环境，这个场景挺好，Docker、数人云有它的界面，将这个东西配置好，这种Docker配置的这种Docker，只有这个Docker里面用的是那种版本的东西，因为Docker是一层一层的，不用做那么多镜像，只有一点点区别没有关系，那么多借点有一点点区别，占不了那么多空间，好多镜像，各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题，但有一个问题，总得有训练数据，有点什么东西在里面，完成后改了配置等等，这些东西不可能存回到那个镜像里头去，就想那怎么办呢？可能过了两个星期之后还用呢？所以就不上Docker，留着，等两个星期后再说，但两个星期后做别的项目去了，机器就卡在那里，所以这是个问题，存储它的周边结果存在哪里，是个好大的问题。
简单的方法，有OpenStack，集群上500块硬盘总是有的，挂上NFS，每台机器上面有一个Ceph的NFS，把这些东西对接好，想把这个东西存在那个上面保证安全的，关了以后重启时再挂回来，设计了这样一套存储。
那有什么问题呢？DeepLearning的模型也很大，有些人直接在上面跑，本想让它存储一个备份数据用，跑到上面做一下其实还是存在本地。
所以后来自己改造了存储的架构，做了一个开源项目Alluxio，也是伯克利实验室的一个同学做的。
Alluxio缓存非常有用，它还为Ceph和NFS适配了一个接口，还有Hadoop集群，HDFS里面也有几百块盘，将这三种东西适配城了两个借口，适合放在Docker里面，也适合放在Hadoop里面，且它加了些缓存，这样用机器人内存吸收了很多流量，上图就是大概的基本架构。
HDFS也可以支持，同时也能顺便支持Hadoop，但是如果有一些大的文件，愿意用HDFS的，就用HDFS。
有写机器内存还蛮多的，就是当年趁内存时买了一些内存，还是很有用的，可以将内容缓存住。分布式内存很有意思。
用人工智能帮助数据中心运维
最后说一下很多做DeepLearning的程序，这张图片解释了一个词“复杂”，OpenStack觉得自己很干净，为什么？拿个笔都能画出来，但是这张图很复杂，复杂的原因不光是因为有这么多图，凡是看见的都是数据库，数据库是一个持久性的状态，每个组件里都有自己持久的状态，那如怎么保证一致？讨论了这么久分布式系统的一致性，它一旦跨了组件，尤其是跨了开源项目，谁也不会再说这件事。
但若组件坏了，里面还有一个复杂的结构，它一层一层的封装起来，所以什么东西坏了，你可能根本不知道，没坏的时候什么都特别好，但坏了就会很麻烦。
我是个很好的系统管理员，这点特别有信心，但是搞不定这个，因为我不是每天都在配这个，记不得这些东西到底在什么地方，随便查一个什么东西，后面的参数那么长，咱们记不住，但别人天天都在做当然可以记住。
那么，如何能动呢？我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库，在里面找一些相关的事情，这是纯从样子上找到的，跟语义没有关系。比如ID长那样，那个ID就是ID，IP地址就是IP地址，将这些东西都找在一起，把这些关联性插在一起，就能生成知识图。
另外，为什么三台机器一起坏了，有可能用户只看到一台机器坏了，但其实另外两台也是如此，因为它坏的原因是一个物理机，要坏肯定是三台一起坏，所以都可以找到系统里的一些东西，这有多少个节点？看这个系统看三天，120台物理机不算大，待该有60多个存储的借点，120多个虚拟机的节点，大概出来的结果是几千万个状态，如上图所示，所以可以想象为什么这东西老坏。
最后总结一下，运维是个什么样的过程？刚才说到DevOps，过去的系统管理员如何适应DevOps是一个非常大的挑战，因为DevOps，运维的人是靠开发程序来自动化运维数据中心的，这是必然的趋势，听起来都对。但DevOps推广起来非常难。
DevOps想要推行，一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方，基本的意思是，预生几个命令行，别说那么多分布式的东西，感觉就是几个配置文件，点点什么东西，这个接口怎么配置，是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录，后台回复“1116”即可下载本次大会的PPT资料。
