写点什么

对话柯旻:中小企业不适合实践 AIOps,更应该上云

  • 2020-02-18
  • 本文字数:3410 字

    阅读完需:约 11 分钟

对话柯旻:中小企业不适合实践AIOps,更应该上云

2016 年,Gartner 提出了利用 AI 技术的新一代 IT 运维,即 AIOps(智能运维),来解决未来企业可能遭遇的因 IT 故障而导致的业务中断。随后,AIOps 的概念得到了广泛普及和发展,有人把 2018 年称为 AIOps 的落地元年,把 2019 年称为 AIOps 快速发展的一年,那么,实际情况到底如何呢?InfoQ 准备了 7 个 AIOps 领域的“尖锐问题”,并采访了2020年QCon全球软件开发大会(北京站)AIOps专场的出品人柯旻。


根据 Gartner 预测,到 2022 年,40%的大中型企业将部署 AIOps 平台。那么,企业实践 AIOps 需要哪些前提条件呢?完整的 AIOps 实践需要具备哪些能力?企业转型为 AIOps,运维人员的工作需要做哪些转变?当前,国内 AIOps 实践到底进行到哪个阶段了?…以上这些大家关心的问题,柯旻都为我们做了解答。

自动化运维是 AIOps 的前提条件吗?

AIOps 的实践不是一蹴而就的,而是逐步发展的。在发展过程中,有人会质疑某些 AIOps 实践是伪 AIOps,质疑某些 AIOps 实践是传统运维+自动化策略…那么,AIOps 与其它运维方法的差异体现在哪里?实现 AIOps 的前提条件是什么?哪些企业适合实践 AIOps?


Q:传统运维、自动化运维和 AIOps 之间的差异具体体现在哪里?


柯旻:如果要说传统运维、自动化运维和 AIOps 之间有哪些具体的差异,我认为主要是体现在机器资源的规模越来越庞大,以及业务组件越来越复杂复杂,带来的运维领域对数据化,智能化的越来越高的要求。


随着公司业务的发展,底层资源也会逐步跟随业务发展快速增长,同时由于体量发生巨大的变化,引发底层技术发生变革(例如分布式技术,存储计算分离等),整体的复杂性发生了质的变化,同时用户不再只是使用单产品,而是整个平台层面、多产品的整体使用,所以运维复杂度也会呈几何式增长。随着这些变化,如果完全靠人力已经无法有效支撑(稳定性,效率,成本,安全)其业务发展了。所以对数据化,智能化的需求会越来越迫切。



Q:自动化运维是实现 AIOps 的前提条件吗?


柯旻:从我个人的角度来看,自动化运维是实现 AIOps 的前提条件。


AIOps 本质上是通过机器学习算法以及相关的大数据技术能智能 &自动的解决日常运维方面的问题,这就涉及到对数据收集、传输、处理、在线/离线计算、AI 算法平台、工作流执行…等一系列的底层平台的功能依赖支持。所以 AIOps 一定是建立在一个比较高度完善的运维自动化基础上的,这样才能建立一整套底层数据处理平台,这其中会涉及从业务需求—算法实验—数据采集—提取 &清理—算法接口—达标反馈等一套平台以及流程落地,深度集成基础运维和数据运维服务以及核心的运维管控,以数据,算法驱动全链路适配不同运维场景。



Q:实现 AIOps 需要哪些前提条件?中小型企业是否适合实践 AIOps?


柯旻:想要实现 AIOps 涉及的相关还是比较多的, 比较常见的技术包括大数据平台相关技术、算法、机器学习、场景感知、自动化平台的完善等,当然最主要的还是上层组织认可后在资源上有一定保障的持续投入。


中小型企业是否适合实践 AIOps 呢?在我看来,目前来说是不适合直接实践 AIOps。相比来说,上云比实践 AIOps 更重要一些。因为 AIops 需要的相关底层的技术能力在云上都有一定的产品支持(云厂商已经把相关技术产品化掉),对于中小企业来说,上云后不需要太多底层技术资源上的投入,而可以直接使用云上产品来做相关的智能化数据分析,同时减少了一些 IAAS,PAAS 层的要求(例如虚拟资源动态切换这个一般云厂家都会提供相关功能,而我们只需要使用他们的能力),专注解决业务运维相关的运维问题,从而简化前期投入以及避免技术投资浪费(前期投入过多的底层技术资源,随着上云后这些技术投入很多将失去意义)。

完整的 AIOps 实践应具备哪些技术能力?

为什么企业会选择从传统运维转型到 AIOps 呢?在柯旻看来,做出这种转变的主要动因还是业务发展带来的底层资源规模的变化以及企业业务复杂度的变化。那么,一个较为完整的 AIOps 实践应该具备哪些技术能力呢?如果转型为 AIOps,运维人员的工作内容会有哪些变化呢?


Q:一个较为完整的 AIOps 实践应该具备哪些技术能力?


柯旻:抛开底层的自动化平台层面和数据收集处理的大数据平台方面的技术能力之外,AIOps 的核心主要集中在数据算法、机器学习技术方面。所以一个完整的 AIOps 实践需要多团队 &技能协同,例如 AI 算法专家需要对比方、层次聚类、随机森林、时序数据分解、DNN、RNN 等算法方面的技能,运维平台研发专家需要负责整个运维产品的开发,数据分析决策后如何闭环执行,具备工程研发以及产品化能力,同时 SRE 还需要了解架构规划、数据分析运营等相关多维度能力要求。一个完整的 AIops team 会是需要一个多方面综合技术能力的集中。


Q:如果企业向 AIOps 转型,那么运维人员的工作会发生哪些变化?


柯旻:说实话,企业转型 AIOps,对传统运维人员带来的冲击会非常大。比较突出的变化是,以前变更管控、配置管理、环境部署、日常操作、性能分析、故障定位等工作可能都会被智能分析、故障预警、运营分析、运维数据挖掘等取代。从核心上来说,越来越多的决策会交给机器算法来判断,机器会把绝大部分工作都做了,包括异常检测,根因分析/定位、异常预测等。不过,这个变化也不是突然发生的,而是慢慢逐步变化的。如果举个例子的话,就类似于现在的自动驾驶,不是一蹴而就直接到最终局。运维人员自身需要做的改变是,把自己脑中的经验能力抽象成自动化产品运维能力,把日常经验沉淀为平台数据积累,业务场景问题的提炼总结,升级自己的研发技能,和算法工程师一起帮助机器决策变得越来越准确。

当前 AIOps 实践的现状

有人说:“2018 年是 AIOps 落地的元年,2019 年是 AIOps 快速发展的一年。”确实,现在讨论 AIOps 概念的少了,讨论实践案例的反而多了。那么,在实际应用中,AIOps 有哪些最佳实践,目前 AIOps 的应用情况到底如何?


Q:AIOps 有哪些比较好的应用?如何看待国内目前 AIOps 的应用情况?


柯旻: 坦率来讲,目前我在 AIOps 领域还没看到太成熟的应用,在某些单维度、周期性的场景下可能有一定的效果,但在多维度海量数据场景下效果不是很理想,特别是在异常检测,根因分析、智能预测等场景中。主要原因可能是在这种场景下,有各类异常数据打标,产品一个版本发布变更之后可能会发生巨变,算法参数就失效了,导致出现大量的误报等。同时涉及的相关维度也比较多,例如可能用户只是个访问失败,涉及的链路有业务逻辑代码、分布式存储、缓存系统、数据库、CDN、网络、OS、硬件等各个环节。而很多时候大家都希望能有一个直接标准的机器学习算法一步到位来解决异常检测所有问题。但这种做法通常不太现实最后会走到死胡同,因为这整个问题已经复杂到 AI 算法不擅长的程度。所以这块从方式以及时间上这块还需持续投入。


从国内情况来看,我个人看到的目前几家头部企业在 AIOps 领域都在做一些持续尝试,因为业务场景已经倒逼相关公司运维团队必须要通过这样方式提升整体运维能力去解决稳定性、成本、效率等问题。(目前我们已经在日志聚类,异常检测-周期性检测,黄金指标分析,根因分析等场景上有了一定的落地)而其它企业的更多是在理论或观望阶段,又或是在某些地方做小的尝试,这些企业的特征是主要业务体量并没有那么紧迫的压力,而且需要有一定的技术积累持续投入。


Q:如何看待 AIOps 的发展趋势?


柯旻:我对 AIOps 的发展趋势还是持很乐观的态度,因为目前对于云计算整个业内大家都已经是一个比较清晰的共识,而随着企业逐渐上云之后,很多底层技术门槛都会逐步降低,例如大数据技术、算法能力、自动化运维能力…等等都会被产品化使用,使得大家可以更聚焦业务场景运维数据的智能化处理场景投入,解决实际的业务运维问题,继而提高整个运维领域的生产力。


最后附上我们内部对比 Tesla 的自动驾驶和 AIops 对比的一个情况。困难是未知的,目标是明确的。



采访嘉宾:


柯旻(大舞)大数据资深技术专家,阿里巴巴计算平台事业部基础工程技术负责人。从 2007 年加入中国雅虎后合并到阿里集团,历经 IDC,系统工程,CDN,云计算,大数据,等不同领域。目前负责整个阿里集团大规模离线计算,流计算,批处理,实时交互式分析型,AI 算法等大数据平台的公有云,专有云以及内部业务的运维以及运维产品开发,体系建设,架构规划,对外输出等方面工作。


更多 AIOps 落地实践请关注 QCon北京2020,大会邀请多位技术大咖与你一起探讨智能化运维新技术,帮你提升整体运维能力和效率,点击了解详情


2020-02-18 10:266958
用户头像

发布了 497 篇内容, 共 320.6 次阅读, 收获喜欢 1918 次。

关注

评论

发布
暂无评论
发现更多内容

TiDB Binlog 支持 Oracle 目标库功能用户手册

TiDB 社区干货传送门

迁移

探索TiDB Lightning源码来解决发现的bug

TiDB 社区干货传送门

TiDB 底层架构

JOIN 查询的执行计划 比较

TiDB 社区干货传送门

性能调优 TiDB 底层架构

TiDB 元信息管理方式

TiDB 社区干货传送门

TiDB 底层架构

记一次TiDB的临时救场

TiDB 社区干货传送门

实践案例

TiDB 在 Cisco Webex 架构中的部署和应用

TiDB 社区干货传送门

TiDB 悲观事务模式和Mysql的表象区别

TiDB 社区干货传送门

TiDB学习之路

TiDB 社区干货传送门

实践案例

TiDB监控Prometheus磁盘内存问题

TiDB 社区干货传送门

故障排查/诊断

TiSpark数据写入过程解析(源码解析)

TiDB 社区干货传送门

TiDB 底层架构

TiSpark On Kubernetes实践

TiDB 社区干货传送门

实践案例

TiDB 运维基础操作脑图

TiDB 社区干货传送门

DR Auto-Sync 搭建和计划内切换操作手册

TiDB 社区干货传送门

TiDB体系结构

TiDB 社区干货传送门

TiDB 底层架构

一言难尽的Prometheus监控实践

TiDB 社区干货传送门

实践案例

在CentOS7上进行TiDB/PD/TIKV编译分享

TiDB 社区干货传送门

实践案例 安装 & 部署

前缀索引在特殊场景下的优化尝试

TiDB 社区干货传送门

实践案例 TiDB 底层架构

高并发请求下 TiDB 集群的业务无损升级

TiDB 社区干货传送门

TiDB 如何获取集群创建时间

TiDB 社区干货传送门

实践案例 TiDB 底层架构

大事务的处理方式对比

TiDB 社区干货传送门

实践案例

使用 TiUP 安装部署 TiDB 集群实验流程

TiDB 社区干货传送门

版本升级 集群管理 管理与运维 安装 & 部署 扩/缩容

TiDB 如何在 LVS FULL NAT 模式下显示客户端真实 IP

TiDB 社区干货传送门

实践案例

传统行业数据架构发展变化

TiDB 社区干货传送门

数据库架构选型

TiDB BR 备份至 MinIO S3 实战

TiDB 社区干货传送门

管理与运维

记一次简单的Oracle离线数据迁移至TiDB过程

TiDB 社区干货传送门

dm-V1.0.5使用汇总

TiDB 社区干货传送门

管理与运维

骏彩竞猜分布式解决方案之路

TiDB 社区干货传送门

安装 & 部署

【考试指南】TiDB 5.0认证指南之PCTA PCTP

TiDB 社区干货传送门

TiDB 底层架构

TiDB在个推的落地实践 | 解决热点难题,提升性能超千倍

TiDB 社区干货传送门

性能调优

TiCDC 4.0.15 初体验

TiDB 社区干货传送门

实践案例

使用SPM固定执行计划

TiDB 社区干货传送门

对话柯旻:中小企业不适合实践AIOps,更应该上云_服务革新_田晓旭_InfoQ精选文章