智能时代下的冷思考：回归ITOA

1、假如运维数据可以这样用

运维人员每天面临很多零碎的工作，有各种渠道而来的问题咨询、多个监控工具的报警，以及各种非计划性和计划性的工作，相比于其它工种，运维人员更需要一个综合性的技术与管理能力，需要掌握大量的方法论与技术栈。

面对多样化的运维工作服务目录与服务能力要求，运维人员通常会疲于奔命，被动的应付各种突发事件。自动化工具的出现从工具层面解决运维人员这些常规的操作效率与风险问题。但是，自动化也出现一些瓶径，很多自动化工具并不是针对完整的运维工场景，而是以解决某个环节的操作自动化而设计，这导致很多工作依赖于运维人员经验来回切换多个零散的工具或交互页面。 如何学习以人为本，从工具功能实现的层面上升到解决用户一项完整的运维工作场景，依托于运维数字化场景，打破数据孤岛，实现信息（加工后的运维数据或工具）的互联互通，让运维人员既能从全局把控，又能局部洞察细节，是运维开发团队需要关注的思路转变。

为了说明这个转变的意义，这里举一个假设，一个并非太难实现的假设。

假设我们利用运维数据与工具为一线值班人员构建一个集中事件处理的数字化工作场景，集运维总控待办、事件概览、事件丰富等几个最佳实践整合的运维场景可视化：

• 全局事件概览：当天共发生6个事件，1个为二级预警事件，5个为通知事件；
• 事件描述： XX系统XX业务交易量指标连续5个采集点低于历史工作日基线的关注区，历史数据关注区为【50-150】，异常区【25-200】，当前为值为【30】，预计出现异常。
• 关联级别：【二级预警事件】
• SLA状态：【处理时长】
• 配置信息：
• 基础配置：围绕该指标采集点的服务器OS的cmdb基础配置信息
• 纵向配置：以拓扑方式呈现基于基础设施、网络设施、硬件设施、操作系统、应用域的纵向配置，并标注每个节点事件汇总情况；
• 横向配置：以拓扑形式呈现的交流逻辑调用关系数据，比如上下游节点的事件情况；
• 事件丰富：
• 关联事件：基于历史学习或经验库结合的方式，绘制当前发生事件的关联关系拓扑数据；
• 现场数据：

- 历史运行基线情况：基于历史工作日运行数据为基准的学习后运行基线，标注当天运行数据走样，以及数据走样趋势预测。 - 监控指标现场数据：当前事件背后指标的基本信息，采集事件发生前后指定时段的历史数据 - 关联日志数据：基于历史经验库的日志关联，或日志分析推荐（异常日志信息）

• 关联流程数据：

- 变更流程：基于事件关联分析涉及的变更流程，以及指定变量时间段的变更流程的可视化关联 - 配置修改流程：基于事件关联分析涉及的配置修改流程，以及指定变量时间段的配置修改流程的可视化关联

• 可能的影响分析：

- 基于事件关联的影响分析 - 基于事件的故障模型的影响分析

• 应急处理决策：

- 经验库关联：基于历史经验的最有可能解决方案的关联推荐选择 - 应急工具推荐：基于历史经验的最有可能应急急工具的推荐

• 关联其它分析数据：

- 关联性能管理工具数据

• 其它

如果有机会，我希望能使用或设计这样一个数字化场景，这个场景主要包括运维总体状态的全景总控、事件集中管理工具两大块，为了工具具备更好定制化，需要工具可定制性，以更快的落地这些场景，不过这不是本篇的重点，本篇主要是想从上面这种基于多维数据与工具整合的场景化解决思路进行扩展，总结出一个更为通用的解决思路。 为了保证数字化解决思路扩展性，且保持一定的严谨性，我想找一个己有、成熟的方法论来支持我这个想法。

于是，我找到了ITOA.

OK，下面就从美帝的企业服务市场发展看ITOA如何出现。

2、ITOA如何从美帝企业服务市场出现

研究美帝的企业服务市场的ITOA主要基于两个因素考虑：

• 美国的企业级的运维服务市场发展情况远好于国内，这一块从估值可以很明显的看出，以5月15日股价看，美国的SPLUNK公司(日志处理)市值是162.53亿美金，servicenow（ITSM公司）市值306.94亿美金，国内企业服务，比如日志易（未上市）从体量看差得很远，ITSM的企业则并没有未有出现有明显优势的企业。
• 国内的运维服务容易出现跳级的情况，即很多企业自动化、数字化水平还一般，却开始大力鼓吹AIOps，甚至是NoOps，这种氛围下不利用形成一个务实的方法论。

基于上述两个因素，我对美国的ITOA的发展进行相应的调研。

2.1 专家式运维、APM、ITOA

为了更好的说明ITOA的一个演变的过程，我画了一张图：

可以抽象出三个大的流程

• 以专家经验式的运维解决思路

以专家经验式的运维在解决问题时，主要是基于实时监控、事件集中处理工具进行事件处理，当事件发生后，由运维人员的专家经验介入判断事件的影响，并决策进行相应的应急处理，问题定位，并进行故障恢复操作。故障应急处理之后，通过管理手段强化事件的总结，进行举一反三的事后优化，减少重复故障的发生，降低事件处理过程中的管理与沟通问题。

• 引入APM提高问题的解决效率

随着业务系统技术栈越来越复杂，业务系统的问题复杂度己远无大于基础设施问题的复杂度，以专家经验式的问题解决方案己不能满足要求，这时就出现了针对应用管理的APM工具出现，APM是通过收集第三方主动模拟拨测、前端应用埋点、客户端数据采集、服务端代理采集、网络旁路等渠道采集的性能数据，并对这些性能采集数据进行分析与建模，也就是说APM将应用运维人员应急处理的专家经验通过性能数据指标化，是这一个最佳实践的一个落地。

• 形成ITOA的解决思路

随着大数据技术在业务领域的遍地开花，企业服务上云等背景，有一些专注企业服务的IT企业开始考虑运维大数据的解决思路，比如splunk的出现成功引出了大批先进的解决方案。在此背景下，gartner提出了ITOA的建设理念，ITOA（IT Operations Analytics）是利用大数据统计分析处理技术方案对海量的运行数据进行运营分析，ITOA可规模、复杂度越来越大，变化频繁的软硬件环境中自动高效收集、整理、识别、存储，并为IT运营或业务人员提供简易的数据消费场景。美帝对ITOA的预测是2020年ITOA的市场大概是97.9亿美元。

ITOA可以落地的领域有很多，比如：

-容量分析：预测、成本、扩展

-运行分析：多方位、高效的分析

-客户体验：快慢（性能），好坏（业务）

-安全审计分析：防、控、审

-服务能力分析：流程、KPI、能力

-数据检索：实时、定制

-可视化：配置蓝图、运行状况全景

-辅助业务运营状况的分析

-AIOps：智能监控，预测、定位、决策

这中间比较火的是2016年由Gartner提出AIOps（AlgorithmicIT Operations），是基于算法的IT运维，即通过使用统计分析和机器学习的方法处理从各IT设备、业务应用、运维工具收集的数据，从而加强增强运维自动化能力，以便更快、更有效、更全面的实现自动化效果。不过，从当技术发展的情况，AIOps更适合局部的智能解决方案，从落地看主要是在监控领域，所以ITOA更适合作为运维数字化建设的技术指引，AIOps则作为ITOA在某个局部的落地方案。

2.2 总结一下ITOA

前面提到ITOA是利用数据统计分析处理技术方案对海量的运行数据进行运营分析，ITOA提供在规模、复杂度越来越大，变化频繁的软硬件环境中自动高效收集、整理、识别、存储，并为IT运营或业务人员提供简易的数据消费场景。当前，ITOA在信息系统运行过程中的问题识别、分析、处理等环节，信息系统性能与容量等IT分析领域等技术领域有不少成熟的案例，比如APM、NPM，这些解决方案促使了IT运维团队具备更为全局性的把控IT运行状况，并能在某些环节更细致的定位与判断。随着大数据解决方案、人工智能等技术对业务领域不断落地，IT运维组织发现利用大数据技术对运维产生的数据进行分析关联处理，能够进一步解决运维过程中遇到的信息系统复杂度、规模越来越大，业务对变更要求更为频繁、信息孤岛等痛点。

基于ITOA的技术解决方案通常需要具备几个步骤：

• 数据集中：来自服务端（有客户端数据更好）的各类运行数据，主要有五类：监控数据（性能指标、事件数据）、日志数据（含应用、中间件、数据库、操作系统、机器硬件等）、配置数据（基础配置、关联关系数据）、关键业务指标数据、流程数据（变更、配置修改、经验库数据）
• 计算平台建设：针对运行数据的实时计算所需要的计算平台，需根据不同的场景、数据类型的不同选择不同的技术栈，并基于数据分析逻辑定制层面的设计，比如标准化的服务与接口，运行数据消费的应用工具；
• 上层应用工具的落地：数据或数据计算平台是运维数据应用的基础，最还是要落地为应用场景，在应用场景方面可以分为技术与业务运营两方面，技方面比如统一运营待办场景、事件集中处理场景、变更场景、服务台场景等；业务运营比如客户体验分析、业务活动推广状况等场景。

需要补充的是，我觉得ITOA并不一定要用大数据的平台，数据也不一定是海量的数据，我认为ITOA重点是针对运维数据的有效利用，通过数据实现运维场景的互联互通，通过数据为运维提供主动分析、智能决策的技术保障，甚至是业务运营的能力。而大数据技术栈是为了实现上述数字化目标提供的计算机解决方案之一，如果你的数量级只是几千万，则关系型数据库即可满足更为高效的应用，只是基于当前运维复杂度越来越高，数据量越来越多的情况下，大数据的解决方案很多时候被选为最佳方案。

3、运维痛点

上一章调研了美帝针ITOA的形成，并对ITOA进行了解释，接下来我们看看ITOA能解决什么运维痛点。

(这一章有点罗嗦，可以考虑略过@_@)

3.1信息系统越来越复杂，数据规模越来越大，变更频率越来越密

随着业务的发展，IT系统呈现越来越复杂的状况，主要表现在以下几方面：

• 应用程序变得越来越复杂，一方面支撑应用的纵向的资源供给、调度越来越复杂，比如基础设施、网络、硬件设施、操作系统、虚拟化、容器、数据库、中间件等复杂的资源供给链；另一方面大部份业务都依赖于多个第三方组件和服务，这些组件和服务组成一个复杂应用关联调用链，形成一个复杂的应用程序技术栈;
• 企业推动devops敏捷交付带来更好的IT价值，但副作用也很明显，变更越来越频繁，系统稳定性不可避免的受到挑战（这一点，可能会引起争议，我先保留意见）；
• 在应用程序环境和IT架构的复杂性、应用规模日益增大的背景下，运行过程中产生的数据也呈现非线性的增长趋势，比如以3000个OS规模的企业，每个OS有100监控指标，每个指标每半分钟采集一次性能数据，则一天将产生8.64亿条数据流水。同时，这个监控工具的性能流水在海量运维数据中的占比小很多，比如日志数据比监控数据大得多。海量的运维数据妨碍了运维组织对运维数据的应用消费。
• 由于企业对IT运维组织的认识和投入通常不如直接面向业务需求的IT团队的资源投入力度，所以运维组织除了面临的海量运行数据的收集、治理、存储、计算、应用的技术与资源挑战，还要寻求一种更为高效、经济、扩展性更好、易管理的解决方案是处理海量运行数据的难题。

3.4 信息孤岛带来的低效率

有不少经验丰富的运维人员花了大部份时间在救火的工作中，当应用程序出现或需要解决问题时，大部份人都会在各自的孤岛（网络，服务器，数据库，虚拟机、应用日志、报警事件）中探究问题，甚至同样是应用运维团队的多个应用系统运维人员都会根据自己负责的应用系统报警进行分析。由于团队里的运维工具通常会很多，所以很难有一个地方可以看到别的团队所掌握的信息，这种问题分析的方式通常是低效的，甚至当沟通出现时，通常是相互推责的出现。同时，经验告诉我们，很多时候异常是有关联的，比如变更可能会影响性能或功能使用，上下游应用的故障会产生事件影响的“雪球”或“多米诺”效应，但现有一方面很多工具注重功能，忽视用户交互，另一方面独立的工具无法实现多个维度的信息全景关联展示，影响运维对生产运行状态的全局把控，以及洞察细微的能力。

上述信息孤岛的问题有两个突出的表现，一是低效率的协作；二是运行数据的全景式的可视化。为了解决信息孤岛的问题，建立面向运维场景的统一工具，支持不同的团队在某个运维场景的协同办公，统一的工具后台集成当前 IT 运维管理工具和实践的数据分析，以合理优化整体 IT 服务性能，指导业务作出明智决策。

3.3 依靠牛人效应，被动的运维工作方式

IT部门有责任建立和维护具有高可用性（在预算和可用资源范围内）的IT环境，由于性能和事件监测数据量的快速增长，IT运营面临的挑战加剧。对于许多运维人员来说，尤其是团队里的运维牛人往往花费太多时间来维护和支持，而没有足够的时间将这些牛人的经验沉淀下来，当牛人不在时，问题的处理效率将大大降低，甚至无法处理，且运维经验很难有效传递。

另外，上述的运维方式，其实是救火的方式，根据海恩定律，每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆，以及1000起事故隐患。理论上讲，如果运维能够对系统进行分析，则可能实现救火到防火的转变，以达到主动避免性能或可用性问题。

3.4传统监控能力的不足

针对当前运维的复杂度，传统监控能力有一些瓶颈，比如工具太多，没有整合，监控误报多，漏报情况频发，监控事件没有及时处理等等，以下从数据角度分析监控的两个不足，一是针对性能指标数据，二是针对事件数据。

• 针对性能数据的监控策略设计问题：

传统的监控是基于历史发生的事件，结合运维人员的经验，转化针对关键运行指标固定规则阀值的监控方式，其本质上是对历史事件最佳实践的沉淀，当出现问题时主要是描述事先定义的警报症状描述，比如响应时间慢，交易失败，性能超限。经验丰富的IT运维人员遇到这个报警后，会基于过去的经验对报警信息进行解读。由于很难有人能设计出全面的规则与阀值，所以当前基于这种固定监控指标的方式有三个明显的缺点，一是会产生漏报，很多性能指标是一个有规律的波动过程，采用一个固定基准阀值会导致一些潜在事件的漏报；二是大量误报，即监控工具人常常遇到的“监控风暴”的问题；三是基于历史经验为规则导向的配置方式，容易忽略了新问题的出现、报警慢的问题。

• 针对监控事件的处理能力：

在监控事件处理能力上通常有以下不足：

• 应运运行于复杂的IT基础设施以及应用模块之上，需要各类监控工具实时监控设备，服务器，数据库系统，交易应用程序等运行指标，这就造成多个监控工具事件数据无法关联的问题。
• 仅仅监控工具数据是不够的，还需要其它关联的数据，比如性能指标数据的关联，变更的数据的关系，只有对各种运行数据进行分析、数据挖掘，并提供可视化，而不再仅仅是查看孤立的指标，才能具备整体把控，洞察细微的IT能力。为了整体把控，评估整个IT基础架构的健康状况， 运维团队需要有来自多个应用程序（以及不同监控工具）的数据，通常是集中的运维数据集合，整合了数百或数千个不同的数据流，且具备有准确的配置数据进行数据整合。 为了洞察细微的IT能力，需要针对具体的场景设计统计算法，实现自动化事件识别、异常检测、关联分析、问题定位等细节。

3.5 仍以被动运维工作为主，缺少主动运营的能力

长期以来，运维工作被定位为维护操作工作，在其它团队的潜意识中对运维的定位通常是保障生产运行，主要是救火为主。救火，顾名思义即准备好各项应急措施，以应对生产运行过程中的各种问题，这种工作状态导致运维工作缺乏计划性，长期处于补漏补坑的状态。同样是针对“火”，假设我们能够做得更前一些，提供发现生产环境潜在的火灾隐患，将更多的工作状态改为“防火”则将由被动运维向主动运维转变。要做到“防火”，则需要运维团队能够掌握生产环境当前，接下来运行趋势，发提前做好相关有效的措施应对接下来将发生的状况。运维数字化可以从全局与局部提供运维分析的数字化体验，并整合在运维工作的场景中，比如，应用的二线运维人员可以通过生产环境性能数据的分析发现性能运行状况，一线服务台人员通过服务台SLA执行情况发现IT服务质量，基础设施资源管理人员从资源利用率的分析以优化成本等等

同时，我发现很多企业的大数据团队通常关心如何获客、如何形成交易、如何进行业务创新。运维团队手握各类生产应用运行过程中的运行数据，有利于对当前运行中的应用进行分析，发现当前业务开展的状态，是否可以通过某些环节的优化，是否可以改善客户体验，促进当前业务的发展，即基于生产环境运行中的数据有助于现有业务更好的运营。运维的数字化建设与业务大数据建设是一个互补的过程。

4、如何开展ITOA

4.1应用建设思路

很多企业都建立了基于业务的大数据团队，在金融业里的用户画像、资金圈、精准定位、获客等方面有很多成功案例，这些大数据团队规模通常会大于运维团队，为了减少企业重复建设，运维团队的ITOA方向需区分于业务大数据的建设。当前ITOA的业务方向可以趋向于技术与业务运营两部份，其中技术是指整合性能、容量、可用性、服务台服务水平、监控等角度，业务运营层面主要是客户体验、业务开展效果等运营类的分析，技术与业务运营的分析都基于整合式的运维场景进行整合。

从技术平台的建设角度看，需要关注数据的集中管理，基于各类数据性能及使用场景需求的技术栈，未来可扩展为智能运维的数据建模支持，以及各类特定运维场景的可视化工具。数据集中、存储、处理等技术栈主要是以开源的大数据架构为基础，不同的运维团队通常采用以下几个不同的建设方式：

• 完全自建：

这种建设方式要求运维团队利用开源技术结合自身需要进行二次开发，这种方式在互联网企业比较流行，但需要正视的是，很多开源的技术或多或少会存在一些BUG，从运维大会的分享看类似BATJ这种大型的企业，他们在人力方面比较充裕，他们往往会对相应的开源架构进行改写以适应实际需要。一些小的互联网企业，比如一些视频网站，则将大数据架构保持尽可能简单，只要支持特定的需求即可。

• 外购开发资源或工具产品：

这种建设方式适合需要快速取得成效，但运维团队人员比较少的情况，在这种项目中，运维团队主要是承担产品经理的角色，即运维团队根据企业的痛点，提出贴近企业的运维数据分析需求，以及项目落地所需要协调性工作，这种建设方式虽然投入收效快，但是对外部资源依赖比较大，不利于后续持续建设。

• 外购与自建相结合：

这种建设方式是目前很多同业采用的方式，即技术平台在建设初期时采用外部资源与内部运维团队投入人力一起建设，运维团队在整个工具体系下，针对局部独立性很强的模块考虑采用成熟的商业套件，同时尽量要求这类成熟的工具需要开放一定的接口或源码支持，对于一些与公司个性强的环节采用自研的方式。

综合金融企业运维团队目前的技术实力与投入产出比来看，通常采用“外购与自建相结合”的方式，运维团队对工具进行技术掌控，并在工具体系的上层为其它运维人员提供简易的、可创造性的“开发能力”，比如所见即所得的工具可视化、可定制的运维报表、拖拉拽方式的流程及脚本组件的拼装等数据消费能力。

4.2 技术实现

4.2.1 ITOA技术整体架构

我觉得从平台需要解决以下四个能力：

• 数据整合：数据平台需要承担生产运行数据的整合作用，原则上，为了减少数据熵减，建议数据平台需保存生产环境原始的数据。基于海量的生产运行数据，以及多种数据消费场景，需要数据平台具备多种类型数据存储的技术解决方案。
• 数据处理：对于运行数据，平台需要提供数据治理、分析建模，以及为适应人工智能算法提供人工智能建模的能力。同时，数据平台需要具备高可用，需要配套的数据平台健康性保障能力。
• 平台能力：基于数据处理后的基础数据处理能力，则需要平台提供数据能力，包括检索、可定制的数据报表、验证回溯算法可行性、数据消费接口等平台能力。
• 分析能力：有了基础的数据平台能力，则需要建立场景化的数据分析能力。严格上看，这块能力最好落地在统一门户，或操作平台、监控平台、信息安全平台等平台工具上，数据平台提供数据消费支撑，统一门户或其它平台提供数据消费的落地场景的实现。比如，在统一门户上实现数据运行状态的全景视图、提供运行分析报告工具，在监控平台中实现生产事件统一管理工具。可以说，数据平台将为工具的深度提供数据支撑。

基于上述的背景，数据平台可以考虑分两个阶段建设，第一阶段以建立高质量的数据集中为目标，第二阶段以数据之上的数据消费为目标，在数据集中整合的基础上，建立运维数据平台，主要以大数据分析和机器学习技术，构建基于运维数据的分析平台。

以下列出一个相对标准的数据平台架构：

关于大数据平台的建设并非我所擅长的领域，所以在这里不进进一步扩展，接下来我将从运维人员擅长的应用场景作一些调研总结。

4.2.2 ITOA离不开数据

4.2.2.1有哪些数据

运维团队手握大量生产数据，应该采集哪些数据呢？

ITOA的业务目标可以分为技术与业务运营两部份，其中技术是指整合性能、容量、可用性、服务台服务水平、监控等角度，业务运营层面主要是客户体验、业务开展效果等运营类的分析，技术与业务运营的分析都基于整合式的运维场景进行整合。

基于上述的技术与业务目标，我们可以将ITOA的数据归纳为5类：

• 监控数据

重点包括两大类：各类监控工具的性能指标、事件数据，性能的指标数据可以用于构建运行基线，容量评估、故障预测等，事件数据可以用于事件关联分析，整体的生产运行状态的概览等分析场景。

• 日志数据

重点包括：应用、中间件、数据库、操作系统、机器硬件的日志。日志数据可用于用故障定位、监控，机器操作日志还可以用于审计等风险控制等。

• 配置数据

重点是纵向的基础配置CMDB、横向关联关系数据，以及应用配置库、网络配置库等配置数据，配置数据的主要作用是实现工具或数据原子之间的互联互通。

• 关键业务指标数据

重点是业务量、交易量、用户数等重要指标数据，这类数据主要是用于辅助业务运营的分析。

• 流程数据

重点是变更数据、配置修改、经验库数据等，这类数据是用于辅助分析，比如变更数据可以辅助故障定位，经验库数据可以用于提高服务台水平等

数据的使用场景将随着数字化场景的不断落地而发挥更多，更重要的作用。

4.2.2.2采集方式

很难有一种通用的数据采集方式可以方便快速的实现监控数据、日志数据、配置数据、关键业务指标数据、流程数据这5类数据的采集，所以这里收集了一些可供数据采集的技术方式。

• 硬件设备或操作系统主动推送数据，比如采用syslog的方式推送网络设备、操作系统日志；
• 网络抓包解码，比如代理抓取网络通信协议、网络端口监听等数据，或通过防火墙旁路，比如NPM的解决方案；
• 服务端代理，比如应用日志、数据库日志数据、监控实时数据等；
• 应用探针，这一块通常需要开发的介入支持，在前端页面或后端的日志上打印数据；或者采用另一种在节点类的应用或组件上部署采集点的方式，比如在JDBC包，Log4j包等采集数据。
• 数据库访问或接口访问方式采集数据；
• 外部拨测数据，主要是采集用户体验，验证前端功能响应数据；
• ……

总之，不同的数据采集通常会有多种不同的解决方案供选择。

4.2.3、数字化场景

上面提到了ITOA数据集中与数据场景消费两个阶段，第一阶段的数据集中，目前己有相对成熟的技术解决方案，实施难度适中，第二阶段以数据场景消费的建设并不多是ITOA的难题，关于这个难题，我觉得可以考虑以前面提到的“帕累托原则”，选择“投入产出比高、痛点明显、收效快”的数字化场景的建设分步完善数据处理及平台能力的建设。另外，对数字化应用场景我们倾向于基于运维的某一项基本完整的工作，对于生产数据的实时检索，比如日志实时检索、基于运维数据的一般性定制报表我们觉得是数据平台的基本能力，不在数字化场景分析中扩展。数字化场景的落地以工具的形式落地，通过统一门户，以及各工具间相互调用来实现数字化场景的整合。

所以说，通过数字化场景建设，促使了运维各类工具间的互联互通。

以下，是我归纳的几个重要的数字化场景：

l运营全景控制台：在数字化场景建设中，如同很难有一个自动化工具可以实现大部份运维操作，数字化场景也会很多，所以需要有一个运营全景控制台负责整合运维场景。运营合景控制台以整合运维KPI重要指标的主要思路建设，KPI应该能反映出应用整体的可用性，当前值班团队日常工作的处理水平，具备多角色、可定制，可作为运维团队日常运维工作的统一入口。

l基本底线保障场景：运维的底线有几项，比如应急、巡检、业务咨询等，这类场景的建设一方面可以基于其它平台的工具进行整合，也可以基于统一门户整合己有工具，比如，可以基于监控平台的一线事件统一处理工具作为应急的数字化场景建设，基于流程平台的服务台工具作为业务咨询的数字化场景建设等，当然，也可以有针对性的建设一个新的面向场景的工具。

l主动运行分析场景：主动运行分析可以分为技术与业务运营的之分，主动的运行分析包括容量分析、性能分析；业务运营分析则可以根据业务实际开展的情况进行个性化的场景设计。以场景的思路建设，则不仅仅是出具数据统计报表，它应该是从运行分析的思路，转化为数据的建模，分析结果的输出，报表的定制，以及整合分析结果的后续跟进，辅助一项相对完整的运行分析工作。

l自动化工具的深入扩展：狭义的运维自动化，可以分为“监、管、控”三部份，其中“监”指监控，“管”在我们公司主要是管理流程的工具化，比如ITIL，“控”是操作自动化，这一块最大，比如资源交付自动化，系统软件安装自动化，补丁安装自动化，批量脚本执行自动化，系统数据收集自动化，变更部署自动化，服务启停自动化等。数字化场景建设，通过提供多维度的运行数据，提供工具的深度，比如基于对性能指标数据的分析，为监控工具提供动态基线，基于事件数据的分析，为事件的处理提供事件关联分析等等。

4.2.3.1运营全景控制台

如上一节所说，运营全景控制台工具以整合的思路构建，将运维人员关注的KPI要求指标化，统一整合可视化。针对不同的运维人员关注度的不同，将重要的KPI指标整合在一个控制台，控制台负责根据KPI指标与各工具互联，比如以下这个针对一线运维人员的运维控制台可视化方式：

控制台实现多个场景工具的KPI指标数据的整合，比如监控报警数据由监控平台的事件集中处理工具提供，变更情况数据由流程平台提供，工单处理情况由服务台提供等。针对指标可以链接到具体的其它场景工具。另外，针对不同角色的人员，关注的KPI指标并不一样，所以，控制台场景需要具备关注指标可定制的能力。

4.2.3.2基本底线保障场景

运维的基本底线工作主要包括数据备份、可用性、故障应急等，以往运维团队主要靠管理手段，以及运维人员的自律、经验实现这些底线工作的落实，随着团队的扩大，这种方式是不靠谱的，很容易出现重要环节的遗漏，操作方式不合理，操作过程未留痕等问题，同时原有的自动化工具主要是为完成某些操作动作而设计的，一项工作通常依靠人的经验在多个工具间操作。基本的底线保障场景则是针对最重要的运维工作建立数字化场景，在场景建设方面中，一方面可以基于原来的工具按完成一项完整的工作进行重新优化，另一方面可以新建一个场景化的工具，实现多个工具间的整合。两个方向的总体思路都是以完成一项完整的基本底线工作为目标，通过融入运维数据，实现多个工具之间的互联互通。以下，以事件集中处理的数字化场景工具为例：

监控平台的建立是“系统不宕，数据不丢，业务不断”的运维底线保障基础，监控的基本目标是“不漏报、快处理、不误报”。但随着系统规模及数据越来越大、业务功能及技术栈越来越复杂、业务要求越来越高的背景下，监控平台中容易出现监控覆盖率不够、误报多、告警风暴、监控工具多、监控管理复杂等问题，需要对己有的监控平台进行梳理、数据汇集、分析处理、可视化，让监控成为能解决或辅助解决问题的监控。实现上述目标，监控事件整合是监控体系建设的重中之重，主要包括基于公司CMDB为基础，实现事件统一管理工作台、灵活且全局的可视化、辅助事件管理（告警、关联、辅助定位、应急）、事件管理的统计分析，这个过程即是事件集中处理的数字化场景。

在设计角度整体的细节要求：

• 实现各监控工具事件数据快速的统一汇总接入，并提供用户对事件主要策略进行可视化配置，提高事件的精确度；
• 实现全公司监控事件的统一管理，提供多角色用户，可定制的可视化管理，作为统一的监控事件管理控制台；
• 提供事件“监”、“控”处理一体化的基础能力（事件丰富），提供关联学习分析的扩展能力，同时事件丰富视图元素可进行配置，以备后续整合监控性能数据；
• 提供事件管理涉及的及时率、事件误报等报表统计分析能力，以支持监控管理的持续改进；
• 高性能，提供具备秒级的事件刷新能力；
• 以统一的CMDB数据为基础，具备关联事件处理、服务台、流程平台工单、事件流程等其它工具的基础，以场景消费提高CMDB质量回馈CMDB。

事件丰富的一些可视化视图在我的其它有关监控体系的文章可以看到，这里不再列出。

4.2.3.3 主动分析场景

前面提到，运维的数字化分析需要区别于大数据业务分析，在初级阶段，我们主要从两个思路开展，一是技术角度，重点在性能，容量，审计三方面。二是针对性对业务运营状态进行分析。其中性能分析主要目标是通过发现运行风险，推动运维优化，反推开发优化程序；容量分析主要目标是辅助容量管理；审计则是为了提高运维风险管控; 业务运营分析是为了促进业务更好的运行开展。

需要注意的是，主动分析的数字化场景需要形成一个相对完整的工作，所以在场景的构造过程中，需要从数据的输入、分析处理、输出，以及输出后的跟进处理，形成一个闭环，这样才能数字化场景的最终目标。由于篇幅有限，以下只梳理性能、容量、审计场景方面的一些技术上关注的点，具体的场景化探讨后续再作展开。

A、性能

• 应用角度

应用性能角度，可以从交易量、成功率、单笔耗时三个维度进行分析，其中比较有效的方法是针对交易类系统的分析，数据来源可以从WEB日志，数据注交易流水（至少需有交易时间、交易成功状态）的数据。

在分析过程中，可以考虑抓典型的思路进行分析，比如采用TOP几的方式抓到性能瓶颈的应用，OS，开发项目组，业务功能、请求等方面。

• 数据库角度

数据库DBA专业化往往比其它领域的管理员更俱有专注力和专业，且DBA面对的对象范围比较少，如能将DBA的专家经验转化为标准化的DBA日志分析，投入产出比可能比其它领域更高。

同理，系统管理、存储管理方面，也会比较应用运维更标准化，更易自动化。

B、容量

容量分析主要针对资源，比如CPU、内存、磁盘空间、带宽，对容量的分析首先需要有一个标准知道容量是否足够，其次是可供容量分析的指标数据，从存量数据来源看，监控数据满足此条件。

• 基本的容量分析

这里基本的容量分析是指当前运行是否资源足够，由于监控事件是高于阀值的报警数据，对报警信息进行整合分析，可以比较快速发现己存在容量瓶颈的指标点，比如CPU,空间不足，再通过CMDB可以关联到具体的OS或业务系统。

• 运行基线分析

大部份监控阀值是一个固定值，所以只以监控的报警数据会存在误报情况，如能针对系统指标运行情况计算一条运行基线，把运行指标偏离运行基线过多的数据进行容量判断可以更加准确。同样，运行基线也可以作为性能的分析基准。

C、审计

• 可疑登录用户行为

做实时统计，统计任意时间范围内，10分钟内连续出现2个登录ip的用户。对于历史数据统计出最近一次登录用户，时间，上一次登录时间，时间相差3个月的列表，对于实时数据，进行实时告警，发现第一次登录或者3个月以前登录的用户进行告警。

• 频繁登录的用户行为

登陆情况统计(新增) 筛选出从一年内登录次数10次/登陆频繁的用户(TOP 10)/登录次数超过N次，统计出用户登录次数top10。

• 高危命令监测

监测开市期间执行命令"update、insert、delete、drop、alter、rm、chown、remove、stop、move、 mv 、kill、load、import、shutdown、configure terminal、system-view"，并统计分析出top 10。

关于分析，我再摘几张在servicenow上看到的分析场景：

4.2.3.4 提高自动化工具的广度与深度

ITOA可以提高自动化工具的广度与深度，广度上，比如对数字的运用可以增加工具的功能，通过数字可以实现与其它工具的互联互通等等；深度上，比如利用数字的分析，可以解决自动化解决起来费力，或无法解决的问题。

为了说明这个问题，我尝试从监控平台的自动化工具方面作一些介绍：

A、广度

• 增加错误关键字报警

针对业务日志、系统日志、数据库日志等高危异常信息字段进行监控，当出现此类异常信息推动报警系统接口。

异常字段的选择，可以考虑针对出现次数据的阀值进行匹配判断。

• 增加性能报警

针对交易量、交易成功率、交易耗时的突降或突增进行监控，其中类似nginx等WEB日志，业务流水表（采用SQL），比较适合此类监控。

• 增加异常操作报警

针对审计日志的异常操作情况，比如异常的时间，场合，通过异常的方式，实施了异常的操作行为进行监控报警。

• 对监控指标数据进行二次分析报警

针对监控工具提供的指标类数据进行二次分析，发分析报警。

B、深度

• 动态基线

更准确（减少误报，发现运行规律，直观感受运行历史情况）、了解常见错误以及指标中的峰值和上下限之间的差异，更及时的发现潜在问题；（异常检测可以在大量数据发展成为真正的大问题之前发现问题的早期迹象。使IT团队能够缩短故障排除时间并减少虚假警报的噪音，使他们能够在问题达到关键比例之前发起攻击并解决问题。）

• 并行运行多个分析

同时分析多个数据源，识别系统内相关的异常关系，当多个事件同时发生、运行状态的数据信息，集中提供给运维人员时，有助于运维人员更高效的处理问题；

• 基于异常数据的统计

可以按概率、变化情况、严重性进行排名，集中力量去处理重点的问题

4.2.3.5 其它场景

由于篇幅问题，还有不少场景，比如基于服务台的联动的客户满意度管理场景、基于人工智能算法的智能监控处理场景，基于针对性业务运营的运营场景等等。这里不再一一列出，在实际实施过程中，可以考虑先解决痛点，解决投入产出比更高的场景。

OK，本月运维体系总结先告一段落，计划下一篇是关于IT服务能力的梳理。