| 编辑推荐: |
本文主要介绍了运维数据中台的探索与实践，什么是运维数据中台、如何建设运维数据中台、运维数据中台建设难点及运维数据中台的发展方向，希望对您的学习有所帮助。
本文来自于微信公众号twt企业IT社区，由Linda编辑、推荐。 |
|
1 、前言
企业在数字化转型过程中运维遇到很多痛点如发现问题难、根因定位难、故障预测难、运维数据治理难、容量预测难以及各种运营大屏需求等，建设运维数据中台可以有效的解决这些痛点，本文将探讨运维数据中台的探索与实践。
2 、背景
企业在数字化转型过程中， IT 架构越来越复杂（如主机、存储、网络、数据库、中间件、虚拟化、容器、众多的业务系统），要如何统一监控运维？海量的
IT 、业务数据该如何体现其价值？如何智能化运维、提升运维效率？
传统运维依赖人工操作，有时也被戏称为 “ 人肉运维 ” 。在传统运维人员减少的同时，我们管理的机器数量却翻倍了，这是我们面临的一个比较大的问题。网络拓扑日益复杂。微服务出现之后，网络拓扑关系更加复杂了，资源频繁的弹性伸缩，导致
CMDB 和其他应用信息无法做到实时管理。
运维专家资源匮乏。运维行业要求硬件、系统、网络、脚本语言、开发能力、应用运维等多领域的知识储备，一名优秀的运维专家需要长期运维工作经验的积累。另外，目前运维从业者减少也导致了运维专家尤其是有丰富经验的运维专家资源匮乏的现状。运维平台日趋复杂。很多公司发展到一定的规模之后，因为前期的发展规划不足，可能每个部门都有自己的运维或者监控平台，平台繁多就容易形成数据孤岛，这样就造成了研发人员在使用的时候非常不便。
以前大家可能面对的是一个应用只操作一个数据库这种传统的应用架构，而现在几乎所有的应用都已经加入了微服务架构的行列，应用之间的调用情况就变得很复杂，在定位系统问题的时候就非常被动，这也是我们面临的一个问题。
数据治理难。当数字化建设进行到一定程度的时候，被管理对象的数据量相应的也是水涨船高，数据数量大、类别多且非常分散，很难通过某一指标体系来衡量系统的健康度，也没有一个统一的视角去判断数据质量的好坏优劣。
3 、什么是运维数据中台
3.1 运维数据中台定位
1 、统一的运维数据平台，基础架构监控：提供丰富的基础架构（主机、网络、存储、虚拟化、数据库、中间件等）
, 环境探针和组件，统一运维数据采集 , 支持对接各种监控平台、外部数据源，统一数据存储 , 标准化数据管理、数据治理，统一数据标准
, 主数据管理。
2 、数字化运营，个性化的数据分析呈现能力 , 提供灵活自定义的指标和评分模型 , 提供丰富的 Dashboard
模板 , 支持高度自定义的可视化呈现能力。
3 、赋能智能运维，智能基线告警 , 智能告警收敛 , 智能故障预测 , 智能根因分析 , 科学性能管理、容量预测。
3.2 数据中台解决企业数字化转型运维痛点
1 、针对系统架构变化频繁，又要搭建新的监控平台我们可以采用一体化数据采集平台 + 可视化平台，放心引入服务组件；
2 、针对历史监控平台太多，多平台反复横跳，数据不统一 ; 原始数据无法直接衡量业务 &IT
服务的健康程度的问题我们可以统一运维数据中台，打破数据孤岛，打造统一、规范的指标体系；
3 、针对业务变动、举办活动、领导视察，又要采购新的大屏的问题我们可以高度定制可视化平台，快速打造酷炫大屏；
4 、针对告警来源不统一，告警风暴侵扰，故障定位困难的问题我们可以搭建智能告警平台，实现告警相关性分析，智能化告警、根因分析
& 故障定位；
5 、针对负载太重、资源空闲过多，容量和成本的平衡、供应与需求的平衡等问题我们可以实现科学性能管理、智能容量预测。
4 、如何建设运维数据中台
4.1 运维数据中台架构 
4.2 运维数据中台数据流程 
4.3 运维数据中台建设方法论
建设运维数据中台本质上是要减少数据的重复建设，提高数据的共享能力。所以建设运维数据中台需要运用 OneData
、 OneService 两个方法论。OneData 要求数据平台的所有数据只加工一次，对应到数据平台的设计层面，要求有统一的维度，对于明细层数据，相同粒度的度量只加工一次，对于汇总层的数据，相同粒度的指标只存在一份。OneService
是统一查询服务，原先数据开发和应用开发的边界是比较模糊的，哪些逻辑应该是由数据开发完成，哪些应该是由应用开发完成。数据服务划清了数据和应用的边界，数据服务提供的是加工好的指标数据，应用通过数据服务，直接获取计算的结果，强制把公共计算逻辑下沉到数据层面，提高了数据的共享能力。数据中台屏蔽了底层系统之间的差异，让运维人员可以将业务日常的运维工作交给产品、开发、测试等人员执行，实现业务发布、变更等日常工作的自助化，除此之外，为降低非运维人员的操作成本，提供了
“ 轻应用 ” 和 “ 职能化 ” 功能，提高自助率。
4.4 运维数据中台应用场景举例
4.4.1 根因定位
针对根因定位，可以分为以下主要几个步骤。
设置时间切片粒度： 实时获取时间切片内（ 1min 、 5min 等）的告警数据；
告警分类： 针对原始的告警数据，结合具体的告警信息和监控项等信息，根据训练好的分类模型对原始的告警数据从
HOST 、 VM 、 SOFTWARE 三个方面进行分类，例如：vm 网卡流量大、 host 磁盘使用率过高、
software_ 网页访问失败等。
根据 CMDB 配置关系建模
告警因果图构建： 基于告警收敛结果，在图数据库中按照系统级别查询每个系统下的所有节点之间的连接子图，并将得到的结果输入到
networkx 中，得到某个系统下的各节点之间的最终连接关系，即告警因果图。
根因路径： 基于上述生成的告警因果图，以及权重来计算疑似路径，排序给出根因路径。
对于上述第一个时间切片中的某个系统，在图数据库中查询该系统下的所有节点构成的子图，以 “ 某银行
XX 系统 ” 这个系统为例，查询得到在 “ 一跳 ” 范围内与该系统下的所有节点之间有关联的节点的关系大致如下（红色表示
物理机 节点，棕色表示 虚拟机 节点，绿色表示 软件 节点）：
上图中出现的所有节点中，既包括有告警信息的，也包括没有告警消息的，因此将上述因果图输入到 netwokx
后，可以得到最终经过精简后的有告警消息发出的各节点的因果图， 其中一部分的因果图展示如下：
可以解释为 : “192.168.xxx.xxx-host- 服务器宕机 ” 导致 “10.104.xxx.xxx-vm-
服务器宕机 ” ，进而导致 “software- 网页访问失败 ” 。
进一步的，根据上述生成的因果图，再结合因果图中每条边的权重，就可以计算出该时间切片下的单个系统层面上的所有疑似根因路径，经过排序后即可得到最终的根因路径。本例中最终得到的几条根因路径如下：
从上图可以看出，程序最终给出了几条疑似的根因路径，其中包括最长的一条，可以解释为：ip**为 192.168.xxx.xxx
这台物理机 由于网卡 overruns 的原因，导致了这台物理机的宕机，从而使得这台物理机上的 ip
为 10.104.xxx.xxx 的虚拟机宕机，最终导致这台虚拟机上的相关的网页访问失败。
4.4.2 容量预测
容量管理服务覆盖 IT 系统的整个生命周期，通过调用中台服务对业务容量数据（包括用户数量、交易与交易量、业务模型、业务复杂度等）、服务容量数据（服务水平等级、
TPS 、并发用户数、连接数、系统响应时间）和 IT 基础架构组件容量数据（服务器（ CPU 、内存、
IO 等）、存储（磁盘空间、 Cache 等）、网络（带宽、端口流量等）、数据库、中间件）的分析，建立科学的容量模型，实现对容量指标的分析和预测，及时发现容量瓶颈、资源配置不均衡等问题，在确保业务系统的稳定运行的同时，节约
IT 基础设施的成本，为客户提供科学有效的 IT 采购与扩容提供科学依据，为 IT 资源更合理分配提供决策支持，实现两个平衡：容量和成本的平衡、供应与需求的平衡。
5 、运维数据中台建设难点
运维数据中台的方法论包括 One Service 和 One Data ，而 One Data 的难点和重点就是运维数据的治理，数据治理是一个长期过程，在运维数据体系建设过程中要有一个持续演进的运维数据治理步骤。
第一阶段：摸家底，落地数据资产。基于要实现运维数字化场景，梳理运维数据分析涉及监控、日志、性能、配置、流程、应用运行
6 类数据存储在哪里，工具或平台架构、数据结构，数据实时性，数据完整性，数据正确性，数据标准化程度等方案。
第二阶段：建标准，提供一站式的管控能力。结合第一阶段的成果，建立数据管控的流程、机制、标准、安全体系能力，建立一站式的运维数据平台，从运维数据应用场景角度梳理企业数据质量问题，建立数据运营职能岗位、制定数据标准及配套的流程。基于运维数据标准，结合运维数据项目推动运维数据治理模块的建设，比如：以运维指标体系场景驱动落地数据资产管理模块
/ 系统，以 CMDB 配置数据为基础落地主数据库。
第三阶段：促消费，以数据消费反向提升数据治理能力。首先，提供自助式服务能力，以用户为中心，加强运维数据运营效能，为用户提供直接获取数据的能力，直接为用户提供价值，向用户提供数据服务化能力，使用户能够自助的获取和使用数据。其次，提供人机协同应用能力，将数据沉淀为知识，形成运维知识图谱，结合
AIOps 理念将机器优势与运维专家经验相结合，形成数据洞察 / 预测、决策 / 自动化、执行 /
任务的闭环。利用丰富的数据消费场景如监控告警、自动化运维等反向发现数据质量问题，来持续提升数据治理水平。
数据领域的数据治理主要包括元数据、主数据、数据标准、数据质量、数据模型、数据安全、数据生命周期 7
部分内容，以下结合运维领域特点，谈一下我对运维数据治理的内容。
1、元数据管理
元数据 ：元数据是指描述数据的数据，是指从信息资源中抽取出来说明数据特征、内容的结构化的数据，用于组织、描述、检索、保存、管理。
2、主数据管理
主数据管理是指一整套用于生成和维护主数据的规范、技术和方案，以保证主数据的完整性、一致性和准确性。主数据与交易数据不同，主数据的内容具有稳定、可共享、权威几个特征。运维主数据的主要数据：
与机器相关的 ：动环、网络、服务器、存储、光纤交换机等。
与软件相关的 ：系统软件、数据库、中间件、应用系统、 DNS 等。
与流程相关的 ：与 ITIL 相关的事件、问题、变更、配置等。
3、数据标准管理
数据标准通常包括组织架构、标准制度、管控流程、技术体系四个方向，应用统一的数据定义、数据分类、编码规范，以及数据字典等。在运维领域数据标准可以考虑如下：
组织架构： 确定运维元数据、主数据、交易数据涉及的管理决策、数据业主、运营、质量、消费等团队或岗位角色。
标准制度： 围绕源端数据制定分类、格式、编码等规范，制定日志、报警、性能指标等数据标准。
管控流程： 要对运维数据管理的供应、变更、申请、共享、质量、运营等流程进行规范化、线上化、流程化、表单化。
技术体系： 综合考虑平台架构、接口规范、应用场景等，围绕运维数据的 “ 采存算管用 ” 建立运维数据平台。
4、数据质量管理
数据质量管理是指针对数据从获取、存储、共享、维护、应用、消亡全生命周期的每个阶段里可能引发的数据质量问题，进行识别、度量、监控、预警等管理活动，并通过改善和提高组织的管理水平提高数据质量。运维数据有如下特点：海量的非结构化数据、秒级以内的实时数据、源端数据标准化程度低、应用场景对实时性要求高。所以运维数据质量管理应该在有限资源的背景下聚焦实时、在线、准确、完整、有效、规范等关键字。
5、数据模型管理
运维数据的模型管理方面，一是要借鉴传统业务大数据的指标数据模型设计方法；二要结合运维数据消费场景实时、准确等特征，利用流式计算方式区分源端原始数据，旁路后的加工数据，根据规则生成的指标数据等方式，设计运维实时数据模型。
6、数据安全管理
数据安全管理是实现数据安全策略和流程的制订，数据安全管理需要遵循国家、行业的安全政策法规，比如 网络安全
法，等级保护，个人隐私安全等要求。另外，数据治理将依赖数据来源、内容、用途进行分类，所以数据安全管理还要求对数据内容敏感程度、影响等进行分级分类。运维数据都是生产数据，生产数据的安全管理，要从技术、管理两个角度对产生、运营、消费进行全流程的安全管理。
7、数据生命周期管理
数据生命周期通常是指数据从产生、采集、存储、整合、分析、消费 / 应用、归档、销毁等过程的数据管理。数据价值决定着数据全生命周期过程的管理方式，数据价值可能会随着时间的变化而递减，影响着采集粒度、时效性、存储方式、分析应用、场景消费等。对运维数据生命周期各个阶段的特点采取不同的管理方法和控制手段，能从数据中挖掘出更多有效的数据价值。
6 、运维数据中台的发展方向
运维数据中台的发展方向可以从以下两个方面考虑：
1、云上数据中台，实现应用微服务化、容器化。应用可以基于容器镜像构建、运行， 实现容器编排、 上线和扩容快、秒级伸缩，同时也提升资源使用率和业务交互的性能
2、构建运维 AI 中台， AI 中台是运维数据中台的未来发展的趋势，随着业务技术的发展，数据中台会向着
AI 中台演进，它围绕智能化服务为核心，它依赖于数据中台提供给它数据服务的能力，而智能化的技术开发能力，又能够提供给数据更便捷和快速的的数据分析和预测，从而提供了更好的数据服务。因此它们之间又是相互依存、共同提升。AI
中台的构建贯穿数据体系的各个方面，并不是在数据中台的基础上加上智能化处理就行。AI 中台尝试解决如下的问题：
拆分服务构建环节，智能服务开发流程化，快速响应业务需求
利用元数据管理方式，提供统一的标准格式，场景可以多人协同配合开发
基础设施共享化，模型的训练和发布与数据平台有效绑定，服务的构建自动化
通用 AI 能力平台化，降低人员要求，提升协作效率
|
