前言从事运维工作整整八年,刚入行那几年,7×24 小时待命是刻在骨子里的工作常态。凌晨两点接到服务器告警、节假日突发数据库宕机、业务高峰期网络链路拥塞,是每个传统运维都经历过的日常。 一、先认清:传统运维与 AIOps 智能运维核心差异在梳理技能清单之前,必须清晰区分两种运维模式的底层逻辑,才能明白为什么旧技能不再适配当下行业需求。 1.1 传统运维工作模式痛点传统运维属于被动式运维,核心流程全靠人工驱动,整体流程如下流程图所示:从流程图能直观看到传统运维的核心短板:告警滞后:必须等故障发生后才推送提醒,无法提前预判潜在风险;人力成本高 模块二:AIOps 智能监控与异常检测能力传统运维只会配置固定阈值监控,比如 CPU 超过 80% 告警、内存超过 90% 推送提醒,固定阈值在业务流量波动场景下完全失效。 如今 AI、AIOps 全面普及,传统人工运维模式逐步退出主流业务场景,与其被动等待行业淘汰,不如主动掌握新一代运维核心技能。
AIOps 这个词这两年很热,但很多人对它的理解还停留在"运维 + AI"的字面拼接。这个理解不算错,但不够。 要说清楚 AIOps 是什么,最直接的办法是看它和传统运维监控的差异——同样是为了"让系统跑得稳",思路其实差得很远。 传统运维监控:你定规则,系统执行传统监控的工作方式很清晰:你设定指标阈值——CPU > 80% 告警、磁盘 > 90% 告警你写好告警规则——连续 5 分钟超过就触发你配好通知策略——告警发到哪个群、谁来值班你维护好处理预案 AIOps 真正补位的,是那些规则写不全、阈值定不准、根因找不到的场景。一个成熟的运维体系,通常是两者结合:传统监控守住基础阈值,AIOps 处理复杂场景下的异常发现和定位。 AIOps 的价值不在于"听起来很 AI",而在于让工程师从"被告警追着跑"变成"被预警提前提醒"。这个差别,做过一线运维的人都懂。
AIOps行业演进全景:传统人工运维向智能运维转型发展路径 在数字化深度落地的当下,企业IT架构从单一机房架构演进为云原生、微服务、分布式混合架构,业务系统复杂度呈指数级增长。 传统人工运维模式效率低下、容错率低、响应滞后的短板彻底凸显,AIOps智能运维成为运维行业转型升级的核心方向,实现运维从“被动救火”向“主动预判、智能自治”的跨越式变革。 一、行业迭代:传统运维的痛点与瓶颈 传统运维以人工操作为核心,依托运维人员经验完成设备巡检、故障排查、日志分析、告警处理等工作,适配早期单体架构、低并发、少节点的IT场景。 二、AIOps智能运维核心架构与技术逻辑 AIOps即人工智能运维,依托大数据、机器学习、算法模型,对运维全量数据进行采集、分析、研判、处置,构建数据驱动、智能自治的运维体系。 整体而言,人工运维向AIOps智能运维转型,不是简单的工具替换,而是运维思维、体系、模式的全方位革新。
0x01 AIOps 背景 1.1 AIOps概述 智能运维的理想状态就是把运维工作的三大部分:监控、管理和故障定位,利用一些机器学习算法的方法把它们有机结合起来。 AIOps平台主要通过整合分析IT基础设施、APM、NPM、日志、数字化体验监测数据,来提升IT运维流程的效率。 2.6.3 微众银行知识图谱 传统根因推导过程是运维工程师通过对软件架构和调用关系的理解将异常发生时的告警、日志等信息联系在一起,应用运维知识经验来排查推导异常根因,相当于在大脑中存储和训练了一个知识图谱 (AIOps)中几处问题的解决方案与思路 AIOps智能运维之三:无监督异常检测 技术干货 | 日志易产品总监饶琛琳:数据驱动的智能运维平台 从人肉到智能,阿里运维体系经历了哪些变迁? 根因分析初探:一种报警聚类算法在业务系统的落地实施 京东物流基于开源APM的智能运维体系建设与落地 百度 AIOps 实践中的四大金刚
我整理了传统运维和智能运维在6个核心维度的对比,让你看清楚这个差距到底有多大。维度一:如何发现问题传统运维:靠监控告警被动通知。 维度三:如何传承知识传统运维:知识在人头上。老员工知道哪些坑,新员工需要几个月才能上手运维手册写了但没人看,更没人更新核心人员离职=运维能力断崖式下降智能运维:知识在系统里。 维度四:如何管理多云传统运维:三个云=三份工作。每个云一套控制台,各自登录各自的告警系统,各自的账单,各自的权限管理汇总多云数据需要人工整理,每周半天不止智能运维(CloudQ):一个入口,统一视图。 发现问题后,截图发给同事,解释背景每周手写巡检报告,耗时2-3小时问题跟进靠人肉followup智能运维(CloudQ):报告自动生成,协作在IM里发生。 总结传统运维和智能运维的差距,不只是工具的差距,是工作方式的差距:从被动响应到主动预防从个人经验到系统知识从多地登录到统一视图从手工报告到自动化推送腾讯云CloudQ(JustQIT!)
一、AI为什么对IT运维重要? 传统运维存在几个痛点:传统运维痛点AI带来的改变告警量大、难筛选根因AI可识别告警关联性并自动根因定位故障靠人工排查,耗时长模型可溯源日志、抓异常趋势并提前预警运维经验靠个人积累,不可复制AI沉淀规则→ 价值:✔避免数据库节点宕机✔保障核心账单业务不出现停机✔形成长期健康评分体系案例3:AI自动化运维闭环–服务异常自动恢复目标异常发生后不依赖人工处理,形成无人值守自动修复系统。 5分钟夜间运维人力成本>2人值守可降40–70%SLA可用性提升99.80%→99.95%⭐这个是最常落地的能力→成本降低最明显。 写在最后AI赋能运维不是概念,而是已能实打实落地的生产力工具。一句总结:AIOps=经验沉淀+自动分析+主动预测+自动修复,最终目标是无人值守与业务持续可用。
随着智能化技术的发展,为了解决上述运维领域的问题,智能运维的呼声越来越高。 2、移动端和微服务给运维工作带来的挑战 在 PC 端的时代,运维的很多工作受限于浏览器,在运维人员拿不到用户端真实数据的情况下,大家普遍会去采购一些第三方服务,尝试获取终端数据。 3、在大数据时代, 智能运维与数据、自动化运维之间的关系 智能运维的理想状态就是把运维工作的三大部分(监控、管理和故障定位),利用一些机器学习的方法有机结合起来。 目前能够把这三部分融合起来的办法就是利用人工智能的手段,最后达到一种智能运维的状态。 4、智能运维当下的状况及智能运维发展的预测 智能运维当下还是一个初步探索的阶段。 传统的 IT 运维需要管理大量的告警,极大地分散了企业的注意力,消耗运维人员大量的时间和创新力。
到2022年,40% 的大型企业会通过大数据和机器学习的能力来帮助甚至逐渐取代传统运维中的监控、服务台及自动化流程。 AIOps重新定义了IT运维的管理方式,为IT运维团队适时提供适当信息,以便实现以下几点。 ,推送给运维人员,做到精细化告警,避免传统监控工具因一故障而导致的告警风暴,生产告警噪音。 AIOps与现有ITOM平台的关系具体如何呢?传统IT运维管理平台,即 ITOM 平台,往往是为完成单一管理任务而设计的,更偏向于管理某一细分专业领域。 规模不断扩大的 IT 系统、日益复杂的系统架构,以及海量的 IT 运维数据对使用传统ITOM的运维人员而言都如芒在背。
而作为救火队员的运维在产品业务建设初期参与架构规划也是减少后期运维灾难的重要手段。 智能化 运维本来就是在解决各种场景下的问题,智能化技术是一些新手段帮助运维解决过去解决不了的问题,我认为能利用好这个技术手段解决问题的就算是智能运维了。 AIOps 并非万能,但它的的确确能让运维彻底脱离重复低效的手工作坊式的工作。从运维升级成技术运营,因此焕发第二春。 腾讯在智能运维应用上有哪些套路和高招? 作为一名伴随腾讯十年的运维老兵,腾讯运维总监聂鑫有话对你说... 个人简介: 从开发到运维,伴随腾讯社交网络运营部成长的十年,负责过腾讯社交产品所有业务运维工作。 作为运维界老兵有好多故事想和大家讲,也特别愿意听听各位经历的酸甜苦辣。 2018年5月26日,高效运维 AIOps 北京沙龙,腾讯运维总监聂鑫老师将来到现场,并分享腾讯在智能运维领域的实践经验。
图片来自网络 在传统的运维里面问题发现可能是系统,但是最终的问题分析定义,问题决策和问题解决则是需要人工进行处理。 对于运维自动化,传统我们可能是编写自动化的运维脚本,然后是手工或定时的执行运维脚本完成整个自动化执行过程和运维例行检查。 优维自动化运维平台解决方案不同于传统的单一业务自动化解决方案,是真正面向企业运维部门提供平台+场景能力的解决方案。 智能运维在前期历史知识库不足够强大的情况下,你出现决策错误不要紧,但是你需要具备不断持续学习能力,自我适应和调整能力,这才是最重要的。 智能运维场景2-性能优化和弹性扩容 ? 智能运维在传统软件运维监控的基础上,能够进一步做到出现问题也能够被自动修复和解决,而不需要人工干预。
本期沙龙围绕运维展开了一场技术盛宴,从AIOps、Serverless DevOps、蓝鲸PaaS平台、K8S等分享关于业务运维的技术实践干货,同时带来腾讯海量业务自研上云实践,推动传统运维向云运维转型 整个智能运维分为好几个阶段,第一个是我们刚刚开始机器学习的能力,而刚刚开始应用到你逐渐能够成熟落地其实这个是有很长的时间段的,通常来说是1-2年甚至是更长的时间。 然后很多人在上面开发各种各样的工具,再将公共的能力,或者说是通用的能力给它抽建出来,抽建出来就可以逐渐搭建我们AIOPS的算法工具。这个就是工具开发和运维开发的东西。 而在整个AIOPS这一块,我们也和很多同行讨论过,在这个角色划分这一块,运维团队其实是一个比较复杂的团队,只有运维是不太够的,运维主要是了解业务场景的诉求,包括他想知道当前的业务出现了什么情况,他该如何处理这个故障 在这个AIOPS过程中这一块是非常重要的,缺了它就很难做成,所以运维工程师、开发工程师和机器学习的工程师是互联辅助、互联扶持的关系。 幻灯片8.PNG 下面我们来说一下单维时间序列分析。
文章目录 ConfigCommand 1 查询配置 Topic配置查询 其他配置/clients/users/brokers/broker-loggers 的查询 查询kafka版本信息 2 增删改 默认配置 附件 More 日常运维 、问题排查 怎么能够少了滴滴开源的 滴滴开源LogiKM一站式Kafka监控与管控平台 ConfigCommand Config相关操作; 动态配置可以覆盖默认的静态配置 sh bin/kafka-configs.sh --describe --bootstrap-server xxxx:9092 --version 所有可配置的动态配置 请看最后面的 附件 部分 2 增删改 配置 --alter –alter 删除配置: --delete-config k1=v1,k2=v2 添加/修改配置: --add-config k1,k2 选择类型: --entity-type value 示例 consumer_byte_rate producer_byte_rate request_percentage More Kafka专栏持续更新中…(源码、原理、实战、运维
2、运维在交付的“最后一公里”看到了问题,并 愿意为此提出改进方案,并推动落实之。 运维之痛1:人肉 vs 平台 人肉不是传统运维的当下过失,是过去的延续。在早期,运维的很多能力建立在少量的高可用硬件对象之上,平台化的需求很弱。 不过很开心的是,传统企业运维人对运维平台拥抱非常强烈,从运维自身能力自动化到全流程的持续交付自动化。 运维之痛2:流程 vs 创新 很多人会告诉我,在传统企业中没办法,我们必须通过流程来驱动各个组织角色,确保协同工作。真的如此么?我们在腾讯维护那么多产品线,没有流程怎么做到的?然后真的会混乱不堪么? 传统企业的运维问题绝不是人的能力问题,是多方因素的综合结果,因此在寻求解决方案的时候,需要立体的方案。
而运维作为IT运行的有力保障,在不同时期和不同类型的企业中正在发挥着越来越大的支撑和引领作用,今天就让我们聊聊信息化时代的传统运维、互联网时代的互联网运维和数字化时代的业务运维有什么不同! 故障发生时,要求互联网运维能够第一时间发现问题,并快速进行根因分析,依靠人工巡检的传统运维管理方式严重落后,自动化运维逐渐流行。 ,传统运维和互联网运维难以有效支撑企业的数字化转型。 未来,随着机器学习、深度学习等技术的不断成熟,AI技术将在业务运维体系中得到广泛的应用,共同推动IT运维市场的进步,而这就是业务运维在几年之后发展方向——智能运维AIOps。 通过不断的数据积累和持续学习,智能运维AIOps将把运维人员从纷繁复杂、过度依赖人工的监控、发现、告警和修复工作中彻底解放出来,而运维也将变得更加自动化、智能化。
配置查询 其他配置/clients/users/brokers/broker-loggers 的查询 broker-loggers 查询指定Broker的Logger相关配置 查询kafka版本信息 2 默认配置 附件 More 日常运维 、问题排查 怎么能够少了滴滴开源的 滴滴开源LogiKM一站式Kafka监控与管控平台 ConfigCommand Config相关操作; 动态配置可以覆盖默认的静态配置 sh bin/kafka-configs.sh --describe --bootstrap-server xxxx:9092 --version 所有可配置的动态配置 请看最后面的 附件 部分 2 增删改 配置 --alter –alter 删除配置: --delete-config k1=v1,k2=v2 添加/修改配置: --add-config k1,k2 选择类型: --entity-type
2016年,Gartner提出智能运维AIOps的概念,旨在使用大数据、机器学习等方法来提升运维能力,其目的是进一步降低自动化运维中人为干扰,最终实现运维无人化、自动化。 在面对当前复杂的技术架构、不断引入的创新技术之下,传统运维团队原来被动救火式、问题驱动式的经验运维,已经很难实现业务连续性的保障目标。 以场景为导向 场景驱动,以痛点、价值期望切入点,用智能赋能运维场景,落地智能运维能力。 AIOps从词来看,应该包括“AI+Ops”,是用AI赋能运维场景的模式。 为了规范国内智能运维领域的发展,中国信息通信研究院发布了《智能化运维AIOps能力成熟度模型》系列标准。 在《智能化运维AIOps能力成熟度模型》中,面向智能运维整体能力建设,规定了对IT系统或平台进行智能化运维的参考框架及分级评估方法,提出了关于企业建设智能化运维能力的实施路径,能够指导国内互联网和传统行业在智能运维方向的相关实践落地
那对于 AIOps 这个新名词,它又会涉及到哪些新技术?从运维的发展角度看,为什么说 AIOps 是必然趋势?它与自动化运维之间会有什么样的关系? 另外 AIOps 一定是建立在高度完善的运维自动化基础之上的,只有 AI 没有 Ops,是谈不上 AIOps。 InfoQ:你认为 AIOps 是运维发展的必然趋势吗? 从手工运维,到自动化运维,再到现在的 AIOps,谈谈你理解的运维发展趋势? 赵成:必然趋势。 当然这个过程中,因为云计算发展,传统的网络、硬件和系统维护的职责在逐渐的被弱化,也在逼迫着运维的关注点从底层转向应用和业务层面。 所以,我们看到就在近 2-3 年,自动化、发布系统、稳定性平台这些系统成为了运维团队重点关注和建设的部分。
2、性能监控和故障排除 由于微服务架构的复杂性,监控系统的性能并及时排除故障变得更加困难。 4、部署和运维 由于微服务架构中有多个服务需要独立部署和运行,因此部署和运维的复杂性增加了。 将异常处理效率提高和用户体验提升后,运维人员的沟通成本将会极大被降低,这样运维人员就有更多时间进行技术投入,能将更多“人肉处理”的异常变成自助或自动处理,从而形成“飞轮效应”。 图片 这个图主要体现从数字化运维,智能化运维和智能化运营三个阶段,每个阶段递进,数学化运维主要体现的就是监控系统,发现问题,故障通知报警,而智能化运维体现的就是全链路智能化分析,当出现问题后 图片 随着AIOps的不断演进和实践,我们正逐步迈向一个更加智能、高效和稳定的运维新时代。
超过 60% 的企业已经部署了 AIOps 平台,但大多数运维团队依然在"告警 → 排查 → 修复"的循环里疲于奔命。问题出在哪?本文换个角度看 AIOps——也许方向比工具更重要。 一、AIOps 的尴尬现状问一线运维人员一个问题:"你们上了 AIOps 之后,最大的变化是什么?"最常听到的回答是:"告警少了一点……吧?""有个告警聚合功能,还行。""说实话,没太大感觉。" 60% 的企业上了 AIOps,但只有不到 20% 的运维人员觉得"明显有用"。为什么? 二、两种 AIOps 思路:治已病 vs 治未病治已病(传统路线)治未病(CloudQ 路线)切入点监控数据核心能力告警降噪、异常检测、根因分析解决的问题出了问题更快发现价值体现MTTR(平均修复时间) 这才是 AIOps 应该有的样子:让运维人员少加班,而不是加班时效率高一点。
运维从横向、纵向分可以分为多个维度和层次,本文试图抛开这纷繁复杂的概念,讲述一个传统的企业级运维人员转型到云运维人员,尤其是软件定义存储的运维之间经历的沟沟坎坎。 因此,云数据中心的运维对于传统的运维人员提出了新的能力要求——不仅要熟悉传统硬件设备,同时要掌握虚拟化、云系统的部署、监控和管理等运维能力。 Ceph运维工程师对于比传统运维人员既有相似点也有不同点,要做到能文能武,文能提笔写Ceph运维手册、预案手册等;武能挥手部署Ceph、进行预案演练、故障处理、集群扩容等。 所以下面我讲述一个真实的A公司传统企业运维人员转型运维Ceph SDS的历程。 本文主要说下硬件选型关卡。 欲知后事,且听下文《从传统运维到云运维演进历程之软件定义存储(二)》,主要讲述了A公司运维小哥在硬件选型完毕之后开始部署Ceph遇到的一些问题以及解决办法。