智能运维系列之四：智能运维落地的思路

开发智能运维，团队需要的能力结构

业务能力

概述

• 智能运维，是建立在现有运维业务和技术体系之上的；

• 智能运维的落地和发展，需要跟业务产生良好的互动，取得他们的支持：

• 智能运维所需要的业务经验，是来源于业务方的；

• 智能运维产品，最终也是业务方在使用的；

因此，掌握运维业务以及运维技术体系，对于后续寻找方向、以及跟业务沟通，都有很大的帮助。

能力结构

• 对运维业务相关的方法论，有较深入的理解；

• 对运维技术体系，有较深入的理解；

详见：https://blog.csdn.net/micklongen/article/details/117136344?spm=1001.2014.3001.5501

产品能力

概述

产品是沟通技术和业务的桥梁，同时也是智能运维落地的载体。

算法工程师，训练出了算法模型。但是，业务需要的不是算法模型，而是一个产品。

以我的经验，大部分业务对数据工程、机器学习、知识图谱等毫无概念。好的产品迭代思路，应该是能够让 研发和业务 一起成长：

• 研发人员，在产品的迭代过程中，不断深入的了解业务，从而设计出更好的产品和技术架构；

• 业务人员，在产品的迭代过程中，对如何使用数据和算法，能够有从浅到深的理解；

能力结构（不擅长）

• 对监控相关的产品有较为深入的了解；

• 对运维相关的产品有较为深入的了解；

• 对数据产品有较为深入的了解；

• 对 AI 产品有较为深入的了解；

数据能力

概述

简单来讲，就是数据仓库。以及建设数据仓库相关的能力。

数据仓库的方法论包括（来源于阿里，详见：https://blog.csdn.net/micklongen/category_9876625.html?spm=1001.2014.3001.5482）：

• OneData 体系方法论

• OneEntity 体系方法论

• OneService 体系方法论

为什么需要建数仓

业务对数据的使用场景，包括：

• 质量保障

• 监控；

• 排障

• 故障复盘

• 成本优化

• 空闲机器回收；

• 成本核算（个人、部门、项目粒度等）；

• 用户体验评估

• 用户使用公司产品的体验评估；

• 服务质量评估（SLA 体系）

• 性能分析

• 等等

运维的数据来源多种多样，有运维本身的数据，也有业务部门给出来的数据；

能力结构

• 大数据相关技术栈，包括但不限于 Spark、Flink 等；

• 数据仓库建设能力；

• 大数据可视化；

工程能力

概述

智能运维，本质上是一个非常复杂和庞大的分布式系统。完整的智能运维解决方案包括，但是不限于：

• 数据工程

• ETL 平台；

• 大数据存储；

• 数据可视化；

• 业务系统

• 常规的运维工具

• 监控系统

• 故障管理平台

• CMDB

• 各种运维自动化平台

• 等等

• 算法对外的服务（每个服务都是基于分布式架构设计的，包括样本管理、算法建模、算法评估，算法模型工程化等）

• 时序指标服务

• 日志文本挖掘服务

• 根因分析服务

• 故障影响评估服务

• 故障预案平台

• 等等

能力结构

• 分布式系统架构能力；

• 了解监控系统的相关架构；

• 了解运维相关的技术体系；

算法能力

概述

算法，是智能运维无法回避的一个话题。

能力结构

• 计算机科学相关的基础算法：比如说 搜索算法、树、图论、动态规划等；

• 统计学相关基础知识；

• 时序算法

• NLP

• 数据挖掘、神经网络

• 知识图谱

• 本体论

• 知识图谱相关的开源工具

• 如果后续要自己开发相关的工具，还需要具备：

• 编译原理，用于设计和开发推理引擎；

• 推理逻辑

• 数据库相关的理论，分布式系统算法相关的理论，用于开发分布式数据库；

• 运筹学，规划类的问题

智能运维如何落地

寻找切入点

做前沿项目，还是比较忌讳一开始贪大求全。这不仅仅是技术问题。

项目刚开始的项目，还是有很多东西需要处理的：

• 熟悉业务的过程；

• 跟业务方的磨合；

• 技术的尝试阶段；

• 等等；

以根因分析作为切入点为例

根因分析技术简介

具体详见：https://blog.csdn.net/micklongen/article/details/89437275

• 分析意图

• 根因分析，需要给出解释的：逻辑推理、状态图、贝叶斯网络等；

• 只需要给出结论：机器学习、频繁项挖掘等；

• 场景划分

• 实时分析：1 分钟之内

• 准实时分析：5 分钟之内

• 离线分析：5 分钟之后

如何落地

数据问题

做算法，最大的问题，是大量的高质量数据。

• 如果有海量的数据，直接采用贝叶斯网络；

• 如果没有数据，一般可以采用专家系统，再深入一点，则是知识图谱。

落地步骤（假设监控系统、和告警都有了）

• 需要一个故障管理平台，能够做故障跟踪；

• 实体之间的关联图，如何组织这些依赖关系，本身就是一个很大的挑战。包括但不限于：

• 物理资源的关联关系

• 硬件之间的关联关系，比如说 机房-交换机-机柜-服务器等；

• 服务和服务器之间的关联图；

• 服务和数据库/消息队列之间的关联关系；

• 服务之间的依赖关系；

• 业务逻辑之间的关联关系，或者说数据之间的依赖关系

如何延伸和扩展

数据方向

• 基于以上的场景，可以开始考虑落地运维数据仓库。但是落地数据仓库不能只考虑智能运维的需求，还需要综合考虑整个运维部门的需求，否则就有点小题大做了；

• 基于数仓，可以延伸出大数据展示，可以参见 阿里云的 QuickBI；

工程方向

基于关联图的发展方向：

• 尝试针对某一个点，做深入分析，比如说 ECS 故障等；

• 在有了一定的故障数据的基础后，开始考虑如果做故障关联分析；

• 开始落地一些通用的基础设施；

如何体系化的建设智能运维

数据体系化建设 — 运维数仓

基础能力建设

• 数据采集

• 数据清洗

• 数仓建设

• 大数据可视化

• 数据分析

应用

• 质量保障

• SLA 指标体系

• 故障影响评估

• 安全生产数据支持

• 可用率分析

• 成本管理

• 资源使用率

• 效率

• 性能分析

• 用户体验

• 等等

工程体系化建设 — 业务系统

基础能力建设

• 分布式系统架构能力建设

• 运维能力建设

• 算法模型工程化

应用场景

• 支撑智能运维解决方案落地

算法体系化建设

基础能力建设

见上面

应用场景

• 质量保障

• 成本优化

• 效率提升

• 用户体验分析与提升

• 等等