边逛边看边学习

一体化数智运维解决方案中的业务全链路观测场景通过综合利用调用链、日志、指标、配置、网络等不同领域的运维数据，构建以业务为观测视角的横向到边、纵向到底的端到端链路，提升了多系统同时告警时的业务影响分析能力以及快速故障定界能力

对近期运维类故障大事做个记录

数智化的建设道路是循序渐进的，在近年来大量行业客户业务体量激增、稳敏双态共存状态以及云上云下架构复杂化的背景和挑战下，更需要以业务视角出发，左移运维建设规划，因地制宜地进行建设。

此次应急作战在AI运维机器人的帮助下，极大加快了数据分析和应对流程。AI R在流量控制、数据库同步调整、应用性能监控等方面提供了关键支持，所有告警现已恢复。

今后 Gartner 将把中国的智能运维称为 “ 中国 IT 运营管理中的 AI 应⽤ ”

面向业务对象的运维全面可观测，必不可少

国内智能运维厂商的月度动态（主要收集自公号）

智能运维应急即在IT系统出现异常或故障时，快速发现问题、准确定位、高效修复并验证恢复的全过程。它不仅包括故障发生时的应急处理，还涵盖了故障预防和事后优化。我们将应急处置分为了六个阶段

金融业的信息化建设，经历了从区域分散式机房 - 数据大集中 - 两地三中心多活 - 云化智能化等过程的发展。这中间经历了信息化建设技术架构、业务服务渠道、通信技术发展、信息化运行手段各阶段的变迁，未来的金融信息中心，将是：数据价值创造中心、先进科技创新中心、协同运营总控中心、绿色可持续发展中心、及智能自治共享中心。

大型语言模型在各种应用场景中都展现出了强大的能力。无论是信息提取、文本释义、内容生成、内容归纳总结，还是内容格式化、编程应用、翻译、自然语言处理、知识获取，甚至是图像生成（抽象的可以，带事实数据的欠佳），都能够有效地完成任务，提供高质量的结果。

风险预警场景主要面向业务系统，以风险管控为主要视角，通过风险指标、健康度风险模型、风险识别矩阵三大模块构建而成

本次项目的目标是对一头部券商客户的“核心业务系统”在过去6个月内产生的33.6万条历史告警数据进行关联分析。通过5轮迭代，我们最终得到了22条关联模式结果，并由数据科学家筛选出了13条有效结果

由于可观测性需求的深入及实施，带来了大量的告警需要进行处理，原有的统一事件管理平台仅完成了对告警的收集、告警标准化、丰富和通知等能力。当前客户面临的最大问题是：告警不能进一步收敛，缺乏运维专家的经验可以将同一问题引发的多个告警进行有效的关联，进而进一步降低告警的处理量。

新一代全行运维一体化平台——“启明”，总体分为两个阶段建设，第一阶段：“建平台，夯实底座”，以一体化平台基础能力为核心建设内容，完成统一采控、数据治理、企业级CMDB、自动化等模块建设，并实现多云环境、信创环境适配，在场景侧优先建设统一监控、应急处置等重点应用。第二阶段：“搭场景，运营生态”，在第一阶段基础上，重点建设技术变更、灾备切换等场景，探索告警智能收敛、根因推荐等智能化应用。

运维大模型的案例分享

运维大模型，当下有什么落地场景？

用“挖呀挖呀挖”说明IT运维数据的价值

智能运维AIOps居然和足球赛有一样的阵型！

让我们看一下2022年我们从市场、客户处所看到并值得关注的3个AIOps新趋势。

2021年6月初，擎创科技CEO杨辰在北京双态用户大会上做了“循序渐进推动智能运维建设”的演讲。这里可以下载演讲的pdf：2021古北 循序渐进推动运维数字化和智能化

老杨的话#中翻中#：智能运维，是在数据中台的基础上，对告警、指标和日志数据进行分析处理，并通过智能运维场景来支持运营决策。20201127 GOPS上海_杨辰 03下一步，从数据到信息和知识。那信息和知识的层面，在擎创看来又有什么分别呢？首先我们来看信息。信息就是指对于运维数据的基本门类的粗加工或者说单元的加工能力。这里面又包括了4个门类。告警数据第一个门类是对运维数据中间最重要的一种能力，也就是告警数据。告警是我们运维人员之眼。也就是说运维想要看到问题，多半绝大多数是..

老杨的话#中翻中#：智能运维的数据中台，不具备以下三种能力就是耍流氓那么怎么样去提升认知能力？就从4个层面或者从应该说4个信息的提炼层面，首先第一点，我们要来看说我们的运维数据从哪里来？其实是从传统运维中来的，从传统运维的多样化的运维工具系统，还有一些设备对吧？应用中间来。这些多样化的数据其实是需要经过三类的处理。第一类处理是非常重要的，就是因为数据量大，所以对于大数据量的这种十九化的方式，是要先想明白的。有日志的持久化的方式，键值数据，指标数据有指标数据的持久化的方式，然后告警...

视频地址：https://v.qq.com/x/page/y3221i0z30q.html （尝试插入，报错未成功，还得再试试）文字版 ——我们的行业客户其实已经分布在包括像金融服务领域的，银行、保险、券商等行业。其实在18年以后，特别19年也出现了多样化的一些行业，包括电信、政府、制造业、能源等等，其实现在都开始有探索智能运维的必要。为什么是这样？我想分4个方面来给大家解释。一方面我们来谈一谈为什么企业会需要智能运维？本质上还是因为企业身处在一场数字化转型的洪流之中，越来越多...

公司更新了2020.11的《智能运维建设手册》。从建设路径到实际产品架构均有讲述。下载地址：https://download.youkuaiyun.com/download/dazuibar/13582518#智能运维# #AIOps# #IT集中监控#

公司内部培训中的一个主题，企业为什么需要夏洛克指标解析中心、又为什么需要日志精析中心、告警辨析中心来进行智能运维建设呢？咨询顾问讲师给举了个特别形象的例子：IT运维工作，实际上跟医生看病的过程特别像。身体不健康了，就要把症状描述给医生听，再做一系列检查，最后由医生判断哪里是根因，再进行治疗。那么，在整个智能运维体系中，告警是触发排障工作的最重要来源，而指标的分析，就好比看病时的第一步“验血”。它可以快速判定问题出在哪些指标，从而为下一步做什么分析指明方向。但跟验血一样，指标也很有局限。我们没

从2016年Gartner提出AIOps概念后，经过几年的发展，慢慢有了相对清晰的架构。实践证明，分这样三层，可以有效处理数据并在数据中台上随时叠加多个应用场景。最底层是统管全部数据的数据处理层，包括所有组件、设备、第三方监控等的数据，根据使用者的设置要求统一采集存储。数据治理层最主要的能力也有三个。一个是流式处理，只有这样的能力才可以达到秒级处理，为异常预警争分夺秒；第二个是AI智能化算法，可以对数据进行建模、对算法进行训练、达到机器学习的效果；第三个是运维大数据处理，具有大数据的处理能力。经过

老杨说，现在很多的企业，对于IT运维工作，都安装了不少监控工具。比如普罗米修斯啦、Zabbix啦、甚至也有不少IOE的产品。但大多数企业首先会把告警的数据进行集中管理，这样便于及时发现IT系统可能存在的问题。但监控的各项指标数据，则依然存放于各个监控工具内，不到告警的阈值不会引起注意。而智能运维的建设，则需要把监控的指标数据也统一管理起来。这样既可以通过AI算法来尽早发现还没有触发告警的异常，也可以在排障时将多个系统的指标放在一起处理分析，大大缩小MTTR（平均排障时间）#老杨说运.

夏洛克AIOos的各项产品，越来越多将数据和智能应用场景区分开来。这样做的好处显而易见。对于IT运维指标数据，也建立了类似的处理流程。来自多个IT设备的数据（比如业务分析数据、APM的应用监控指标、自采的架构监控指标、日志数据、第三方软件...），不再逐一分析，而是先通过实时数据流处理平台，将数据规整后存储到“指标管理池”内，再在此技术上建立模型。在指标数据上面建立的场景应用可以是 “监控”“告警”“异常分析”“容量分析”“根因定位”，乃至生成统一的业务视图、仪表盘、大屏。#老杨.

9月底深圳开了场专门运维的技术会，很多运维相关的工程师去听去看。公司参与了智能运维AIOps场的演讲（好几个分会场都跟AIOps相关，就知道这个词现在在运维领域里有多热火了）。没想到还有参会的华为工程师在网上分享了他的心得，对擎创的架构印象最深。把运维数据中台化，再在上面搭建各种应用，未来也是个方向吧原文可自行百度...

近期，复旦大学计算机科学技术学院教授王鹏在深圳某会的AIOps最佳实践及解决方案专场，讲述了他作为时序数据算法专家对智能运维算法场景的理解。“智能运维在国内发展已经是如火如荼，甚至出现过度炒作的现象（如宣称拥有完整的解决方案、通用的大而全的算法），但是在场景落地能力方面目前仍然十分欠缺。实际上，智能运维的落地，除了需要考虑算法的设计能力之外，还应该考虑对运维场景的理解能力，以及平台的工程化能力。 算法的设计能力。客户的需求是个性化的，我们需要设计针对性的算法。此外由于生产环境不同，客户的数据也

把指标数据读入后，进行处理并存储在“指标管理池”，便于进行各种后续处理。

2020.08.26（周三）晚上20:00本期主要分享的话题：1.综合运营分析的挑战2.指标管理池构建对于指标数据治理和运营分析的重要意义；3.如何从业务视角洞察指标体系的健康度4.业务运营问题的指标波动分析和根因推荐#老杨说运维#...

开会时有老大提到，用于智能运维的算法有不少是有监督学习，在一定规则下学习出适用的场景模型。而我们需要做的“无监督学习”算法，难度则要大不少。对于我们这种算法小白，虽然理解了有监督和无监督的区别，对于无监督到底是怎么学习的还是有点云里雾里。直到前几天看到一张算法学习的图，才略有点明白。挺有趣的：如图中所描述，无监督学习也是分一段段时间的。第一阶段开始根据读入的数据初始建模。建完后继续学习，这时有突增的异常发生，使得变宽。原先初始阶段建的模不好用了嘛... 结合成新的模型检测暂.

在智能运维领域做了越来越多项目后，感觉大量的国内企业要用好智能运维工具，首先要把数据治理好。（前些日子电视里说，有些农村妇女经过培训当上了“数据标注师”，大量廉价人力的供应，或许真是中国大数据行业弯道超车的机会呢！）所以我们把与智能运维数据相关的功能剥离出来，这部分都以“数字运维中台”的形式集中处理。真不是件容易事...

公司CTO在2020年04月时一个演讲里提到的智能运维核心技术栈。细看看，真不少。做toC产品时，完全想不到toB的软件如此复杂。hadoop、Elasticsearch、Spark、kafka、Vertica、Mesos、Apache、Flink...已晕...

在描述智能运维的前景时，我们常常会幻想它的终极场景：机器不休息地跑啊跑，异常预测、自动排障... 运维人员在旁边悠闲地喝茶学习，偶尔提供点解决方案就可以了！梦想很美好，可惜实现的路还很长。就像手机的发展历程，20年间，经历了多个功能的赋能，慢慢集成成今天看到的样子。建议的智能运维建设之路是：现有的监控数据，用智能运维的分析平台来归整分析 在进行集中监控（系统网络监控、或者应用性能监控APM等）改造时，同时引入智能运维能力 以事件的集中和智能管理整合多样化监控指标、日志异常智能.

最近情况变了一点。记得两年前，只要是智能运维的项目，大部分都是日志。似乎上日志分析系统是智能运维的第一步。事实上，在我们协助建设智能运维系统的多家客户中，日志只占了其中一半不到的量。日志数据，可以通过日志平台来存储、分析，但传统的日志处理偏向于事后分析，来找出问题的异常。智能运维则借助于数字运维中台的能力可以抓取实时数据来进行事中监控甚至是事前预判。有不少其他方式的监控数据无法判断的问题，换用日志分析，会更容易得到结果。智能运维，会用到日志，但也不仅仅是日志。...

企业需要先建设DevOps吗？看起来DevOps和AIOps之间并无冲突。一个注重于将已有的运维事务标准化（做得好也不容易）；一个注重于决策选择。有标准化后的数据最好，没有也可以利用现有系统的日志、指标等来进行分析。如果企业还没有进行DevOps的建设，那可以从运维场景智能化先入手。如果企业已经有完善的DevOps，则可以在其建设中融入智能化的处理能力#老杨说运维#...

前几天看到一篇德鲁克管理学院的文章，叫“先干起来，你就赢了50%的竞争者”。这句话说起来很是轻松，但在做产品、做企业决策时，我们总是怕自己做了不是最佳的决定，而讨论来讨论去，迟迟不敢迈出第一步。实际上，只要投入不是完全浪费、也不是不可补救，闭门造车八成造出来的不是什么好车，只有先做一个非“想象中的完美品”，交于市场打磨，才会让产品越来越契合市场的需求。同样，智能运维的建设也不是一蹴而就。大而全、基础好的企业，自然可以高举高打，凭借完整的数据储备，在其上发展出超多的智能运维场景。而小企业，在数据量还没

我们在给企业客户做智能运维系统演示时，总会发生演示环境时很容易就能展现出算法的结果，看着也很漂亮，让人惊叹。但一段时候后接入真正的生产环境，用算法来进行检测就没一开始那么准了，靠AI算法打天下的情形无法复现。对比后得知，演示环境中因为数据有限，很多业务指标的异常只需要周期性异常检测就能发现，这个算法并不难而真正的生产环境，会有很多非周期性的基础架构指标。因为这些指标的异常不具备周期性，检测就很难准确，需要根据各种数据的情况再调整具体的参数和检测方法：调参对算法的实际应用来说，非常耗费功夫