大型企业智能运维深度解析 --- 孙杰

北哥

讲师简介

孙杰

听了有关AI运维之后有很多人感到比较焦虑，我所从事的运维或开发将来会不会被AI给代替掉呢？为什么会产生这个焦虑？现在新技术发展的特别快，各种语言、技术、理念让大家确实感到很焦虑。但是有一点，在这里我要特别重申一点，AI在目前这个阶段还是一种辅助大家来进行判断和学习，包括定位问题的工具。就像无人驾驶，现在可以做到完全没有人驾驶吗？肯定不行，无人驾驶在一些路比较宽，视线比较好情况下，是完全可以替代人的，但是在北京这样的路段，交通特别复杂的路况，人特别多，车特别多，无人驾驶还是完全不能使用的，因为它还有很长一段路要走。AI运维就像无人驾驶一样，未来前景很光明，但是中间还有很长一段路要走，它现在还是辅助人的定位。

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

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

• 第一个IT部门的整体认可不足。虽然说IT在任何单位现在都是一个比较重要的部门，但是还有很多领导仍然认为它是一个成本中心，不是一个利润中心，认为这个部门是花钱的，而不是像业务部门创造业务价值和创造利润的。
• 第二个对于运维工作人员负荷比较大，工作模式不被员工认可。比如像我所在的保障中心，我们面对中石油大概80多个运维系列，整个团队只有十个人，要处理这么多业务故障，每天打到服务台来的服务请求电话很多。如果每个人一天处理六到十个故障，基本上没有时间去研究别的东西了。在传统企业里面只能把运维人员逼上死路。在腾讯和京东，他们是把运维人员放到运维部门或者研发中心，研发中心的人既是研发也是运维的人，这样更加容易促进AIOPS的落地。
• 第三运行的态势相关信息掌握不足。监控会有很多指标，业务上有上千个指标，不同的计算和网络监控的指标都不一样，这很难成体系的，而且根据这些指标有时很难做去决定的。因为指标值不是固定的，有报警上下的范围，这个时候运维态势就很难保持平稳。
• 第四依据业务需求调整服务和设置资源的能力不足。在业务处理的时候需要很长的过程，中间涉及到很多的部门，需要和业务方进行交互，要控制资源的能力，仅靠十个人是完全做不到的。

我们希望在现有的业务体系里面，运维部门要实现什么样的运维目标和理念呢？

• 第一个全面的性能管理。能够提供对现在所有的设备和服务质量进行实时监测，并且提供阈值的告警。比如很多特别吃内存的业务，报了90%甚至95%都没有特别大的影响，还有像特别吃CPU的，这个怎么关注它？这个时候有没有影响到业务？还有网络的时延，丢包率等等。我们使用了很多商业软件，不同的版本有相应的错误，怎么去解决这些问题？很多时候厂商会给你提供一些解决方案，包括升级版本或者打一个补丁等等。这个性能管理，很多时候不光依赖于对这个产品的认识，还依赖于厂商的技术进步。
• 第二个统一的资源管理。很多企业业务都上云了，有了统一的监控平台，可以把所有业务相应视图都抓取出来，这样就便于我们对资源有一个合理的预估和分配，可以从整体角度评估各个业务部门对资源的使用情况。以前没有统一资源管理的时候，很多业务一下申请了很多资源，事实上用不了这么多，造成了一些浪费。
• 第三个及时的故障告警管理。我们发现有很多产品还不能做到完全及时的告警，希望有一个及时告警，告警发生后能够立即得到，甚至在业务没有出现问题的时候就能够预测。
• 第四集中统一展现管理。我们基础设施，像我们现在的能源行业，是多数据中心的，它们之间怎么来进行监控，怎么对它做一些异常的检测？在任何大型企业或者传统企业里面，运维部门分的都特别细，比如系统管理员、IT经理等等，做任何事情处理都有工单，要把很多相应的子系统集成起来，这个在现在的企业里面需求是很大的，像日常的巡检，借助于各种自动化工具，采集数据之后自动合成一个报表统一呈现出来。有了自动化才有智能化，自动化做好了，你的标准才能做好，包括对一些指标、阀值的定义等等。

我们企业存在的核心问题有：

• 第一我们是一种跨地域的平台，是多数据中心，我们希望有一个IT的综合运维平台，目前这块结合厂商的产品慢慢形成的综合平台。
• 第二是实现深入监控并进行集中统一的可视化管理，查看日志效率比较慢，而且不可能一下看太多的，非常麻烦。
• 第三就是有效的预防问题的产生跟快速定位故障，降低运维成本。问题出现后处理分析它的时间越长，花费的人力成本就越高。
• 多维的报表为决策提供支撑，通过网络上的，硬件上的和系统上的数据。
• 全局的业务视角和平台化的业务扩展以及大数据分析的融合，满足企业对于业务高效和快速迭代的需求。
• 保护和优化IT资产。以前各个业务都是自己的一套系统，有自己的开发和运维人员以及监控系统，这对企业来说是重复建设了。现在上云了后，就把原有的系统集中整合到一套云上面来，通过统一的监控和资源管理最好的保护资产。

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

• 第一个是规范化。规范化就是尽可能的把操作规范下来，比如第一步测试什么，第二步要分析什么问题，有一个规范化的流程。
• 第二个是可控化。就是能够通过云监控平台发现各个业务存在的瓶颈，包括页面响应时间上的瓶颈都能够通过云管平台快速统一发现。
• 第三个是数据化。只有形成清晰的数字才能方便作出清晰的判断和决策。
• 第四个是主动性。从被动响应变为主动服务，现在很多企业有云服务热线，这种相对来说都是比较被动，如果云服务商，能在你业务发生问题之前及时电话告知，这个感觉就不一样了。

我们希望构建的现代化和智能化的运维管理模式，这也是大家考虑的问题。

• 第一个就是系统都能够实现集中的监控，集中IT支撑和统一的调度，不管我部署在什么数据中心，通过一个云管平台就可以实现统一调度。
• 第二是传统企业里面研发人员比较少，有一部分可以自维的，有一部分可以专业外包的，比如现在市面上很多做性能监测的，像APM等等，他们这块做的很好，我们没有必要再自研了。
• 第三就是建设智能集中的运维信息化平台，要提高自动化水平，尽量的减少监控人员。通过平台主动输送信息。
• 第四是建立降本增效、绿色节能，全成本核算的效益管理模式。针对每一个业务拉取视图就可以知道资源使用的详细情况。
• 第五就是组建掌握网络、动力等相应的核心技术和运维支撑团队。现在要求我们运维人员什么都要会，到了AI阶段这些工作其实可以统一到AI工具上，它可以把各个工程师碰到的故障案例和处理经验，形成一些规范化的处理模型，然后输入到AI工具里面，这样可以形成一个更加智能的运维队伍。

2. 全景业务服务管理

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

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

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

建立以业务为导向的综合监控平台，主要目的就是要统一展现。之前大家都在说全链路压测和全链路监测，这个目的就是从访问入口进来后一直到数据输去，每一个过程都要能监控到。

从业务的视角进行IT管理资源的视图，可以捕捉到异常的点。在故障发生的时候，你能知道在这个时间点发生了什么事，同时还会在某些事件上反应出来。比如某个故障发生之后页面响应时间长了，数据库也出现了慢查询，CPU也突然一下飙升了，这些地方这些资源突然发生变化了之后，影响到哪些业务呢？这时候就需要将监控资源视图和业务关联起来，这样才能确定这些指标发生异常之后到底影响了哪些业务。

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

任何问题首先要采集上来，没有采集没有数据源没法分析问题的。

采集层需要把数据采集过来。
中间层做一些性能分析，配置管理和预警分析。
展示层将分析的结果展示出业务的各种图表。
通过这些才能够科学的去判断和预测问题，从而决策问题。

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

以前的日志分析没有像现在的ELK平台处理的这么快和及时。通过日志关联分析帮助准确全面定位提升效能和满意度，为科学决策提供量化依据。

将采集到的网络监控数据、机房数据、服务器和云环境监控数据以及摄像头报警数据集中起来，然后进行判断和分析。
数据汇集之后的PMDB的指标和模型，这个里面指标就很多了。把采集来的数据要做建模，然后通过这个模型进行相应的算法分析。
根据不同的资源类来定义KPI指标，建模目的就是扩展监控范围，为资源管理、告警管理、集中化展现等其他模块提供数据模型的支撑。

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

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

性能指标的计算，要跟业务进行协同，从业务的角度来定义。

阈值的判断，一个是固定的，一个是动态的。固定阈值就相当于资源使用率，肯定有一个上限的。动态阈值像一些性能曲线，CPU的利用率，磁盘的使用率，这些是可以使用动态阈值的。根据历史数据来计算出来这个动态阈值，某一刻有个峰值，根据这些合理计算出在那个时刻到底需要多少资源。

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

• 日志没有集中处理
  
  • 登陆每一台服务器，使用脚本命令或程序查看
• 日志被删除
  
  • 磁盘满了删日志
  • 黑客删除日志，抹除入侵痕迹
• 日志只做事后追查
  
  • 没有实时监控、分析
• 使用数据库存储日志
  
  • 无法适应TB级海量日志
  • 数据库的schema无法适应千变万化的日志格式
  • 无法提供全文检索

事件和时序的关联分析。某个时间段出现了故障，都会产生一些事件的，对它筛选和过滤是能够详细捕捉到故障和根因的。事件诊断一直是运维领域一个很重要的工作，事件和时序数据的相关性不仅可以为事件诊断提供很好的启发，而且在帮助进行根因分析都能提供很好的线索。

数据的汇聚处理就是把采集到的数据关联起来，压缩、过滤形成标准化的信息。
数据导入可以通过全量的HDFS和增量的Kafka来实现。

基于大数据平台的多维报表，根据自己的需要，按照日、周、月来生成运维报告，发送给运维管理层部门和领导，这些数据是他们比较关心的，会清楚这些时段里发生了哪些问题，造成了多大的影响，然后决定相关的资源是否进行扩充，相应的业务部署是否需要调整。

综合展示比较关注的是性能分析、容量分析和自动化配置。比如我今年采购了5TB存储，我用了多少，明年还需要扩容多少，业务增长量会有多少，这个都影响到企业的采购。我们每年集中采购一次，要写一些相关的招标参数，根据业务进行评估，来推算出明年大概需要买多少的存储量等等。

4. 统一展现事件及监控告警平台

IT监控管理的发展大概有三代，从上世纪九十年代至今，第一代是以网络为中心，在这个时候咱们提供比较多的都是基于网络的监控和故障发现，带宽管理和服务水平协议。第二代监控就是以监控IT基础设施为中心，看到比较多的就是主机、存储等等。第三代监控以IT应用为中心的，针对比较高度复杂的交易，像一些互联网公司，他们都是需要实现面向用户体验和面向应用可用性的实时监测和故障的智能诊断。

5. 故障管理及自治自愈

这是我们每天收到的告警情况统计。

做完优化之后我们希望通过反映出的信息里提炼出我们最想要的信息，从而减少每天的告警信息量。

目标就是简、智、深。

简就是要确保业务和SLA服务级别，出现问题要及时的响应和维护。

机器学习主要就是突出智，这个需要大量的数据，故障出现的形态是千奇百怪，对故障的历史数据进行标注，然后机器才能够判断。标注不能完全靠人，也需要通过机器来自动进行标注，而标注的合理性就需要人为进行判断。然后再利用到机器学习上，这样才能真正辅助我们做一些决策。

基于功能架构、工程师的经验和概率来做到收敛告警事件。
基于规范和分工产生告警事件。
基于数据和模型来提高事件的处理能力。

很多事件有的工程师处理特别快，如果对这个故障不熟悉的人可能花费的时间就很长。这就需要构建一个策略知识库，让其他人来参考，提高事件处理的能力。

自动化包括智能化，实现的目标就是减少对人的依赖，逐步信任机器，实现机器的自判、自断和自决。

技术都是在不断的进步，AI技术会解决很多的一些需要花费大量人力时间才能解决的事情，但是AI不是一个很纯粹的东西，它也需要结合具体的企业场景和业务，才能产生一个真正可用的东西。

智能运维的终极目标一个是日常工作都能自动完成，另一个是运维人员都能够独立的进行数据分析。