听了有关AI运维之后有很多人感到比较焦虑，我所从事的运维或开发将来会不会被AI给替代掉呢？

现在新技术发展的特别快，各种语言、技术、理念让大家确实感到自顾不暇跟不上趟，但是有一点，在这里我要特别重申一下，AI在目前这个阶段还是一种辅助大家来进行判断和学习、定位处理问题的工具，就像无人驾驶，现在可以做到完全没有人驾驶吗？肯定不行，未来无人驾驶是完全可以替代人的，但它还有很长一段路要走。AI运维就像无人驾驶一样，未来前景很光明，但任重道远。

大部分的智能运维还没有完全落地，我所在的企业也是处在一个探索的阶段。在一个传统的企业它的运维该如何走？从以前的脚本到工具、自动化，再到现在的智能运维，中间这个步骤该怎么走？今天就从下面五个方面给大家分享下：

一、构建一个全面科学的IT运维管理体系

第一个IT部门的整体认可不足。虽然说IT在任何单位现在都是一个比较重要的部门，但是还有很多领导仍然认为它是一个成本中心，不是一个利润中心，认为这个部门是花钱的，而不是像业务部门创造业务价值和创造利润的。
第二个对于运维工作人员负荷比较大，工作模式不被员工认可。在没有自动化运维和平台之前，整个运维团队只有八个人，如果每个人一天处理六到十个故障，基本上没有时间去研究别的东西了。传统运维压力很大，疲于奔命和救火，必须要寻求改变，走向自动化、平台化、智能化。
第三运行的态势相关信息掌握不足。监控是多维度的，不同的业务会有不同的指标，所有加起来有上万个指标，但却没有整体态势变化图、很难成体系，不能实现智能感知和态势预测，整个运维态势就很难保持平稳。
第四依据业务需求调整服务和设置资源的能力不足。在业务故障处理的时候需要很长的过程，中间涉及到很多的相关技术部门，需要和业务方进行交互，仅靠较少的人力几乎做不到。

我们希望在现有的业务体系里面，运维部门要实现这样的运维目标？

第一个全面的性能管理。能够提供对现在所有的设备和服务质量进行实时监测，并且提供动态阈值的告警。
第二个统一的资源管理。很多企业业务都上云了，需要有统一的监控平台，可以把所有业务相应资源视图抓取出来，便于我们对整体资源有一个合理的预估和分配，并从整体角度评估各个业务部门对资源的使用情况。
第三个及时的故障告警管理。我们发现有很多产品还不能做到完全及时的告警，告警发生后总是延时才能知晓，需要实时的准确的告警，减少延迟和误报。
第四集中统一展现管理。把很多不同的监控子系统集成起来，这个在现在的企业里面需求是很大的，借助于各种工具，采集数据之后自动合成一个报表统一展现出来，方便管理。

我们关注的核心问题有：

第一我们是一个跨地域的平台，是多数据中心，我们希望有一个IT的综合运维平台，来统一管理。
第二是深入监控并进行集中统一的可视化管理，提高效率。
第三就是有效的预防问题的产生，降低运维成本。另外就是问题出现后，能够快速跟踪定位，降低人力成本。
第四多维的报表为决策提供有力支撑，科学预判趋势。
第五全局业务服务视角和平台化扩展以及大数据分析的融合，满足企业对于业务高效和快速迭代的需求。
第六保护和优化IT资产。以前各个业务都是自己的一套系统，有自己的开发和运维人员以及监控系统，这对企业来说是重复造轮子了。现在上云后，把原有的系统集中整合到云上，通过统一的监控和资源管理最好的保护和优化资产。

要做好智能化运维之前，我们经过深入的分析，提了四个要求：

第一个是规范化。规范化就是尽可能的把操作规范下来，比如模板里是什么基础配置和安全基线，有一个规范化的标准。
第二个是可控性。就是能够通过云监控平台发现各个业务存在的瓶颈，包括资源瓶颈和性能瓶颈，对可能产生的问题可控可分析。
第三个是数据化。基于海量数据的决策分析，才能方便作出准确的判断和科学决策。
第四个是主动性。从被动响应变为主动服务，主动发现问题，把问题消灭在萌芽中，在业务发生问题之前及时告知，这个感觉就不一样了。

我们希望构建现代化和智能的运维管理模式，主要是以下5个方面，如下图：

二、全景业务服务管理

在互联网大爆炸时代，国家层面上也在提互联网+、数字化转型、智能化等等。我们的系统能不能快速响应，为业务保驾护航？

面向业务的IT服务管理主要有这几个特点：

1、监控的粒度要细，能通过一个曲线捕捉到异常点。
2、面向业务管理和面向用户管理。这块要区分开来，在企业里用户权限分的是比较细的，什么人可以操作什么样的业务，管理员可以管理哪几类业务都有清晰的定位。
3、数据的全面和扩充性。数据只有全面才能进行科学的决策，很多时候如果看到的日志不全，或者拿到的监控数据不准，在做决策的时候肯定就会比较贸然。比如数据中心某业务链路出现问题，是不是要切换？数据是不是还能保持一致？这个时候在没有确定的数据来支撑你决策之前，你做决策时都会感到比较忐忑，犹豫不前。

建立以业务为导向的综合监控平台，主要目的就是要统一展现、统一管理和统一调度。全链路监测，这个目的就是从访问入口进来后一直到数据出去，每一个过程都要能监控到感知到。

从业务的视角进行IT基础资源的管理与维护，一旦某个资源发生故障或问题，都可以从业务视图中直观地了解到这个资源的故障将影响什么业务影响哪些服务，进而了解到影响哪些用户。

数据库慢了，CPU突然飙升了，这些地方这些资源突然发生变化了之后，影响到哪些业务呢？这时候就需要将监控资源视图和业务关联起来，这样才能准确定位影响了哪些业务。

这个是问题的整体诊断和分析。

任何问题都需要采集相关的日志和数据，才能科学全面的分析问题。

采集层需要把不同数据源的数据采集过来，中间层做一些性能分析，配置管理和预警分析、告警处理。展示层将分析的结果展示出来，也就是各种图表，建立综合的业务指标分析，方便根因定位和解决问题。

三、基于大数据平台的日志分析和多维报表

基于大数据平台，提供日志的采集和聚合处理，通过日志关联分析帮助准确全面定位提升效能和满意度，智能预测和预警，为科学决策提供量化依据。

将采集到的网络监控数据、机房数据、服务器和云环境监控数据以及摄像头报警数据集中起来，数据汇集之后生成PMDB性能管理库，在根据业务应用的特征，建立不同的模型进行相应的算法分析。

根据不同的资源类来定义KPI指标，建模目的就是方便快速分析，为资源管理、告警管理、集中化展现等其他模块提供数据分析模型的支撑。

数据采集有两种类型，一种是被动的，一种是主动的。

采集业务相关指标，可以对数据进行预处理，做一些有效性的标签识别，比如这个信息和指标是不是你关注的，对不友好的日志进行格式化处理。

性能指标的计算，要跟业务进行协同，从业务的角度来定义。设置的阈值，有些场景是固定的，也有的场景是动态的。固定阈值就相当于资源使用率，肯定有一个上限的。动态阈值像一些性能曲线，CPU的利用率、页面响应、图片加载等这些是可以使用动态阈值的，根据历史数据来计算出这个动态阈值，某一时刻的历史峰值，根据这些合理计算出在那个时刻到底需要多少资源。

根据上面的阈值会有一个报警的事件，任何事件产生都是基于时间的，故障的定位肯定也要基于时间找到相关的日志和发生的事件。