本期嘉宾：百度运维技术经理 曲显平
演讲会议：部分内容选自 1024学院旗下品牌iTechClub主办·华南区第六届互联网技术精英高峰论坛
整理编辑：小猿
运维一直是个繁重的活，并且随着公司规模的增大，运维压力直线提升。
有一张大饼图揭示了运维的工作时间都消耗在哪里：
可以看见，47%的时间消耗在两项工作中：
1.执行实际的部署工作。
2.修复与部署工作有关的问题。
这一方面是日益增长的庞大业务线问题，一方面是研发和运维日益严重的隔阂问题，剩下的就是手动运维到自动运维的转化问题。
就业务复杂度而言，单以百度来说，就包括七大业务线：搜索，广告，地图，金融，云，无人车，AI，且每条业务线都很重要，相关的运维平台需要大量的单独对接和开发。
而研发和运维的低效率沟通就更古怪了。长期以来，双方所属部门不同，日常工作的侧重点不同，使用的经费也不同，导致一堵无形的壁垒出现在中间。但最终大家发现，不管基于何种目的，只要配合不默契最后的结果都一样：项目失败。
最后在自动化运维的问题上，大家有一个普遍的错觉：我们就是自动化运维。但实际上根据调查，在运维情境中，61%的企业使用脚本完成的工作占比低于10%。
而手动输入指令这件事有多要命呢？请看下方的面条图：
仅仅手动输入五条命令，成功率就跌到了86%，手动输入200条命令，成功率约等于0%。
所以现代运维的问题主要可以归结为一句话：活儿多嘴笨还手残。
在这种情况下最先出现的是DevOps， 很多人提起DevOps喜欢立刻吐出一堆工具链，比如puppet，Docker，Redmine，Jenkins，Zabbix等等，但实际上DevOps是一个方法论，自动化运维只是其中的一部分。
本质上，DevOps是为了解决掉通往敏捷开发路上的一切障碍，打破相关各部门的沟通壁垒，全自动化运维部署。
简单点说，主要是打破研发和运维的沟通壁垒：
说全一点，是解决开发、运维、QA三方的沟通问题：
那么DevOps有用吗？有用，有大用，据一份第三方统计机构调查3200位从业人员以后的信息显示：
组建了DevOps团队以后，代码部署频率提高了46倍，但变更失败率却降到了之前的五分之一。
但这种事你始终要多留一个心眼来看，DevOps是一个方法论，而不是一套确实的开源工具，更不是哈利波特的魔杖，具体执行起来的效果肯定会有优劣之分。
而且但凡可以归结为一个方法论的东西，就存在相当的模糊性，从许多从业者甚至说不准DevOps的概念这点就可见一斑。
不然百度也不会再加上一套SRE体系与其互补。
SRE是谷歌率先提出来的概念，全称是Site Reliability Engineer (网站可靠性工程师)，要求更高更直接，就是要求你既会开发，又懂运维。
得咧您呐，就您自己干吧，只要不是精神分裂，应该不存在什么沟通问题。
SRE一般都是从研发工程师转行的，唯一目的就是保证网站不宕机。但这种复合型人才的招聘难度也很大，涉及到职位赋能时大家更懵，如果使用SRE体系，中小企业基本就可以说拜拜了，反正你也招不到人。
在这种情况下，百度开始了更高阶的运维方案实践之路：AIOps。
AIOps，也就是基于算法的IT运维（Algorithmic IT Operations），是由Gartner定义的新类别，源自业界之前所说的ITOA（IT Operations and Analytics）。
目前百度团队对AIOps的应用主要有四个方面：故障管理，变更管理，容量管理，服务咨询。
核心包括三个方面：运维知识库，运维开发框架，运维策略算法平台。
在构建AIOps之前，百度将问题场景归纳在四个象限之中：
类似全网宕机等重大故障，虽然问题复杂，但属于低频问题；像监控管理、部署变更类工作，虽然问题并不复杂，但发生频率很高。
站在运维的角度上，优先考虑解决高频、简单的应用场景，因为这种问题虽然往往简单，危害低，但是却消耗了大量的人力。（老板想的正好相反，并叫你到办公室来一趟）
基于对问题场景的理解，百度首先规划了庞大的运维数据网络，即三个核心之一的运维知识库。
从图中可以看出，运维数据主要分三大类。
第一类是元数据，元数据可以理解为针对任何一个个体单位的数据，这个个体可以是一个产品，一个人，一个APP，一个网络，等等。
第二类数据是状态数据，这些数据是传统运维最关注的部分，涉及硬盘，内存，cpu的使用情况等。
第三类数据叫做事件数据，是最难归纳的数据，包括一些告警、紧急方案等等。它相当于基于运维的理解，归纳出的逻辑数据。该数据的准确与否，直接影响整个系统的行为。
就像我们曾经在过去的文章中反复提到的一样，没有数据的AI开发都是扯淡，百度整理这套数据总共耗费了四年有余。
准确的归纳出运维的指标数据是一件相当困难的事，数据必须完整又足够描绘出整套运维框架，这是AI版的“0和1”。
建筑在运维知识库（运维数据）之上的，才是完整的运维开发框架：
在这张令人眼花缭乱的架构图中，有两项工作最困难，却又是我们最熟悉的。
1.模块的抽象和封装
在所谓的OPAL（operation abstraction layer）部分，所需要的还是大量的完整的封装工作，可以说自打有模块化开发的概念，良好的抽象封装在架构设计上就一直是个绕不开的弯。
复杂的交流，复杂的接口，本质上都是抽象和封装的不完善。
比如你说你想吃胡同东头的山东大蒜拌意大利面，同伴说想吃西头的牛肉汉堡沾东北大酱，然后你们开始为了吃法而争论不休。
其实正确的说法是：“我饿了，吃饭吧。”
2.大型测试环境的构建
而在Develop Tool Chain部分，有一个Test，涉及大型测试环境的构建。
这点研发和运维的怨言倒是史无前例的达成了统一。很多公司纠结成本问题，舍不得买服务器构建大型的机房级别的测试环境。
实际上很多线上问题的根源就在这，测试环境和线上环境的差距过大。
这一点 百度做到了。
看的出来，不管我们把AI这个词讲的多么高端，很多基础问题仍然围绕在IT圈说了二十年的东西，数据、抽象、测试环境，这是一条没有捷径的路。
很多人听到AI乐够呛，以为冒出来个黑科技，把坑都绕过去了。实际上这个“黑科技”是帮你在传统大坑后面，挖好了下一个坑，只不过最后到达的地方，天空也更加蔚蓝。
在漫长的基础准备工作后，AIOps终于开花结果，以下是三个百度在AIOps方向上的实践例子：
1.智能故障自愈
其核心还是运维知识库，由于IDC故障的原因五花八门，归纳异常事件的种类完全是个技术活儿。但在这方面的工作越优秀，也意味着整个系统越智能，据说，谷歌已经可以达到任何一个IDC的故障自愈。
2.无人值守上线
早期可能还是需要人工检验规划结果，目标是慢慢彻底的去人工化。
3.智能客服机器人
在服务企业内部的智能客服上面，百度在自然语言处理方面有天然的研究优势，而且单独对于运维场景来说，该系统的难度要降低很多。
毕竟运维同学应该不会闲着没事去找智能客服聊骚。
如同AI技术的不断发展一样，AIOps的演化也在不断地进行，从自动化到智能化，这是一个升级蜕变的过程。
但运维同学也不要过于高兴，谁说以后就是“喝着咖啡做运维”了？兴许以后就没有运维了呢？
联系客服
