智能运维就是由 AI 代替运维人员？
本文整理自 GOPS2017·上海站演讲《从说到做 - 大型企业智能运维的360度解析》
作者简介
孙杰，国内一线运维专家，从业十几载的 IT 老兵，专注于系统、运维、云计算和数据中心管理，先后在外企、互联网、电商、大型企业任职，参与实施数据中心建设、私有云架构规划及运维管理、大数据挖掘等相关工作，在若干大中型项目的建设和部署运维中，积累了丰富的架构设计、项目实施和一线经验。凭借丰富的技术经验和乐于分享精神，先后受邀出席全球云计算峰会、可信云大会、GOPS 全球运维大会等全国性技术会议并发表热点主题分享，受到广泛好评。不仅是技术分享的推崇者，也是 IT 行业的实践者、布道者。
听了有关 AI 运维之后有很多人感到比较焦虑，我所从事的运维或开发将来会不会被 AI 给替代掉呢？
现在新技术发展的特别快，各种语言、技术、理念让大家确实感到自顾不暇跟不上趟，但是有一点，在这里我要特别重申一下，AI 在目前这个阶段还是一种辅助大家来进行判断和学习、定位处理问题的工具，就像无人驾驶，现在可以做到完全没有人驾驶吗？肯定不行，未来无人驾驶是完全可以替代人的，但它还有很长一段路要走。AI 运维就像无人驾驶一样，未来前景很光明，但任重道远。
大部分的智能运维还没有完全落地，我所在的企业也是处在一个探索的阶段。在一个传统的企业它的运维该如何走？从以前的脚本到工具、自动化，再到现在的智能运维，中间这个步骤该怎么走？今天就从下面五个方面给大家分享下：
1构建一个全面科学的 IT 运维管理体系
第一个 IT 部门的整体认可不足。虽然说IT在任何单位现在都是一个比较重要的部门，但是还有很多领导仍然认为它是一个成本中心，不是一个利润中心，认为这个部门是花钱的，而不是像业务部门创造业务价值和创造利润的。
第二个对于运维工作人员负荷比较大，工作模式不被员工认可。在没有自动化运维和平台之前，整个运维团队只有八个人，如果每个人一天处理六到十个故障，基本上没有时间去研究别的东西了。传统运维压力很大，疲于奔命和救火，必须要寻求改变，走向自动化、平台化、智能化。
第三运行的态势相关信息掌握不足。监控是多维度的，不同的业务会有不同的指标，所有加起来有上万个指标，但却没有整体态势变化图、很难成体系，不能实现智能感知和态势预测，整个运维态势就很难保持平稳。
第四依据业务需求调整服务和设置资源的能力不足。在业务故障处理的时候需要很长的过程，中间涉及到很多的相关技术部门，需要和业务方进行交互，仅靠较少的人力几乎做不到。
我们希望在现有的业务体系里面，运维部门要实现这样的运维目标？
第一个全面的性能管理。能够提供对现在所有的设备和服务质量进行实时监测，并且提供动态阈值的告警。
第二个统一的资源管理。很多企业业务都上云了，需要有统一的监控平台，可以把所有业务相应资源视图抓取出来，便于我们对整体资源有一个合理的预估和分配，并从整体角度评估各个业务部门对资源的使用情况。
第三个及时的故障告警管理。我们发现有很多产品还不能做到完全及时的告警，告警发生后总是延时才能知晓，需要实时的准确的告警，减少延迟和误报。
第四集中统一展现管理。把很多不同的监控子系统集成起来，这个在现在的企业里面需求是很大的，借助于各种工具，采集数据之后自动合成一个报表统一展现出来，方便管理。
我们关注的核心问题有：
第一我们是一个跨地域的平台，是多数据中心，我们希望有一个 IT 的综合运维平台，来统一管理。
第二是深入监控并进行集中统一的可视化管理，提高效率。
第三就是有效的预防问题的产生，降低运维成本。另外就是问题出现后，能够快速跟踪定位，降低人力成本。
第四多维的报表为决策提供有力支撑，科学预判趋势。
第五全局业务服务视角和平台化扩展以及大数据分析的融合，满足企业对于业务高效和快速迭代的需求。
第六保护和优化 IT 资产。以前各个业务都是自己的一套系统，有自己的开发和运维人员以及监控系统，这对企业来说是重复造轮子了。现在上云后，把原有的系统集中整合到云上，通过统一的监控和资源管理最好的保护和优化资产。
要做好智能化运维之前，我们经过深入的分析，提了四个要求：
第一个是规范化。规范化就是尽可能的把操作规范下来，比如模板里是什么基础配置和安全基线，有一个规范化的标准。
第二个是可控性。就是能够通过云监控平台发现各个业务存在的瓶颈，包括资源瓶颈和性能瓶颈，对可能产生的问题可控可分析。
第三个是数据化。基于海量数据的决策分析，才能方便作出准确的判断和科学决策。
第四个是主动性。从被动响应变为主动服务，主动发现问题，把问题消灭在萌芽中，在业务发生问题之前及时告知，这个感觉就不一样了。
我们希望构建现代化和智能的运维管理模式，主要是以下五个方面，如下图：
2全景业务服务管理
在互联网大爆炸时代，国家层面上也在提互联网+、数字化转型、智能化等等。我们的系统能不能快速响应，为业务保驾护航？
面向业务的 IT 服务管理主要有这几个特点：
监控的粒度要细，能通过一个曲线捕捉到异常点。
面向业务管理和面向用户管理。这块要区分开来，在企业里用户权限分的是比较细的，什么人可以操作什么样的业务，管理员可以管理哪几类业务都有清晰的定位。
数据的全面和扩充性。数据只有全面才能进行科学的决策，很多时候如果看到的日志不全，或者拿到的监控数据不准，在做决策的时候肯定就会比较贸然。比如数据中心某业务链路出现问题，是不是要切换？数据是不是还能保持一致？这个时候在没有确定的数据来支撑你决策之前，你做决策时都会感到比较忐忑，犹豫不前。
建立以业务为导向的综合监控平台，主要目的就是要统一展现、统一管理和统一调度。全链路监测，这个目的就是从访问入口进来后一直到数据出去，每一个过程都要能监控到感知到。
从业务的视角进行IT基础资源的管理与维护，一旦某个资源发生故障或问题，都可以从业务视图中直观地了解到这个资源的故障将影响什么业务影响哪些服务，进而了解到影响哪些用户。
数据库慢了，CPU 突然飙升了，这些地方这些资源突然发生变化了之后，影响到哪些业务呢？这时候就需要将监控资源视图和业务关联起来，这样才能准确定位影响了哪些业务。
这个是问题的整体诊断和分析。
任何问题都需要采集相关的日志和数据，才能科学全面的分析问题。
采集层需要把不同数据源的数据采集过来，中间层做一些性能分析，配置管理和预警分析、告警处理。展示层将分析的结果展示出来，也就是各种图表，建立综合的业务指标分析，方便根因定位和解决问题。
3基于大数据平台的日志分析和多维报表
基于大数据平台，提供日志的采集和聚合处理，通过日志关联分析帮助准确全面定位提升效能和满意度，智能预测和预警，为科学决策提供量化依据。
将采集到的网络监控数据、机房数据、服务器和云环境监控数据以及摄像头报警数据集中起来，数据汇集之后生成 PMDB 性能管理库，在根据业务应用的特征，建立不同的模型进行相应的算法分析。
根据不同的资源类来定义 KPI 指标，建模目的就是方便快速分析，为资源管理、告警管理、集中化展现等其他模块提供数据分析模型的支撑。
数据采集有两种类型，一种是被动的，一种是主动的。
采集业务相关指标，可以对数据进行预处理，做一些有效性的标签识别，比如这个信息和指标是不是你关注的，对不友好的日志进行格式化处理。
性能指标的计算，要跟业务进行协同，从业务的角度来定义。设置的阈值，有些场景是固定的，也有的场景是动态的。固定阈值就相当于资源使用率，肯定有一个上限的。动态阈值像一些性能曲线，CPU 的利用率、页面响应、图片加载等这些是可以使用动态阈值的，根据历史数据来计算出这个动态阈值，某一时刻的历史峰值，根据这些合理计算出在那个时刻到底需要多少资源。
根据上面的阈值会有一个报警的事件，任何事件产生都是基于时间的，故障的定位肯定也要基于时间找到相关的日志和发生的事件。
事件诊断一直是运维领域一个很重要的工作，事件和时序的相关性不仅可以为事件诊断提供很好的启发，而且在帮助我们进行根因分析时也能提供很好的线索。某个时间段出现的故障，都会产生一些相关的事件，对它们进行筛选和过滤是能够详细捕捉到故障和定位到根因的。
在事件诊断和处理中，是不是需要引入算法，我觉得是有必要的，如果能提高效率和提高解决问题的能力，一切探索都是值得的。
也有一些运维界的朋友们花了很多时间和精力，去学习和研究算法，我认为不必过于纠结算法， 简单了解一下开源的这些算法，知道这些算法的输入和输出是什么，能解决运维中哪些实际问题，以及组合起来又能解决什么问题，方便我们合理的应用它就可以了，这样会对更快落地智能运维起到事半功倍的效果。
数据的汇聚处理就是把采集到的数据有机的关联起来，压缩、过滤形成标准化的信息。数据导入则可以通过全量的 HDFS 和增量的 Kafka 来实现。
基于大数据平台的多维报表，根据自己的需要，按照日、周、月来生成运维报告，发送给管理层的领导，这些数据是他们比较关心的，比较清晰的图示出在这些时段发生了哪些问题，造成了多大面的影响，然后决定相关的资源是否进行扩充，相应的业务部署是否需要调整。
综合展示比较关注的则是性能分析、容量分析和自动化配置。比如今年采购了 500TB 存储，我用了多少，明年还需要扩容多少，业务增长量会有多少，这个都影响到企业的采购计划。根据业务的实际进行评估，来推算出明年大概需要买多少 TB 的存储。
4IT 监控管理平台发展
IT监控管理的发展大概有三代，从上世纪九十年代至今，第一代是以网络为中心，在这个时期咱们提供比较多的都是基于网络的监控和故障发现，带宽管理和服务水平协议。
第二代监控就是以监控IT基础设施为中心，看到比较多的就是主机、存储、操作系统、中间件、数据库等各类基础资源的监控。
第三代监控以IT应用为中心，针对比较高度复杂的交易，需要实现面向用户体验和面向应用高可用性的实时监测和故障的智能诊断，运维人员必须高屋建瓴、全面谋划，有能力提供一个全局性、高效健壮、标准规范、自动化的监控解决方案并加以实现。
5故障管理及自治自愈
这是我们每天收到的告警情况统计，在没有自动化和智能化之前，我和大家一样心态是焦虑和崩溃的。
如何从错综复杂的运维监控数据中得出我们所需要的信息和结果，一句话就是分辨和精炼，提取真正需要关注的信息，从而减少每天的告警信息量。
目标就是简、智、深。
简就是要确保业务和 SLA 服务级别，出现问题要及时响应、自动分析和优化，把处理的流程精简和高效组合起来，让问题匹配正确的场景，找到正确的人，在第一时间正确处理。
机器学习主要就是突出智，这个需要大量的数据来训练，故障出现的形态是千奇百怪，对故障的历史数据进行场景分类和标注，不断用模式识别和数据来训练机器识别和分析，然后让机器自动准确判断。
当然标注不能完全靠人，也需要通过机器来自动进行关键词标注，而标注的合理性就需要人为进行判断，然后再利用到机器学习上，这样才能真正辅助我们做一些决策。
基于架构、工程师的经验和概率来做到收敛告警事件，基于规范和分工产生告警事件发送到对的人，基于数据和模型来提高事件的处理能力。很多事件有的工程师处理的特别快，反之如果对这个故障不熟悉的人可能花费的时间就很长。这就需要构建一个策略知识库，让其他人来参考和学习，提高同类场景事件处理的能力。
智能运维的终极，实现的目标就是减少对人的依赖，逐步信任机器，实现机器的自判、自断和自决。
技术都是在不断的进步，AI 技术将来会解决很多的一些需要花费大量人力和时间才能解决的事情，但是 AI 不是一个很纯粹的技术，它也需要结合具体的企业场景和业务，通过计算驱动和数据驱动，才能产生一个真正可用的产品。
智能运维技术在企业的落地，不是一蹴而就的，是一个渐进和价值普及的过程。
我们可以看到，智能运维技术已经成为新运维演化的一个开端，可以预见在更高效和更多的平台实践之后，智能运维还将为整个 IT 领域注入更多新鲜和活力，在未来发展和壮大下去，成为引领潮流的重要性力量！
转自：『高效运维』公众号
资源下载
关注公众号：数据和云（OraNews）回复关键字获取
2017DTC，2017 DTC 大会 PPT
DBALIFE，“DBA 的一天”海报
DBA04，DBA 手记4 经典篇章电子书
RACV1, RAC 系列课程视频及 PPT
122ARCH，Oracle 12.2 体系结构图
2017OOW，Oracle OpenWorld 资料
PRELECTION，大讲堂讲师课程资料
