2018-08-15 14:20

　　萧田国：各位朋友，今天讲一些我这里面的实践内容，我还准备了一些书，就是关于AlOps和DevOps，把这些书可以送给你们。

　　看到在座的很多朋友都是以前做运维或者是准备做运维的，对于你们而言，这一个路还很长。今天我们做的事情很简单就是分享。那就是说运维，我们以后该怎么做，怎么能够有一个比较好的职业生涯。我们知道现在的说法是这样的，IT人员做到35岁就有一点困难了，35岁之后有很多的岗位都不招了。但是对我们而言从24岁-35岁是十年的时间，你应该如何度过，我们给一些行业里面的思考和思想。

　　我们说整个运维从很多的这一个大场来看有一个演进，由人肉运维到了一个自动化运维和DevOps的，人肉运维就是凭我们的血肉铸起一个城墙或者是桥梁，但是容易倒塌。但是任何事物发展都是这样的规律，一开始是运维的知识，把它圈牢靠了，网络的通信、进程都应该学会，你应该试着把这些基础学扎实。再想第二步的自动化运维。我们做一些自动化的部署这种事情。那我们说对于运维而言，实际上很有意思，在2015年，社区开始鼓动自动化运维的时候会有一些问题，这个时候你的Ops做的再好，只是解决了自己的问题。后来在2016年我们在全中国推广这个DevOps，开放运维。

　　新时代的运维对我们而言会有困惑，有很多同学会觉得，到底怎么去弄。那我们的建议是有两个：第一个是实施DevOps。刚刚我们的合作方就是信通院，对DevOps给大家讲了很多。关于DevOps，很多人会误解什么是DevOps，他可能认为会点运维工具就是DevOps，其实不是这样子，这只是一个最狭义的DevOps。也就是说要去做DevOps的工具开发，DevOps如果大可以很大。那么DevOps的前途会怎么样？说是等到明年的时候全球财富的80%会应用，2019年也快了，目前的趋势是有的。第二个好消息就是说DevOps的前途怎么样。我们看一下早一些年的时候很赚钱的行业是什么，是做移动开发对不对，安卓和IOS的开发。但是目前为止，他们已经是在底端了。然后在近年以后，要做一个DevOps工作，你有机会比开发工资还高38%，有零有整的数据好像很现实的。但是不管怎么样，对于我们而言，像我们这些运维的同学在学运维的同时，还是得学一些相关的内容，以后你做一个工具开发，有一个公司有好事情。目前公司都讲开源，还少去讲买产品。这个时候你至少能看得懂代码。对运维人员是有机会弯道超车，以后有春天。

　　DevOps的趋势就不用说了，好消息是什么？现在做DevOps不需要重头再头，这个词从2009年提出，那么这里头我们做了一些事情，就是非常鼓舞人心的事情。以前的时候我们知道很多标准是很惨的，是被动的接受者，或者是ISO20000或者是9000，这次我们DevOps有机会，国人做好之后推到全世界。

　　如果说你有标准了以后，这个时候你有可能必须容易达到一个共识了，就没必要再摸索了。我们DevOps是一个模型，有五级。这个五级也不是很简单的，第五级是最难的。目前为止，很多大厂也就是三级的样子。2015年的时候我们互联网的同仁想做一个事情，做了一百多页就放弃了。运维做的最好也很难产生价值，后来我们驾驭框架做了一个外延，于是乎就有了一个研发运营一体化的模型。   

　　这是当时评估通过的画面，当时工信部的领导一起为他们授牌发证，这个标准做完之后好处是横向的评测。我们看一看例如这边有一个公司A，还有一个公司B。这个时候它们的得分完全相反，说明什么？说明它们肯定不是统一部门。例如说其中一个是开发部门，一个是运维部门，授权的项目。这个时候可以做到习大大说的话：车同轨、行同文。

　　对于开发管理，我们知道开发管理不是开发。你们需要知道，以后每一个运维都应该训练敏捷。敏捷现在比较流行的，现在的东西跟开发本身没有关系，需要去革新你的思想，但是不局限于运维本身，这是一个它的特性。

　　然后是持续交付。持续交付，现在里面实际上是把开发设施运维全部串起来了，最终形成一个持续交付的流水线，这是一个平台。这一块是一个技术运营，这一块是运营设计刚刚说过了。然后运营设计的话，这一点对于我们很重要，那就是说一个运营的可维护性，我们希望以后开发的程序里面，至少日志应该有一个代码，我们通过代码发现什么错误。

　　然后应用架构里面很多关心的是微服务的设计和实践。还有一个是安全和分享管理，组织结构。这是那个评级。有人问你们的DevOps标准和CMMI是什么区别？其实区别挺大，CMMI和ITIL是侧重管理，而DevOps标准是把两个串起来，讲的是一个技术的评测。

　　为什么做评估？包括自查、自证、对照和度量。自查的时候很多人不知道，做到什么时候就够了，而且很多人立项参差不齐，这时候需要补齐。还有是自证，这很重要。很多要先知道运维在哪里，我们做好的事情，那就是说没有办法去证明这些能力，所以说这个是有用的。

　　我们做到一个端到端的持续交付流水线。这里面是从开发的分支，构建，再做一个代码扫码，构建、测试等等，我们把这些内容全部都串进去了。对于我们很多朋友而言，可能运维也是刚开始做或者是做的时间不长，这个东西你可能不重要，你可以先了解一下。因为等了解完以后的话，至少的话你能知道不是那么无知。因为我们说做技术的最怕就是自负，不用说觉得我很厉害了，就是天下第一了。这是一个完全错误的，需要有一个谦虚的心态做这个事情。

　　后来我们又做了一个端到端持续交付的2.0。这里面基于高核的服务架构来做的。模拟一个商店，比如圣诞节快到了，有一个公司去参加活动，这个时候怎么支持。这个时候我们就刚刚的环境有人设计出来一个稍微复杂一点的，就是流程图。那就是说，怎么去把我们的这一个产品，把我们的第一个需求能推到这个验收环境，预发布环境和生产环境，以及随后怎么样去做后续的一些变更。大家需要有一个开放的心态，不停的去学习。像我们的这一个有什么好处？这个时候它能够去做编排，那么这个时候每一步一目了然，很快就过去了。我们也可以做什么事情，还可以做这个事情。那就是说，我们可以去打造一个这样的端到端的流水线，这个时候可以把很多功能都吸收进去。从构建到代码质量的测试，然后还有包括服务测试，然后就是说发送，包括手工发布等。

　　我们做Ops以后的路还很很长，做手工运维把底子做实，另外尝试自动化运维，然后是试DevOps，然后是AlOps。等到我那个时候是不是黄花菜就凉了，我们说不会，至少五年内运维还是会很开心的。五年以后可能会更加开心。

　　关于这一块我们做的企业级的AlOps实施，都有白皮书了，这也是国内的第一个，也是全世界的第一份。是国内众多大咖的一个心血所在。包括目标、能力框架、团队角色、应用场景，AlOps的实施建议，实施关键技术，AlOps效果度量。

　　AlOps通俗得讲就是对规则的AI化。假设你知道规则，但是很多时候我们不知道规则，很多时候场景过于复杂，你动则是百万级的用户，自己找不出规则，这个时候尝试机器学习把这个规则AI化这个事情。

　　我们这里面的这个白皮书定义的AlOps是五级，第一是尝试，第二是单点，第三是创建，第四是能力完备，第五是终极。我们这在个白皮书里面，我们里面有一个东西叫学件。学件可能是我们的福音？就是模型加公约，会具有一个记忆功能。我们看一下这里面，我们说最开始的时候会有一些API的东西。API有一个固定的输入和输出，里面的规则是固定的。以后的话会有一个API2.0，输入数据，输出的接口，这个时候的规则是变动的。我们是学件？学件就是模型加规则。有什么好处？这个时候可以被了解，里面的算法等等就是智能化的功能。这个时候数据被接入进去，这个时候你的数据越多，结果就会越准。我们认为，学件是用来踏进AlOps领域的敲门砖。学件是可以应用之前的经验，你只需要配置实现功能，比如说快速的布站定位的功能。这个时候意味着你没有任何算法也能做AlOps，或者是你至少能实践一些功能。这里面，一会儿嘉宾还要分享一下学件，这也是一个对于整个业界都是一个鼓舞人心的好事情。

　　我们AlOps的能力框架。是根据五个维度来做的，在一些场景里面的各个的应用点，以及是否需要人来操作。这个是由蓝鲸来做的AlOps的体系，后面的体系类似于谷歌的这个。第五块是说DevOps的团队角色。一个是运维开发工程师，运维AI工程师，目前是按这样来招人的，以后可以统一化。以后你有机会用到学件的话，你可能暂时不需要招AI工程师，名字想了很久，一开始是运维算法研究员，太过于专业和偏门，第二是运维数据科学家，后来想运维怎么能和这么高密度的词汇搞得那么近，没有必要，我们团队是务实的，就叫AI工程师，就像我们的内涵低调奢华。

　　今天有人问我今天有AlOps了吗？我说是的，并且在少部分环境里面已经有应用了。这是一个关于Ops的实施及关键技术。我们很幸运，阿里巴巴的一个大数据负责人，正在给我们改写这部分，以后的版本可能会更加好玩一些了，这是一些实施和关键技术的一些内容。

　　我们现在的话，也可以说叫国际级的DevOps和AlOps的标准发起方，后续大家如果有这样的需求可以再聊，就是关于运维该怎么走，下一步的方法在哪里，我是希望大家在这次会结束之后，对于你们会有一个认识，那就是你做运维的路很长，你可以踏踏实实做技术很多年。但是还有一点很重要，那就是说你千万不能够只是埋头走路，还要什么，还要抬头看天，还要有职业修养，这个很重要。有一些人认为自己会一门技术就很自负，我们说自负就是自卑。反正路漫漫其修远兮、吾将上下而求索。我的演讲完了，谢谢。