CodeWisdom

“智能化软件开发沙龙是由CodeWisdom团队组织的围绕智能化软件开发、数据驱动的软件开发质量与效能分析、云原生与智能化运维等相关话题开展的线上沙龙，通过微信群访谈交流等线上交流方式将学术界与工业界专家学者汇聚起来，共同分享前沿研究进展与业界实践，共同探讨未来技术发展方向。”

可观测性与智能化运维

智能化软件开发微访谈·第二十一期

背景介绍

以微服务体系结构为主要特征的云原生软件系统通过细粒度的服务拆分以及服务的独立开发、交付、部署和伸缩能力极大地降低了单个服务开发的复杂性以及整体系统的可用性和可伸缩性。然而，云原生软件系统所包含的大量服务之间复杂、动态的交互关系以及系统所处的复杂、动态的运行环境使得系统的运维管理和高可用性保障成为一个重要的挑战。当前，以指标（metrics）、日志（log）、链路轨迹（trace）为主要支柱的可观测性（Observability）已经成为所谓的智能化运维（即AIOps）的重要基础。可观测性具体代表什么含义？可观测性在实践中有哪些具体实践？可观测性的流行代表着我们看待复杂软件系统的眼光发生了什么样的变化？基于可观测性的智能化运维未来的发展方向在哪里？

针对这些问题，本次微访谈邀请了来自学术界和工业界的多位专家，围绕可观测性与智能化运维这一主题展开讨论，总结业界实践和学术界研究进展、探讨相关技术问题以及未来的发展方向。

主持人

彭鑫

复旦大学教授

嘉宾

裴丹

清华大学计算机系长聘副教授

陈鹏飞

中山大学副教授

贺品嘉

香港中文大学（深圳）助理教授

张圣林

南开大学软件学院副教授

林庆维

微软亚洲研究院首席研究员

王含璋

eBay应用研究员

凌志钧

字节跳动 APM服务端负责人

林帆

阿里云 云效数据洞察产品板块技术负责人

蔡小刚

华为云应用运维域首席架构师

范超

京东零售平台运维负责人

访谈主题

可观测性与智能化运维

01

能否谈一下您对可观测性的理解？可观测性对于以微服务架构为主要特点的云原生软件系统为什么特别重要？它与我们一般所说的“监控”是什么关系？

02

可观测性这个概念为什么这两年会火起来？可观测性的流行代表着我们看待复杂软件系统的眼光发生了什么样的变化？

03

您所在的企业以及您所了解的企业中在可观测性数据的收集、处理、分析方面有哪些成功的实践？当前所使用的可观测性技术还存在哪些问题和不足？更细粒度、更深层次的可观测性技术是否有现实需求和应用前景？

04

您如何评价数据挖掘、深度学习、知识图谱等智能化技术在可观测性数据分析中所发挥的作用？智能化技术在当前的云原生软件系统运维实践中发挥了什么样的作用？

05

您认为基于可观测性的智能化运维未来的发展前景如何？有哪些值得学术界和工业界探索的发展方向？您对相关领域的学术界研究者或工业界实践者有什么建议？

Q&A记录

Question 1

主持人：能否谈一下您对可观测性的理解？可观测性对于以微服务架构为主要特点的云原生软件系统为什么特别重要？它与我们一般所说的“监控”是什么关系？

裴丹：

当我们说一个系统“可观测”，是指其内外部行为可以基于其观测数据和领域知识给出合理解释。而可观测性是指：a）一个系统可观测的程度；以及b）为了提升其可观测的程度，在开发、测试、运维（DevTestOps）中所做的设计、实现、及各类技术。

以微服务架构为主要特点的云原生软件系统用户体验要求高，本身规模大、服务数量众多，调用关系复杂；监控数据模态多、数据量大、速度快、信噪比低。因此云原生软件系统的可观测性非常重要，同时挑战性也非常大。

如前所述，可观测性的内涵包括“为了提升系统可观测的程度，在开发、测试、运维（DevTestOps)中所做的设计、实现、及各类技术”，因此可观测性可以粗略认为涵盖传统、狭义的“监控”，并且范围要更广泛，特别在开发、测试中为提升可观测性做的设计和工作（分别如：TracingFramework、混沌工程等）不在传统“监控”的范围内。当然“监控”的内涵也在随着时间推移不断扩展，比如有人认为“可观测性”的三个支柱traces、logs、metrics及对应的后续处理、分析都算监控范畴内。在此不做展开阐述。

陈鹏飞：

我的理解跟裴老师有点类似。个人认为可观测性是对系统由外到内、由现象到本质的观察过程，不是静止的观察系统的状态，而是动态溯因的动态过程。与传统的监控不同，传统的监控是相对静态、孤立、固定的获取系统的状态，运维工程师被动地观察各种数据表格、曲线，以此找出问题根因，适用于相对稳定、变化不大的系统中。而可观测性是一种主动、关联、交互式的运维过程，是通过不断验证假设找出问题根因，适用于动态、多变的系统中比如当前的云原生系统，不仅仅回答发生了什么，还要回答为什么发生。总之，可观测性不仅仅是对系统的简单遥测，而是一个不断深入到系统内部、解决问题的过程，最终提高软件系统的用户体验。

监控是一个相对单一和开环的过程，而可观测性是一个综合和闭环的过程，需要融合三种支柱型的数据即指标、日志和调用链等解决问题。这对当前复杂的以微服务架构为基础的云原生系统至关重要。主要的原因是微服务架构的复杂性、分布式以及动态性的特点，导致传统的监控没有办法在这样的场景中真正发现问题根因。云原生系统动辄数千个服务实例，上百万个指标，传统的监控手段往往将这些指标独立看待，而且指标之间存在大量的冗余，不仅浪费大量的存储空间，而且无法快速定位问题。但是，根据可观测性的理念，可以将不同维度、不同数据源的运维数据进行关联，根据需要解决的问题选择观测数据，并且能够根据系统的变化不断调整观测策略，不仅可以节省存储空间，而且能够快速、有效解决问题。

观点讨论

@彭鑫：两位老师都提到了可观测性作为一种能力，需要我们主动去规划、设计和实现。

贺品嘉：

我感觉可观测性是一种衡量指标，展示 软件数据的使用 能多大程度上还原 软件系统的真实（运行）状态。换句话来说，当DevOps团队（或其它有关人员）对系统状态有疑问的时候，现有的软件数据基础设施能多好、多快地回答相关的问题。 可观测性就像其它重要的系统特性一样，比如系统功能、性能、可测试性。

监控是可观测性的必要非充分条件。监控是提升可观测性的一种手段。监控任务通常目标确定，关注系统在某个预期指标下是否正常工作，比如两种日志模板出现的频率是否成一定比例关系；而可观测性的重点在于如何更好地把系统运行的状态展示给人看，不与特定任务绑定。监测常以系统故障为中心，可观测性以帮助人理解系统为中心。

在以微服务架构为主要特点的云原生软件系统中，系统架构复杂，服务灵活多变，观测难度大大提升，因此大家意识到可观测性的重要。过往简单的三层架构服务现在可能是部署在不同云上的几十个微服务。

张圣林：

我的理解与以上老师们的观点很类似。可观测性的原始定义为系统可以由外部输出推断其内部状态的程度。

在云原生软件系统中，应用系统一般以微服务的形式部署成多组应用，调用关系十分复杂。如果不统筹考虑整个云原生系统的可观测性，那么很难判断整个系统是否出现了异常，并及时诊断异常。此外，只有在云原生软件设计阶段就充分考虑可观测性，才能发现总结云原生系统的故障模式。

可观测性包括了“监控”，但又不只是“监控”。监控只发生在软件维护阶段，但可观测性贯穿了软件的开发、测试和维护等多个阶段。可观测性不仅概述了系统的运行状态（即“监控”），检测和诊断可预期的故障，而且能够感知系统的隐式故障，采用正确性验证等方式对云原生系统进行更加立体的测试。

林庆维：

跟几位老师的观点非常相似。我个人认为，可观测性描述了对于复杂系统内部状态和运行情况的刻画能力。云原生软件以及云基础设施系统已经变得越来越复杂，并且不止是一个单一的复杂分布式系统，而是一组互相依赖、称之为体系的系统的系统（System of Systems）。面对这样的复杂体系，还处于高度动态中，没有人能够掌握全局，只能通过观察来看到系统的一些可测切面，尽可能的了解系统。

可观测性提供了监控需要的基础数据，只有可观测系统才能更好地监控。除了帮助监控，可观测性基础数据还赋能故障诊断分析、系统优化、资源调度等等下游任务。

王含璋：

可观测性是源自控制理论的概念，指从外部输出推断及衡量系统内部状态。也可以理解为一个工程系统的状态自解释及其衍生能力（比如故障恢复和质量优化）。每个工程系统都必须考虑高可用和高质量，所以可观察性一直都在实践中逐步发展。对于微服务架构而言，高动态、高多样、快迭代和大规模等特点极大地增加了可观察性的相关实践的挑战，比如分布式系统也就意味着分布式故障，所以可观察性自然显得更为重要。

监控和可观察性的目标是一样的，但在工程实践上有很大区别，也是从解决“Known Unknowns”到“All Unknowns”的演进。传统监控的代表工具从早期的sysstat、iostat、zabbix、ganglia再到现在的promethus，大多基于metrics (数值加tag/label)支持各种数据操作(slice&dice/query/group)和衍生应用。但监控的大多原生方案只支持low cardinality数据，写入前需要提前做好某种准备/聚合。这导致了对使用场景的限制，使得监控的场景可以解决“Known unkowns”——如某个应用的几页dashboards和报警系统。

而可观察性需要解决 “All Unknowns”，比如出现业务故障时观察链路数据，跳转不同dashboards对比各个services上的不同指标。这类需求要求high cardinality的底层数据处理能力支持，再进一步，要使得这些海量多态的数据可以同时被高效的探索和理解，传统监控的dashboards是不能scale或支持的。以上这类 “Unknown Unknowns”的例子都是可观察性需要解决的问题。

同时，伴随着技术发展，每个人职责不断细化，比如SRE又分为Infra和domain SRE，在故障发生时，沟通协作的成本大幅增加，而高可观察性的工具作为通用的能力提供统一的交流，理解，协作方式，提升运维效率。最后，监控更多地指只从外到内的观测能力，而可观察性更侧重于成为系统的原生属性，即与生俱来的自解释/自推断能力。

凌志钧：

可观察性最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动态系统提出的概念。若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观察性. 所以 他本质上描述如何通过白盒的方式监测目标对象, 知其然知其所以然。

微服务其实还是在多团队敏捷协作/服务细粒度弹性调度/稳定性隔离等诉求下提供了新的编程&协作范式。

上云[包括公有云、私有云、混合云]之后就又带来一些新的技术挑战, 随之而来的就是类似容器、服务网格、不可变基础设计和声明式API 以及一系列部署自动化,易管理易运维的生态构建。

回到主题,为什么可观测性对于微服务/云原生那么重要? 我理解本质还是在于提供对于整套系统运行时上下文透明和赋能。你可以通过指标来量化系统的状态, 可以通过日志看明细的异常,可以通过链路了解上下游在特定请求下的表现,可以通过事件来感知人为变更在时序上和线上状态的关联, 可以通过profiling了解系统内部代码级别的热点。

至于可观测性与监控的关系, 我个人觉得可观测性并不是个全新的方法论和概念, 更多的是监控的延续和升级。 也是由于上述新的研发范式变化, 所以对于监控提出了更大的要求和挑战, 需要更多整合 metrics、tracing、logging、event、profiling [也包括CMDB元数据]的各种数据, 在数据质量,上下文标准化,数据规模,时效性,离线分析等方面提出了更高的要求-- 随之升级成"可观测性"的概念。

林帆：

现在大家其实都知道，可观测性已经是云原生体系里面的一个重要的组成部分。在2013年提出云原生概念的Pivotal公司技术经理Matt Stine，在2017再次总结云原生应用6大特征时候，其中的一项特征就是可观测性。

在单体应用的时候，服务的代码高度耦合，业务边界不清晰，对开发来说，这种代码很容易腐化且不容易重构和局部替换，但对于运维来说，不论是部署还是监控都很简单，因为系统的复杂性基本上封装在内部。

但到了微服务架构的时候，系统内部的业务模块被显式解耦了，各个组件独立部署，这样既提高了系统演进效率，也更加有利于团队合作，但系统整体的复杂度其实是上升了，传统的简单几个指标已经无法满足这种复杂系统的运维要求。

与此同时，以往的应用由于没有可观测性的标准，内部模块之间的调用关系等等信息都是没有统一规范来对外暴露的，即使运维做了信息采集也只能用于特定的这个系统使用。云原生和Kubernetes的出现，为许多指标、日志、链路的采集方式都提供了标准，也让可观测性的问题具备了实现大规模产品化的可能。

监控和可观测性有一定关联，但后者的范围更大。可观测性是对整个软件研发生命周期提出的一种思想和实践方法，开发者在设计软件的时候，就应当将可观测性作为一个非功能性指标纳入到软件设计的考察范围当中。比如考虑到在什么地方需要输出日志，在什么地方应该需要提供一个可监控的埋点等等。在服务运维的阶段就需要对这些观测数据进行采集和分析。而监控只是运维环节中的一种观测手段，它更关注的是具体的采集工具和方法，并且监控通常是可以在服务部署上线之后再事后增加的。

观点讨论

@吴文胜：赞成这个观点。我们团队大概在16、17年左右，提出了架构可观测性这个属性。

之所以如此，而且不仅把可观测性限于云化软件、服务化软件，就在于当今软件的复杂度已高到了无以复加的地步。以往靠着人拉肩扛，简单建模的方式，已经再也不能够管理好未来系统的复杂性走向了。

通过现有的逆向工程、架构可视化工作，借助devops手段，也很难理解实际的系统架构，所以我们就希望能够从分析设计的一开始就预埋下系统架构的观测点，以便未来采集到必要的数据，把我们可能会关注的架构给恢复出来。

蔡小刚：

前面各位大咖给出深刻的理解。我从工程和Ops发展历史来说一下观点。它是过去APM技术的一种延续和专注化。它把可操作性排除在外了。

为什么重要?本质是云计算下的分布式、无状态微服务、动态auto-scaling、故障快速漂移等，加之容器化、serverless化的新计算模式的普遍使用，造成了现代化的应用非常的复杂和多变。需要更合适的度量、评价体系来及时感知甚至预测IT系统的变化。

与监控 monitoring的关系：从最终效果来看，二者基本可以等价起来。但从底层的实现来看，所采用的方法论又完全不同。可观测性体现出了 主体的属性特征的开放性；是一种主动的对外状态呈现，与过往的被动式监控截然不同。同时，它是从“以人为本”的视角度量业务系统：通过数据、通过表现层，给Dev、给Ops不同角色的人，呈现了什么样的观测结果。

观点讨论

@陈鹏飞：同意您的观点，就我个人的理解监控还只是一个静态的展现，缺少一种交互、增量的观察过程。

@贺品嘉：同意，现在自动化日志分析算法的效果，很大程度上也是由所收集到的日志的质量决定的。如果能在写日志语句的时候，就知道这个日志后续会被哪些可观测相关基础设施使用，应该会有不一样的日志语句设计。

范超：

从概念定义可以看出来，可观测性是对生产系统的从技术运营角度提出了更高层次的抽象化设计要求。在微服务架构下尤其升级到一个重要性层次，是系统发展到一定复杂度的客观反映。目标很简单，就是希望复杂的系统能够实现更好的控制，易于管理。解决方案上要面向工程师具备足够的成熟度，不单是要有相对完善的监控，还包括了基于监控的系统状态可度量，或者说是使⽤监控产⽣的数据和解释来全⾯掌握系统运行情况。还有更深层次的，比如把确定指标的监控升级转化成不确定问题的感知。

观点讨论

@彭鑫：通过嘉宾们的发言，可以看出可观测性已经远远超出了传统意义上的“监控”。一方面可观测性需要结合软件系统的特点（例如服务依赖和微服务体系结构）进行深入、综合的大数据分析。另一方面，可观测性是一种注入系统内部的能力，可以从系统设计和实现过程中考虑如何增强可观测性，例如引入分布式追踪（tracing）框架等。

@凌志钧：我想加个小问题: 可观测性面向用户会有哪些? 他们的诉求有什么不同吗?

@彭鑫：@凌志钧，确实，可观测性的用户应该多种多样。例如，高层业务层面是否也有可观测性的需求，例如触发告警和异常分析的有时候可能是业务指标。

@蔡小刚：可观测性不仅仅是面向运维运营人员的，主要的变化点是，也针对Dev研发段人员。比如我们在架构设计评审阶段，会衡量审视系统的可运维性。面向开发人员，会审视可观测性的实现，不管是对接框架能力实现的，还是自己开放API实现的。欢迎其他人拍砖。

@彭鑫：@吴文胜，"预埋下系统架构的观测点，以便未来采集到必要的数据" 这个是否跟云原生软件一样，是运行时产生的数据？个人的感觉，云原生软件可观测性和智能化运维代表一个思路变化，即我们越来越倾向于从一个复杂系统的运行时“活”数据中去获得对系统内部行为的知识，例如架构状况及故障传播链等。

@吴文胜：正是如此。我认为，之所以现在提出了架构的可观测性，其根本原因就在于以往对于运行架构的忽视。以往无论是哪一类架构设计过程，实际上对运行架构都是很少做设计的。我们大家可以扪心自问。我认为，可观测性的提出，可能是对以往忽视运行架构设计的一种弥补。

@吴文胜：是的，根据运行架构恢复的要求，来设计好将来的性能打点，进程、线程的调用日志，关键资源的动态，等等。

@彭鑫：@蔡小刚 衡量审视系统的可运维性：能否举几个例子？容易想到的应该是日志语句（where、what）以及tracing框架的使用，是否还有其他方面？

@蔡小刚：是的，有你提到的这些，以及时序指标，直接告警。还有可观测性的粒度控制问题，比如logging数据量不能影响业务，极端情况下优先级较低，对数据关联分析上关联点的设计等等。

Question 2

主持人：可观测性这个概念为什么这两年会火起来？可观测性的流行代表着我们看待复杂软件系统的眼光发生了什么样的变化？

裴丹：

可观测性这两年关注度不断提升，个人认为主要是由于如下三个原因：（1）云原生概念普及、更多云原生软件系统落地；（2）用户对云原生软件系统的服务质量期待不断提升，这就要求不断提升其可观测性；（3）而其可观测性又面临很多不易解决的技术挑战（规模大，多模态数据依赖关系复杂，数据量大、速度快、信噪比低等）。

陈鹏飞：

可观测性之所以在这两年火起来，我觉得可以从内因和外因两个角度看。外因是当前的软件架构、开发和运维的方式发生了变化，随着软件不断上云，云原生系统成为主流趋势。云原生系统的高复杂度以及高动态性的特性让传统的监控手段捉襟见肘，难以在第一时间发现和解决问题。随着云原生软件系统的大规模部署，软件性能和可用性关注的焦点逐渐从底层向业务层迁移，在这类系统中更关注用户体验，而且追求的是极致的用户体验，也就是P99的响应时间和5~6个9的可用性，服务好每一个用户的每一个请求，这就需要有更加深层次的可观测性来发现问题。而传统的监控主要以聚合数据为主，保证均值，但是不保证尾部用户的服务质量。另外，就是随着相关技术和工具比如tracing的成熟，我们能够监测到的系统的状态越来越多、越来越细，这也是外因之一。 内因是可观测性交互、动态、关联的特点，能够给运维成员呈现全景上下文，能够更加准确地检测和诊断问题。

可观测性的流行说明我们开始关注和正面理解、解决复杂软件系统，尝试利用一种更加直接、有效的白盒方式解决问题，而不是继续将系统看成黑盒，通过猜测或者算法来间接的观察系统、间接解决问题。

贺品嘉：

（1）以微服务架构为主要特点的云原生软件系统的普及。系统整体架构更复杂。此外，Michele Mancioppi在《Observability vs. monitoring debate: An irreverent view》中指出，2019年左右，开源分布式tracing软件在开发者中普及（特别是OpenTracing），一定程度上为增强可观测性提供了解决方案，也间接促进了可观测性的流行。

（2）随着DevOps模式的普及，需要理解系统状态的人越来越多、查询系统状态的频率越来越高。

（3）从“用户”的角度，大家不再满足于通过特定预设场景“监控”系统，而是希望能从一个全局的角度，了解系统的“健康状况”。从软件数据分析与可视化服务提供商的角度，现有的服务更丰富多样，“监测”不足以概括，需要一个术语来描述他们所能提供的服务。“可观测性”从这个角度来说是个比较适合的术语。

张圣林：

同意以上老师的观点。可观测性变得流行，主要得益于云原生软件系统的流行，以及大规模云原生系统的运维挑战越来越多、越来越大。在可观测性引入之前，一般是运维人员先根据经验采集一些类型的监控指标、日志以及调用链信息。发生故障以后，对故障进行复盘，发现当前的监控数据不能覆盖某些类型故障的检测和诊断，就增加更多类型的监控指标、日志以及调用链信息。这种“事后诸葛亮”的方式容易导致对故障的漏报、误报，造成用户体验下降和收入损失。

可观测性的流行代表着我们越来越重视复杂软件系统的可靠性和稳定性。在软件设计、开发、测试阶段，就考虑软件运行后如何观测软件系统的状态。既能快速感知软件系统的故障，也能感知系统的潜在故障。将设计、开发、测试、运维一体化，提高软件系统的稳定性和可靠性。

观点讨论

@林帆：这一点我们很有感受，以往做监控就基本上是运维自己的事情，可观测性这个思想和DevOps有一脉相承之处。

@彭鑫：@林帆，确实，好的可观测性也需要开发来支持甚至来实现，反过来好的可观测性又可以造福开发人员。

林庆维：

几位老师讲的很好。很赞同大家的观点。个人理解可观测性火起来是伴随着复杂软件系统（比如云原生）火的，而云原生为代表的复杂软件系统火是由于现代各种软件需求的复杂性，应对这样复杂性的产物。

其实在云基础设施（cloud infrastructure）中早就有telemetry、metric、log、trace了，只是更多的在云服务供应商中有使用和提及。学界以及大部分公司在拥抱云原生之前，涉及的大多数场景可以调试，或者故障点相对明确，问题相对也并没有那么复杂。log、trace等数据用来做故障分析诊断有非常悠久的历史，对于单机大型应用、web service、分布式系统都是有使用的。而随着需求复杂性的提升，带来了软件本质复杂性的提升，而系统也自然演进成了更复杂的体系。

类比于物理中的三体系统、混沌理论，即使只考虑三个天体间的牛顿引力作用，我们都无法精确刻画系统运动规律。对于复杂体系，我们通常只能观察，几乎不能直接推演。所以会提出可观测性的概念。

观点讨论

@裴丹：我也类比下：人体-复杂计算机系统；医疗检验检测能力-系统可观测性。

@彭鑫：@林庆维 对于复杂体系，我们通常只能观察，几乎不能直接推演：确实如此，所以我们要更多关注于收集运行中的系统产生的“活”数据，而不是像以前那样靠测试环境中的调试等手段来推演。

王含璋：

首先，传统的监控手段不够用了。我们在演进系统的同时还在不断追求系统诊断能力和故障恢复效能。但现在，海量多态的数据分布在分布式系统的每一个角落，从之前采集处理存储方案再到之前用眼观察或用手排查的方式都变得很难。同时，近年来，专注于不同分支的开源产品逐渐成熟(如Prometheus、Istio、Jaeger)以及基于围绕AIOps的智能故障检测/推断等应用技术逐渐落地，这概念就自然越提越多了。

可观察性的流行使我们开始追求更高效、更便捷的故障处理闭环(检测报警->根因排查->故障修复)。即降低TTD (Time to detect)，TTR (time to recovery)，最终实现高ATB (availability to business)。服务开发及维护人员们也越来越期待更便捷、更智能的运维工具了。

凌志钧：

个人理解火的原因可能是4点.(1)由于上题说到的微服务/云原生/FaaS等新技术的涌现 带来观测领域更大的复杂度。(2) 业务需求:  C端/B端业务对于事故的容忍度 & 止损时效性要求提升。(3) 上云 甚至是多云 带来的挑战。(4) 从整体行业的降本增效背景看, 希望能最大程度降低运维的难度 降低对于人肉专家经验的依赖, 提升自动化 & 智能化比例.

看待复杂系统的眼光变化: 复杂的定义可能是几方面的 (1) 深度: 链路的连通性足够复杂 以及深度较深, 你可能需要在技术和业务层面附加以服务域聚类才能有一定清晰的认知 (2) 广度: 服务单集群的容量/节点超大, 你可能需要基于网段/机架/机房/数据中心/集群 等等维度来观察. 这些复杂度的问题解决 可观测性基础设施都会是比较重要的原子能力支撑.

最终的变化还是在于4点赋能: 1 赋能运维, 降低运维的门槛。2 赋能技术研发 确认自身服务的稳定性/容量进而性能优化。3 赋能架构师 能真实的做架构梳理/治理。4 赋能技术管理者 在一个全景图下跨部门的多团队联合作战.

观点讨论

@彭鑫：确实，大规模云原生软件系统像是一个持续生长的生态系统，当前的架构状况很大程度上可能也需要靠观测，而不是像过去那样由架构师自顶向下规划和掌握。

范超：

过去面向一个业务系统讲监控的立体化实现，建设应用监控（APM）和网络监控（NPM）工具平台，在这些系统的实际使用中，遇见一些异常需要够做出基础的现象告警，比如一些核心指标数据曲线的同环比涨或跌，有相应的阈值触发告警。这些现象告警更多依靠一线工程师的经验去判断原因，及时止损，这明显是不可持续的，值班人员会成为瓶颈。部分监控指标的现象级告警距离原因定位还比较远，距离执行适当的措施及时止损就更远了。另外一方面，个别场景下的事故可能会导致令人头疼的告警风暴。这些心酸故事相信有些互联网人可能亲身经历过。所以，在继续演进的过程中尝试做场景化的告警收敛，基于经验沉淀场景化的原因告警。其实这些都应该算是系统可观测性的发展历程，解决方案往更加简单高效的方向演进。

林帆：

其实“可观测性”这个词被正式提出来到现在还不到5年时间，新的概念从提出到被普遍认知需要一个传播过程，所以到这一两年里我们在越来越多的场合听到大家谈论可观测性，也恰恰说明了它已经基本跨越了早期的舆论讨论阶段，开始进入主流技术圈的视野。云原生从提出到被大众广泛提及，也花了差不多3、5年时间。

对于任何复杂的软件系统，可观测性诉求是一直存在的。在Google的SRE体系里面，就很强调应用的白盒监控，本质来说就是对应用的日志、行为、调用链路等等的观测和分析。我们早些年在电信行业里做通信系统，对链路上各种信息的采集比起现在的微服务可以说是有过之而无不及。

所以我的观点是只要系统够复杂，开发者就必须去面对可观测性的问题。其实看待复杂软件系统的眼光并没有多少变化，只是现在的软件系统相比以前确实普遍变得更复杂了，大家对可观测性的关注也变得的更强烈了。

但即便如此，在云原生背景下提出“可观测性”这个理念还是非常有意义的，因为过去我们做信息采集，大型的设备商都自己定标准，采上来的数据不通用。现在CNCF很有预见性的提出了统一的标准，也就是OpenTelemetry这个项目，我相信它在未来会成为所有云原生开发者工具箱里的标配组件。

观点讨论

@裴丹：同意。我之前做了10年的网络智能运维，网络其对可观测性的诉求也是类似的。

蔡小刚：

火的原因客观说明大家面临着挑战，有痛点。 我重点说一下变化，这些变化包括了：数据种类的多样性和完备性。 比如我们去看一个传统Ops服务商的产品或服务时，经常会发现 日志系统只管日志，指标系统只管指标，APM产品只管调用链，尽管Ops厂商也在尝试做些融合和一站式的方案，从产品角度看，但总体效果不理想。它们更多像一个个孤立的烟囱。更单纯、业务边界更清晰。在过去的二十年里，监控业务既包括monitoring能力，也包括control的能力，也就是通俗所说的操作operation/take action的能力，追求的是能够形成闭环的自动化能力（Automation）。这种新的方法论与微服务架构中的单一职责原则有异曲同工之妙。最后，可观测性，并不排斥对原始数据的聚合、关联和洞察。 我的理解，insight能力才是在数据完备性基础上的下一跳，关键的一跳!

吴文胜：

我认为，可观测性的提出其实就一句话，觉得系统复杂性越来越高，原来各种“各样投机取巧”的方式不灵了。对大设计的不屑，需要一定的反动。

有些事情我们还是需要从设计的一开始就预埋到系统中，只有这样我们才能掌握必要的数据，进行推演，从中恢复出所需关注的运行架构，理解运行架构。

观点讨论

@彭鑫：@蔡小刚  确实，各种运维数据其实都是一个正在运行中的“活”系统在不同方面所产生的信息，背后其实刻画了一个系统的行为，需要将它们关联融合构成对系统的一个整体试图。因此烟囱林立的运维数据是不符合可观测性的要求的。

@林帆：我始终觉得问题还是那些问题，只是以前的复杂系统比较少，现在一方面是微服务化了以后许多系统变得更复杂了，另一方面可用的系统监控指标更多了，加上各种大数据和智能化的发展，这些原先的问题有了更好的解法。

@吴文胜：我认为，可观测性的提出其实就一句话，随着系统复杂性越来越高，原来各种“各样投机取巧”的方式（如服务化）不灵了。对大设计的不屑，需要一定的反动。有些事情我们还是需要从设计的一开始就预埋到系统中，只有这样我们才能掌握必要的数据，进行推演，从中恢复出所需关注的运行架构，理解运行架构。

@张圣林：的确是这样。如果不从架构上进行整体设计，就会导致运维人员不明白日志什么含义、调用链的报错什么意思。

@彭鑫：@蔡小刚，能力应该就是指对于系统的反作用吧？这个目前还不多，似乎到了采取措施的部分（例如扩容）都还是依靠专家经验的，但未来确实会进一步智能化、自动化形成闭环。这一点可能边缘计算中会更突出。

@彭鑫：嗯，运维人员像是警察，我们要为他们破案提供更加完整的信息链甚至证据链。

@蔡小刚：我们会经常谈论到自证清白的能力。

@彭鑫：@蔡小刚，嗯，根据跟业界专家的交流，边缘计算中的运维自动化程度要求可能更高，更需要首先形成自动化的闭环。

@贺品嘉：确实，现在系统的“健康状况”比原来更难观测了，有了痛点，大家也就都开始关注了。

@吴文胜：打个比方说，我们现在很多服务框架都包含着日志功能，但实际中，如果你真敢把这些日志都打开，很有可能系统会挂死，或者某些服务质量降低到难以容忍的地步。这里，就有两方面的工作可以提前做好设计。一是合理预判和规划好打开日志的方式，二是根据日志打开需要，合理调整系统的运行架构。

@张圣林：这一点太重要了，不能什么锅都让运维人员去背

@彭鑫：@吴文胜，日志以后可能也要像摄像头那样可以按需开启，例如发现问题迹象后可以针对系统某些部分开启更详细的日志记录。

Question 3

主持人：您所在的企业以及您所了解的企业中在可观测性数据的收集、处理、分析方面有哪些成功的实践？当前所使用的可观测性技术还存在哪些问题和不足？更细粒度、更深层次的可观测性技术是否有现实需求和应用前景？

裴丹：

我简单说下我从与合作企业了解到的部分实践信息：

（1）普遍对traces、logs、metrics、alerts、tickets、workflow做了数据采集；traces一般会有某种程度的采样；主要是在span级别采集，个别也在更细粒度的method级别进行采集。其它数据基本上是全量采集。

（2）处理一般采用某种（流式、批式）pipeline。

（3）分析方面一般对故障发现（异常检测）、故障定位、根因分析非常感兴趣，并有基于可视化、规则、统计、机器学习、深度学习的分析尝试。主要关注在线分析速度和开销。

当前的可观测性技术面临的挑战包括：

（1）采集层面的异构性（编程语言；第三方开源组件；传统且不易修改的代码；不同开发团队），虽然云原生系统的数据采集基础要比传统行业（如银行业）要好很多：更规范、有一些如OpenTracing的标准，更统一、更容易落地。

（2）现有可观测性分析技术与云原生软件系统的要求还相差甚远。

更细粒度、更深层次的可观测性技术肯定是有需求的，但是即使是当前常见的采集方法已经在开销、处理、存储、计算等方面遇到了较大挑战。因此未来的可观测性技术必须要统筹规划，根据可观测性目标，整体设计一个闭环系统；而不是采集、分析各做各的。比如借鉴一些DPI领域的做法，上层应用根据当前情况，通过SQL-like的查询，或者software-defined data collection，通知agent采集的粒度、深度；从而达到分析效果好和开销可控的双重目标。

陈鹏飞：

因为跟华为、阿里巴巴和腾讯接触比较多，首先可以肯定是大家都在都在积极推进可观测性，利用可观测性在解决问题。据我了解阿里和微信内部已经实现了调用链、日志和指标的关联，并通过逐步下钻的方式定位根因，并且在这些数据的基础上也在积极实践智能运维，实现一站式、端到端的问题解决，效果也不错。但是我个人觉得现在的工业实践在可观测性的广度、深度、云原生程度、智能化程度还存在问题。（1）首先是深度，现在商业和开源版的可观测性工具虽然已经提供了丰富的指标，但是还有些细粒度指标比如内核中的关键状态信息、队列等没有拿到，难以区分某些故障；（2）其次是广度，没有完全将指标、日志、调用链等关联起来，日志与调用链的关联的已经实现，但是如何关联指标还需要一些讨论和最佳实践的检验；（3）然后是云原生程度，现在的可观测性工具还没有完全统一，而且大多需要侵入源代码，学习代价和软件开发代价较大，未来需要实现可观测性与源代码的解耦，将可观测性能力下移到基础平台，摆脱与编程语言的依赖，实现云原生的可观测性。这就要求实现对用户透明的日志、调用链、指标等运维数据的生成、采集和分析，现状离这个目标还有一段距离，我们也正在跟阿里做类似的合作研究，利用eBPF形成统一的可观测性解决方案，希望能有一点突破。（4）最后是智能化程度，目前针对多种运维数据的智能化分析的程度偏低，还主要依赖于简单阈值和人工分析，亟需提高智能化分析水平，真正实现端到端自动化的问题检测、诊断和解决。

从目前可观测性以及智能运维的进展和效果来看，更细粒度、更深层次的可观测性技术的确是一种现实需求。云原生系统的故障类型和复杂度高，仅依靠现有的监控数据以及智能运维算法，难以实现具有可操作性的问题分析。更细粒度、更深层次的可观测性能够提供更接近根因的信息，举个极端的例子，如果可以刻画每一条指令的性能，那么分析软件系统的性能瓶颈就不再困难。但是，这里需要权衡，权衡可观测性代价与预期效果，不能过多牺牲性能和资源来换取效果。未来随着云原生应用的更深层次的发展以及可观测性技术的不断涌现，更细粒度和更深层次的可观测性技术将会具有广阔的前景。

张圣林：

成功实践（个人浅见）：使用一些开源框架，比如Prometheus、Elastic、OpenTracing等，可以快速搭建可观测性数据收集、处理和分析的架构，并基于这些架构进行二次开发。因此，即使初创公司也可以快速实现云原生系统可观测性数据的采集和处理。

问题和不足：在数据分析方面，将不同模态的可观测性数据，比如指标、日志、调用链等进行融合还较为欠缺。只有融合了多种模态的数据，才能准确检测云原生系统的故障，以及诊断故障。这是因为，单一模态的运维数据不能覆盖所有类型的故障，且容易产生误报。

更细粒度、更深层次的可观测性技术可以方便运维人员快速发现更细粒度的故障根因。但同时也给运维数据的存储、计算带来了极大的开销。需要在运维需求和运维数据处理能力方面找到平衡。软件服务提供商需要综合考量后再做决定。

贺品嘉：

我所了解到的可观测性基础设施一般包括几个组件：数据收集、数据去重与压缩、整合与分析、可视化与交互。所涉及到的任务包括：异常检测、重复/相似 问题识别、告警信息关联、辅助索引/过滤/排序等。

当前可观测性技术大部分是基于metrics、logs、traces这几类软件数据。如果数据本身不够完整，则无法提供全面、精确、与可靠的观测结果。用软件日志（log）举例。开发者在代码中写日志语句时，往往假设日志是在系统出问题时被人工查看，因此日志常有一段自然语言描述，因此日志语句不能过多。然而某些关键路径下的日志语句缺乏，常是异常检测失效的原因。在可观测性的考量下，日志语句自然是越全面越好。在以可观测性为重要特性的思维方式下，开发者写日志语句的实践或许也会有所改变。日志分为“对算法日志”与“对人”日志。“对人”日志就是当前我们常用的日志，会有一段日志语句描述特定的事件。“对算法日志”则不需要描述，重点在于记录程序运行路径与重要变量，以供后续各种数据挖掘与机器学习算法使用。

观点讨论

@彭鑫：@贺品嘉，日志分为“对算法日志”与“对人”日志。目前的日志主要还是传统意义上给人看的，例如支持关键字检索，给机器或者算法看的日志应该可以关注于记录更关键的一些信息（例如路径），似乎Span Log就有点像。

@贺品嘉：是的，“对人”日志因为是非结构化日志，还涉及到日志解析等步骤。“对算法日志”其实只要记录一个模板ID就行，与Span log类似。

林庆维：

同样的，作为云基础设施供应商，微软拥有IaaS、PaaS、SaaS各层全覆盖的服务，还有Azure、M365、Bing、Teams等广为使用的云应用。公司内部有非常好的数据收集、处理和分析平台和服务，并且有不少相关的系统论文发表。

个人看到两个当前可观测性技术和数据的重要问题，一是数据质量保障困难；二是数据之间的关联性。而这些都是由于目前系统的复杂性引起的。

比如说第二点，数据之间关联性的难点，其中很大的挑战是，微服务/模块间复杂的依赖关系难以完全获得。在云原生以及云基础架构中，服务间依赖非常复杂，常见的依赖方式就有进程间通讯，RPC远程调用，间接依赖（比如消息队列、数据库访问），运行时服务间调用依赖，还有部署时引入的基础设施实例依赖，负载均衡、容错集等引入的实例间依赖等等。要完整的发现所有数据背后的服务/微服务/模块间依赖关系，从而对数据间关联性建模相当具有挑战。同时，复杂软件的设计跟随组织架构，也会随组织架构的变化而变化，这在大型IT/互联网公司由几百几千人开发一个系统的场景中常常难以避免。

更细粒度、更深层次的可观测性技术一定是有其现实需求和应用前景，如果现有问题无法解决关键场景和问题，那么就需要更细粒度和更深层次的可观测性技术。

王含璋：

除了比较常见的基础能力，eBay做了比较强大的metric base的监控系统，虽然还有cardinality的限制但是这个限制已经非常小了，另外eBay也做了没有cardinality的“event”的系统，即用户不需要在写入的时候做agg。

同时，大家用了很大的力气搭建了机器学习平台和根因推荐系统，近几年来逐渐落地，效果不错，实际降低了TTD和TTR的时间，运维人员（尤其是新人）逐渐对工具产生依赖。我们的目标是逐渐完善更深更广的数据处理和分析能力，更好地从推断系统各种内部状态，让机器代替人完成越来越多的运维工作。这里我想特别感谢一下群里的彭鑫、谢涛、裴丹三位老师和lab同学们在之前的几次合作中对我们的指导和贡献！

所以正在解决的挑战也有很多：比如在时序预测领域，根据无/少标注的监控数据，智能选择算法、搭建更“通用”的算法或更高效的弱监督学习系统。比如在根因检测领域，在可靠的场景下完成自动诊断和修复的闭环；把根因搜索范围扩展到更远的范围（如网络层，edge层）；以及使监督学习的根因检测模型自动适配新的故障类型或更广的根因范围等。

更细粒度和更深层的可观察性是有必要的，在高效和便捷的用户体验的前提下，人工排查或确认故障的时候，快速下沉和理解细粒度或深层次的数据可以让运维人员少走很弯路（比如手动登录pod去查）。同时这也会为未来的各类机器学习应用提供肥沃的数据土壤。

凌志钧：

关于成功实践:我理解还是比较多的 比如从类Tracing看, 国内的阿里的EagleEye、 腾讯 天机阁、包括字节跳动的bytedTrace 都是比较多落地的场景. 海外Uber的Jaeger & Google 最早的Dapper & eBay CAL Logging, 开源社区还有Apache Skywalking 在很多公司采用率也比较高. 至于日志 & 指标类, 基本各个大厂很多都有各自实现或者是开源版本的二次开发.

问题 & 不足:

我个人觉得跨层间的上下文传递 包括术语、标签、指标名、日志模版的统一化, 另外埋点规范对于计算侧/存储友好上一般关注也比较少一些.

更细粒度、更深层次的可观测性技术:

我不太确定这部分具体所指, 但从数据采集侧看的确有必要收集细粒度的数据, 在后端数据处理 & 预计算 & 存储层 可以做一定的平衡 按需保留/产生粗粒度数据聚合, 相较于单位存储 产生的业务价值而言.

林帆：

阿里云在云原生可观测性的产品工程化方面做得还比较好，创建一个Kubernetes集群，系统级的监控都是自动配置的，然后如果要加上日志采集、链路采集、业务监控相关的服务也都有现成工具和方案可以直接用。

也就是说运维侧的很多工作都是可以自动化处理掉的，真正需要比较多人工参与的主要是前后两头的工作。往前是研发过程中的观测点设计和埋点透出，往后就是对采集到的数据做分析。

数据分析方面，大概一两年前我们团队还在服务阿里集团内部，当时有打算去做这么一个结合应用发布行为、日志、指标、链路，实现风险识别和归因的系统，和负责安全生产和技术风险的部门合作，同时和彭老师实验室的几位同学也在合作。

其实要说怎么做，大家心里都大概有数，但是发现一个很现实问题是数据量太大。阿里内部对故障处理是有1-5-10这么一个要求的。1分钟发现，5分钟定位，10分钟恢复，最后大家发现1和10都能做到，中间这个5特别难。

故障发生之后一般最多几秒钟监控就报警了，10分钟恢复其实本来也难，我们有很多大型应用重启一次就超过10分钟，但是阿里技术同学的能力确实很强，通过Serverless和操作系统的团队一起做了很多底层优化，硬是做到了分钟级的回滚。

唯独这个5分钟，因为整个链路太大，指标也比较多，即使反复剪枝，也没办法在速度和精度上同时满足要求。只能是从自动定位变成辅助定位，5分钟还是要出结果，不然错过了故障恢复了关键时间也就没意义了，但是这个结果只是给开发人员一个参考，最终还是要由人来判定。

后来我们复盘这个项目，总结出来故障定位不了的原因，不仅仅是数据量大，还有很重要的一部分问题在于原始数据的质量。当时集团里有个别BU的故障是可以很快被定位的，就是因为他们在BU级别上有统一的故障码机制，从日志里就能够很快发现异常来源和影响范围。

所以更精细、更深层次的观测这个问题，我觉得还是要看运用场景，如果是纯做事后回顾分析，可能有意义。但如果是实时的在线分析，数据太多可能不一定有用，数据的质量是关键。要做好分析还得从源头上入手，不然上游数据质量非常差，下游要分析出高质量的结果也很难。

范超：

我们有一些这方面探索，并且已经取得了一点阶段性的成果。比如部门所服务的APP产品，基于已有的APM监控平台积累了相对比较丰富的数据，从这些数据中抽取了秒开率、打断率、崩溃率等性能指标，结合应用层各模块耗时、异常、流量等数据，再加上基于用户反馈情况的语义归类分析，综合得出体验指数值，并按版本积累基线配合判断质量情况。指数的波动变化可以自动快速下钻到具体异常波动数据项上，甚至堆栈信息上，如果能够关联到已经沉淀的确定场景，会自动触发做出IDC节点调度、柔性降级等运维操作，这套解决方案已经在线一年多了，并且平均每月都会有1~2例实际的问题触发和自动处理解决，提升了业务连续性。面临的实际问题是对数据的分析和模型建立上，不仅需要场景的持续沉淀，数据达标和算法训练，还需要长周期数据的积累，不断迭代。但大家还是比较有信心，持续做下去会从量变到质变。

蔡小刚：

最近我们在做ePBF，面向业务指标的采集、网络IO、磁盘IO的采集，做到快速感知应用的变化。我们这些年在AIOps算法上进行了很多探索和实践。尤其在内部运维场景中更多，但作为产品和服务，AI的可解释性和可呈现性一直是个挑战。

技术问题和不足：（1）采集能否非侵入式？ 做到了，比如java agent、probe 探针， ASM、Javassit、ByteBuddy等字节码技术的； 针对的是应用程序，属于壳层面的拦截；（2）不显式部署采集器？靠谁来获取数据呢？我们很容易想到2点，一是靠框架，比如微服务开发框架、微服务治理框架（一般提供微服务的托管和运维等能力）； 二是在OS层面，通过ePBF技术获取数据感知能力。

更细粒度的，更深层次的可观测性技术(有动态on demand采集，也有洞察，尤其proactive的洞察) 非常有广阔的应用前景。 尤其是复杂业务软件系统。

观点讨论

@张晨曦：对机器的日志能达到还原执行流程的目的是不是就足够了？语义等信息可能也不重要了？

@彭鑫：@张晨曦 感觉文本语义可能还是有用的，因为我们是在没有源代码的情况下分析日志的，所以需要靠着文本信息带上一点程序执行的信息。

@贺品嘉：我感觉语义信息还是有一定作用的。比如某些词的出现或缺失可以辅助异常检测任务。不过相比于记录所有日志文本的开销，语义信息的“性价比”或许不高。如何提取关键语义信息，比如关键单词，也是一个有意思的研究课题。

@彭鑫：而且日志文本也应该搞点标准化术语了（甚至基于知识图谱），就跟代码标识符一样，如果足够规范的话会为后续的分析提供很大的帮助。

@蔡小刚：@彭鑫 这个idea不错，是否有人基于知识图谱的角度制定一个logging的规范?

@彭鑫：@蔡小刚，我们在代码分析上做了一些探索，后面可以针对日志也试试看@张晨曦。

@林帆：这个一般在团队或者部门层面还是有可能做到的统一规范的，就看有没人去推。

@彭鑫： @林帆，确实，代码标识符命名规范化也是类似。

@凌志钧：整体推动的难度 & 周期都比较长, 而且也还有确保存量上层系统相对无感. 也需要集团层面 自上而下 对齐规范 & 理念

@林帆：规则匹配永远是兜底手段。

@贺品嘉：有时候基于规则的解决方案可能效果更好。之前我们做日志解析，在很长一段时间内都发现，基于各种聚类、分类的算法，还没有基于3条简单规则的方法效果好。

@彭鑫：我看到业界日志数据一个很大的应用场景是基于正则表达式匹配形成指标数据然后告警。

@裴丹：我在AT&T做根因分析时，参照手册，手写了400多条cisco路由器日志模板，效果很好。

Question 4

主持人：您如何评价数据挖掘、深度学习、知识图谱等智能化技术在可观测性数据分析中所发挥的作用？智能化技术在当前的云原生软件系统运维实践中发挥了什么样的作用？

陈鹏飞：

我的个人理解是数据挖掘、深度学习、知识图谱等智能化技术不是目的，是我们刻画和理解运维过程中软件系统的行为的手段，理解了系统的运行规律才能发现和诊断故障，这才是我们的目的。而可观测性同样是我们解决故障的一种手段。只不过智能化技术可以理解为一种黑盒方法，在表象和根因之间建立非确定性模型，是在拿不到细粒度、深层次系统运行数据时做出的权衡；可观测性技术类似一种白盒方式，直接观察系统的内部行为，建立确定的从根因到表象的传播证据链。但是，因为可观测性仍然不成熟，没有办法或者没有必要实现完全的白盒分析，所以智能化技术仍然是必要的，而且要求会越来越高，因为简单的问题已经可以通过可观测性解决，留下的硬骨头问题需要智能化算法帮助解决。智能化技术在未来一段时间内在云原生系统运维中还将作为可观测性的重要补充，发挥不可替代的作用。

裴丹：

一方面，可观测性的数据是海量的、高速的、多模态的、价值极大的、但又信噪比极低的（即：对运维人员来说直接价值最高的异常数据在数量上远远小于正常数据）。目前看，人工智能算法是处理符合上述特点的数据的最有希望的方法。

另一方面，只有在这些数据被关联起来一起分析时才能发挥出它们最大的价值，而关联需要各类复杂的依赖关系知识（逻辑组件之间的调用关系图、流式组件对批式组件的依赖图，批处理依赖关系图，逻辑组件在物理组件上部署关系图、物理组件的网络路径关系图）和专家知识（组件内运维故障间的因果关系图），才能有物理意义地把各类运维信号关联起来进行有效分析。目前看，知识图谱技术是表征和应用这些用图表示的知识的最有希望的方法。由此可见，智能化技术在当前的云原生软件系统运维实践中势在必行。

智能化技术在当前的云原生软件系统运维实践中还有很长的路要走。当前主要在单个组件、系统整体层面的异常检测、基于异常检测的多实例系统“故障自愈”、软件变更检查、容量预测、故障预测等领域有成功实践；在基于多模态数据融合分析进行故障定位、根因分析、影响力分析等方面的效果还有很大提升空间。

贺品嘉：

目前智能化技术在可观测性数据分析中的作用是不可或缺的。该类技术对收集好的数据进行挖掘与学习，向人提供其学习到的知识（insights），节约人看数据的时间，是可观测性的核心之一，有广泛的应用。拿自动化日志分析举例，智能化技术在日志打点、日志压缩、日志解析、异常检测、问题识别等场景均有应用。我们的自动化日志分析框架LogPAI，就是Log analytics Powered by AI的意思，其中大量使用了各种智能化技术。

目前智能化技术在“理解过去”这件事上做得非常好。比如，通过计算当前故障日志与档案中故障日志的相似度，自动推荐可行的解决方案。在“预测未来”这件事上，还存在不少挑战。再拿异常检测举例，很多真实场景下，故障的数量非常少，可能一年只有几个，因此较难学习到异常日志的“模式”。而只学习正常日志的“模式”又往往会带来较多的误报。当前对未知异常的预测，仍是一个很有挑战性的课题。智能化技术也还有很长的路要走。

张圣林：

数据挖掘、深度学习、知识图谱等智能化技术极大地提高了可观测性数据分析的效率和准确性，这一点是毋庸置疑的。当前，随着云原生系统的规模变得越来越大，仅仅依赖人工方式去分析海量运维数据是不可行的，必须借助人工智能算法实现。

数据挖掘、深度学习、知识图谱等智能化技术实现了基于指标、日志、调用链等运维数据的故障检测、故障诊断、容量预测、智能调度等，提高了云原生系统应对故障，包括故障检测、故障根因定位等方面的能力，提升了系统的资源利用率。但是，我们也应该看到，基于智能化技术的可观测性技术还有很多挑战需要解决，比如故障样本少、噪音多、故障传播规律千变万化等，并不能解决所有的运维难题。

林庆维：

很赞成各位老师的看法。智能化技术在可观测性数据分析技术中非常关键。面对巨大的数据量，只靠人力分析、运维很难全面考虑，也过于依赖开发经验容易产生人力的单点依赖。而数据挖掘、深度学习能够更好的利用海量可观测性数据。软件分析以及知识图谱，能够帮助建立可观测性数据间关联，以及进一步建立和系统组件、用户间关联，在故障监测、诊断、恢复等等下游任务中可以发挥很大作用。这方面我们有不少的相关技术发表，同时也需要跟各位专家老师多多学习交流。

王含璋：

赞成各位老师。对于解决可观察性的Unknown Unknowns问题，这几类技术是必不可少的。比如从前几个dashboards看一眼就懂了，千万个dashboards就没眼看了。这里需要机器去帮或替我们去做，也必然会依赖于各种智能化技术。

可观察性是基于工程产品的工程领域并产出需要被人或机器使用分析并作出决策的海量多态的原始运维数据，那整个过程必然充满各种智能化技术的机会。比如最常见的基于时序数据做异常检测，降低TTD和节省人工成本。本质上，智能化技术在可观察性领域和在其它场景效果是类似的——理解数据从而提高效能。

凌志钧：

这块, 我比较赞同裴丹老师之前对于AIOps 15条建议中提及的点: 数据 知识 算法 + 代码 & 人机协同 会是个完整的拼图. 其中, 数据的质量/标准化 以及运维知识的构建会是和算法并重的部分, 而算法本身更多偏无监督 甚至于传统统计学的方法都会比较有效.

我们近期和彭老师实验室的同学也就如何结合动静链路做跨服务级别的根因分析探索, 主要往 基于因果关系图 & 谱分析两个思路探索，也期待其他老师分享更多的案例 给我们学习.

智能化技术在系统运维实践一些局部点 比如日志模版抽取, 时序分析 [异常检测]会有比较多的应用, 而且的确有较多落地的案例出来. 我们内部实践也印证类似的说法, 但整体看 纯算法类的还是偏单点突破 & 辅助的角色更多一些.

林帆：

我们的团队现在到了阿里云，云效这个产品主要是面向开发者的DevOps一站式协作平台，虽然也还在做数据相关的工作，但更偏向于代码和软件研发过程的效能数据。所以对于这个问题，我就只简单谈两点我的看法。

首先不论是是研发还是运维系统的数据分析，它在本质上都是会有离线建模+实时数据流处理两个基本步骤，用户评价这个系统的好坏，最终还是看分析结果的时效性、准确性和可解释性几个方面。

从这个角度来说，深度学习的可解释性问题会使得它在这类领域的数据分析上还不太适合作为实际生产系统主要的分析手段，但它可能是研究团队值得关注的方向，而基于图谱和策略的传统机器学习方法在眼下的可落地性会比较好。

第二点就是软件系统的可观测性数据分析是一个横跨软件生命周期的研究领域，我们在做数据分析的时候，可以不只局限于采集数据之后的环节，而且从数据产生的时候开始设计，对提供数据的源头系统提出规范和要求，可能能达到事半功倍的效果。

范超：

可观测性工具需要具备丰富完善的、实时的数据，不仅是单点散列的指标或是全链路的追踪数据，可能还需要结合上下文日志，以多维方式聚合，实现更友好的可视化，还包括复杂多样类型的数据处理和管理以实现更快的监测和响应目的，所以引入机器学习是必要的。尤其是告警的质量提升和基于告警触发的操作流程都需要持续的场景沉淀、事件积累、数据打标、模型训练。在日常实践中一些专项上可以发挥很好的效果，比如，入门可以从优化一项关联告警着手，或者一个人性化的报表视图，甚至是一个设计巧妙的数据分析策略，都会是不错的尝试。

蔡小刚：

可观测性解决了数据的完备性,但数据本身还是离散的。它需要元数据和AI来理解和洞察。

数据要成为数据资产，必须挖掘出其蕴含的业务价值。 这戏新技术都是数据分析的重要手段。比如我们在 日志的聚类分析中，从大量日志中提取通用的日志范式，从而快速诊断问题。聚类计算还用于告警风暴抑制和削减，以及调用链的故障分析。也借鉴了清华、港中文大学相关研究成果。在测试域，构建了测试域知识图谱，实现了测试更高的覆盖率，测试自动化率，已经智能化测试用例生成等。

有数据是最基础的一个环节，最好有高质量的数据，有完整的数据。但是数据是有代价的，尤其IoT世界。数据不能发挥价值，就是数据垃圾。在工程上，有成本 vs 价值 对可观测性的制约。

观点讨论

@彭鑫：@陈鹏飞的观点似乎是如果可观测性数据足够，简单的统计分析等方面可能就过了？

@陈鹏飞：我的理解是这样，不能直接传导的证据链就得靠算法”猜一猜“了。

@张圣林：那看来可观测性是革了“AIOps”的命了。

@陈鹏飞：这个我觉得也不是，因为也许不存在彻底的可观测性。

@彭鑫：@张圣林，其实还好，智能化是个大框子，帮助人做一点数据筛选和可视化也可以说是一种智能。

@张圣林：嗯嗯。也是。能把数据采集起来，汇总下，稍作分析，也是智能化的开始。很多工业物联网领域的运维数据连采集都没有做好。更别说汇总、分析了。

@王含璋：同意，我觉得可观测性是个愿景，微观和宏观上都没有尽头。

@裴丹：哈哈，我觉得恰恰相反。 我们说，AI是任何模拟人类行为的计算机技术。AIOps是什么？就是任何模拟运维人员行为的计算机技术，它可以基于专家知识、经验、自动化、机器学习、深度学习或它们的某种组合。从另一个角度说，不要因为用到了自动化或硬逻辑，就判定其不是AI 或AIOps。可观测性让AIOps更能发挥作用。

@彭鑫：嗯，没有可观测性数据，AIOps可能就是无源之水了。

@林庆维：可观测性让AIOps更能发挥作用，同时，AIOps也让可观测性有着更大的用武之地，两者相互推进。

@吴文胜：把操作系统纳入考虑，再来看可观测性问题，如何？

@吴文胜：能不能把可观测性机制，埋入到操作系统中去，开发新一代的可观测的操作系统？

@陈鹏飞：这个刚才提到了，可以实现基于eBPF的指标、调用链、日志的统一监控，而且是去侵入性、跨语言。

@陈鹏飞：做过在操作系统内核做过一个原型，完全用eBPF收集指标、日志，并且实现。trace的能力，会有一些性能损耗，但是基本可以实现与编程语言的解耦。

@彭鑫：@蔡小刚，在测试域，构建了测试域知识图谱，实现了测试更高的覆盖率，测试自动化率，已经智能化测试用例生成等：能否简单说下目前你们测试与运维在这方面的关系是什么样的？

@蔡小刚：测试是DevOps的一环，Ops是DevOps的一环。目前的可观测性，是把dev深度卷进ops领域了。所以大家貌似都在一个战壕中了，不是一个人在战斗。

Question 5

主持人：您认为基于可观测性的智能化运维未来的发展前景如何？有哪些值得学术界和工业界探索的发展方向？您对相关领域的学术界研究者或工业界实践者有什么建议？

裴丹：

如前所述，基于可观测性的智能化运维是大势所趋。智能化运维是任何模拟运维人员行为的计算机技术，它可以基于专家知识、经验、自动化、机器学习、深度学习或它们的某种组合。

从架构角度而言，一个AIOps系统是以运维监控数据和运维领域知识为输入的、算法和代码联动的、人机协同的分布式系统。其每个组件都有其提供的服务（确定性的或模糊性的），而其整体上模拟运维人员的行为，即在智能运维领域践行“知识+数据+算法+算力”的AI 3.0理念。

对相关领域的学术界研究者或工业界实践者的技术层面的重点建议和值得探索的方向包括：（1）数据知识双轮驱动，用知识关联数据；（2）人机协同 （主动学习、用户在线反馈作为系统设计的一部分）；（3）细分融合（细分场景专属技术；集成学习融合多种场景专属技术构成通用技术）；（4）精准建模（如：根因分析系统应该建模为一个排序问题还是分类问题）。

其中社群层面的重点建议包括：（1）标准引领（建立行业、国家标准）；（2）数据治理和AIOps应用齐头并进；（3）社群中产学研用多方合作。

更多建议详见我之前发表在“智能运维前沿”公众号上的文章：“AIOps落地的15条原则”。

陈鹏飞：

我个人的一点建议：从当前的云原生系统智能运维需求以及发展现状来看，可观测性的智能运维在未来几年内还将保持持续的发展热度。我个人觉得值得探索的方向包括：（1）是从运维数据融合的角度，真正实现多模态数据如日志、指标、调用链的关联，如利用OpenTelemetry实现统一；（2）实现云原生的可观测性，将日志、指标、调用链全部下沉到基础设施，做到跟用户、跟应用、跟编程语言的解耦，eBPF或许是一条解决之道；（3）多模态数据融合的智能运维算法，对多模态数据形成统一的表达，类似于编程语言中的IR中间表达；（4）产生和积累质量良好的故障案例数据；（5）形成主动反馈的机制，连续学习模型。

张圣林：

基于可观测性的智能化运维将是未来运维的主流模式。在软件系统设计之初，就考虑要收集哪些可观测性数据，而不是采用“事后诸葛亮”的方式。需要确定可观测性数据的粒度和层次，以便于软件系统部署后可以在对应的粒度和层次上检测故障、定位根因。此外，要做好可观测性数据模式变化的解释，每一个日志模板、每一个调用链的错误类型、指标的上涨或下跌，最好从开发者的角度给出解释，方便运维人员快速理解可观测数据模式变化的含义。结合基于智能化技术的运维数据分析，可以显著提升故障处置的效率。

基于可观测性的智能化运维方兴未艾，需要学术界研究者和工业界实践者的通力合作，才能够解决一个又一个挑战。

贺品嘉：

我觉得这个方向包含非常多的具体场景、存在较多未规范的问题定义、涉及多个方向的技术（软件工程、网络、机器学习、人机交互与可视化等），因此有很大的发展空间。我个人对以下三个方向很感兴趣：

（1）多维数据融合/筛选。如何把不同数据类型（metrics、logs、traces）、以及不同抽象层次的数据（容器数据、应用数据、用户数据、运维数据）统一考量，或者选重要的进行考量。

（2）新型日志实践与规范。如何以可观测性的智能化运维为目标设计写日志（logging）的新型实践与规范。

（3）软件数据的可视化与人机交互。如何针对云原生系统软件数据设计可视化与交互方案。

我有一点感受，这个方向的软件和数据开源比较难，但很重要。相关数据在公司里多是敏感数据，不便开源。因此，学界在研究时往往受限于数据集和单一的问题定义，只能在特定数据集和问题上做出成果。而由于工业界真实场景千差万别，这类研究在应用到实际中时往往需要比较大的调整。比如基于日志的异常检测这个问题，常用数据集大多收集于10年以前，且数据集本身包含的异常类型有限。在这个数据集上表现好的一些深度学习方法，在实际中可能比不过10年前提出的传统方法。这是数据集的局限导致的。此外，异常 的定义也比较模糊，每个业务场景中的“异常”不尽相同。直接套用学界的算法不一定能得到比较好的结果。因此，我们若能提供开源代码与脱敏数据集，加强学界业界的合作，对这个方向的发展会有比较大的帮助。

林庆维：

对于目前云原生和云基础设施这样的复杂体系，基于可观测性的智能运维是最为看好的技术趋势。一方面是由于复杂体系/系统的规模效应，传统上几倍的软件复杂性增长和用户数增长还可以靠增加人力来解决，但是几十倍甚至百倍的软件复杂性，叠加上急速的用户数增长使得依靠人力的方式越来越难以为继，必须要更自动化、更智能化的方式运维。另一方面，当前越来越严格的数据隐私要求催生了sovereign cloud/region的增加，在这些隐私性要求极高的隔离环境下，产品的开发者无法直接访问运维数据，而同时，部署的部门无法找到大量熟悉产品的运维人员，其核心出路只能是依靠智能运维。一些技术如目前的实体挖掘、知识图谱技术初步展示了其在软件系统中的作用，未来可以在复杂系统中进一步研究、探索和应用。

建议方面，我是很希望看到学界研究者和工业界实践者，更多的结合软件、系统和AI，对可观测的智能化运维进行综合分析。专注实际系统中的痛点问题，做落地的研究和工具。这需要学术界和工业界的共同努力。

王含璋：

建议分享：

（1）可观测性+智能运维是领域跨度很广的方向，很难有人什么都会都懂。建议算法和开发能多和运维同事们密切合作 - 开发造弓，算法制箭，运维找鸟。也希望我们也能在彭老师的群里多交流学习！

（2）尽量避免过量开发/研究，尽早在实际的场景/数据中快速迭代能更快产出实际价值，也及时调整科研方向和策略。很多美好的策略，落地不好使，或者不scalable。

（3）生产环境和模拟环境，实际故障和注入故障有本质区别，建议老师同学们能多找机会基于各种业界的实际工程系统做科研。

（4）阶段性的ML演进，我们的根因推荐系统就是从一个“专家系统”和框架开始的，才能有了后来的不断地数据收集和验证，去年和裴老师和文潇同学合作产出了不错的模型。有时候产品和数据像是鸡和蛋 - 总要先做出来一个才能迭代。

未来可期。前面提到围绕单/多时序数据的异常检测技术的落地，就成功使很多公司降低了很多场景下的TTD，为运维人员带来非常实际的效能提升。更多可观察性数据的实际场景还是相对手动的或基础的。在高ATB和高效能的需求驱动下，一定会有更多优秀的研究和产品诞生。探索方向建议推荐围绕“在线高可用”（如异常检测和根因定位）或“离线高质量”（如服务架构异常，性能异常）。直接impact来看高可用角度更热，但高质量角度未开发的机会更多。

凌志钧：

在目前整个行业业务相对走稳,大家更多关注研发效能 & 降本增效的话题下, 我觉得基于可观测性的智能化运维业务需求和价值都很大, 而且也会越来越重要.

关于建议：（1）制定标准规划 包括对应的数据集, 有助于各方在同一个上下文下做进一步的对比和交流。（2）话题上可以更为广泛一些 AIOps之前提到的 质量、性能、成本、效率等. 我个人觉得 性能 和 成本的话题也有很多可以探索的部分. 另外在微服务的链路治理/服务画像 等话题上, 学术界也可以有所关注。（3）套件化: 在仿真模拟 [样本库构建] & 基础算法库共享 & 标准数据集合访问 & 运维知识抽象 & 数据标准 等方向, 整体可观测性研发套件相对也比较稀缺. 所以导致整体研究时, 很多时间都在关注核心算法/问题以外的配套设施准备/构建上。

林帆：

我目前考虑的更多是数据源头质量的问题，如果数据源质量足够高，后期分析就会变得简单，效果也会好得多。比如根据代码中的关键行为，比如与外部系统的交互，来提供需要补充日志输出的位置，甚至结合一定的规范，把这个日志给他自动生成出来。或者根据服务的运行时行为，比如根据调用链路的模式事先抽象成指标，在遇到问题的时候就可以直接基于指标做判定而不用去临时分析全部链路等等。

当然也期待运维系统上能有更多的新算法和模型被设计出来，共同把可观测性和AIOps落地下来。

蔡小刚：

可观测性+AIOps， 会促进AIOps的成熟和落地。 前景非常看好。具体来讲，发展方向很多，比如底层： ePBF， 结合微服务runtime框架的可观测性新技术。

上层：主要是基于海量数据的智能分析技术， 这方面之前我们主要和国内外的一些高校、初创公司有常态化的合作研究。比较看好知识图谱、可解释性的AI在运维域的技术研究；长远大目标是构建运维大脑，对应的智能化程度，可以参照智能汽车领域的L0~L5分级模式。希望运维大脑尽早帮助从业人员减少加班时间哈。

对学术界，希望能有机会和有想法有兴趣的老师多合作，一方面是针对我们在工业界中碰到的世界难题；另一方面是结合老师的研究方向，我们帮助在云边端各种场景中去寻找工程落地。 这样就能把老师的原创研究和我们的工程化能力结合起来，实现强强联合，可以做到比以往更高效的合作研究模式。短的合作项目可以是一年，也可以是2~3年的中长期研究项目。对同行，我们秉持开放、包容和分享的原则，支持和推动社区的活动，众人拾柴火焰高，大家一起推动新技术的研究、推广，以及相关规范、标准的制定。

范超：

技术趋向是必然的，过程也会较长，不同系统生态都会逐渐摸索适合自己的解决方案。如果说建议的话，其实，有些时候我会更倾向个别精于实践的传统行业去学习，他们从部分角度看可能已经探索在前沿了，方式方法上也很先进，甚至是更加严谨，比如一线城市的路网调系统、机场运行指挥中心。这些在线的系统也很有意思，感兴趣的话可以找资料研究。

观点讨论

@董震：初识可观性，读了些文章，发现存在两个不同的概念（个人理解）：

（1）【控制论定义】可观测性是系统的属性，如果能够基于其观测数据和领域知识很好推断出系统内部行为，就是该系统的可观测性好。

（2）【谷歌的定义】可观测性是可帮助团队有效调试其系统的工具或技术解决方案，如果该方案能够准确报告系统的状态、异常等，并且误报比较低，那么该方案性能比较好（https://cloud.google.com/architecture/devops/devops-measurement-monitoring-and-observability）

很多文章根据不同的上下文使用不同的定义，自由切换以上两个定义，很是困惑。

请教各位专家，我们该如何理解可观测性的概念。

@凌志钧：上下文是个比较容易出问题的点 比如在业务 到应用 到runtime 到容器到物理层上 定义的标签命名需要统一. 另外 单一的指标名是不具有业务含义的, 只有类似每个服务平均的流量 才是有真正业务含义的measurement 需要业务表达和底层数据访问解耦。

@王含璋：我理解，谷歌的是在运维工具这一维度的落地版定义，而控制论版的像是泛化抽象版，不冲突。

@裴丹：我的个人理解是 两者兼而有之：  当我们说一个系统“可观测”，是指其内外部行为可以基于其观测数据和领域知识给出合理解释。而可观测性是指： a)一个系统可观测的程度；及b)以及为了提升其可观测的程度，在开发、测试、运维（DevTestOps)中所做的设计、实现、及各类技术。

@贺品嘉：我觉得其实两个都对，很多工具或技术解决方案依赖于系统本身。为了更好的使用这些工具或方案，我们有时也会修改系统。确实目前还没有一个统一的定义，不同的服务提供商经常根据各自所能提供的服务，提供自己的可观测性定义。

@彭鑫：我来问一个问题，我在一些企业看到被称为“快排工具箱”的工具集，里面是运维工程师们提供的各种问题快速排查的小工具，我的理解是这些小工具体现了专家们对于某一类特定问题的排查经验。这方面积累如果多的话，是不是也可以形成一种智能化手段，当然需要进一步整合。

@林庆维：是的，所以也有不少专家学者一直在研究如何将domain knowledge跟模型（或者其他基于数据分析手段）深度融合的方法。

@凌志钧：我个人理解 是个不错的辅助手段, 我们目前的观测手段 都偏集中式 & 运行时被动采集. 很多 “快排工具箱”都是主动 而且 单点视角 会是个不错的补充。

@陈鹏飞：是的，有些场景可能很有效。之前经常看的Neflix的以为专家Gregg就是喜欢搞这种“小工具箱”，她觉得很有用。

@彭鑫：就像有些有经验的警察有自己独特的破案思路，按照某个特定的顺序或方式把相关信息整合分析一下，可能就很快发现线索和嫌疑人。快排工具箱有点像这种做法。

@林庆维：基于经验和领域知识的系统确实是很关键，也很实用的。同样，基于可观测数据分析，或者由模型从大量历史数据学到的知识，也很重要。两者相互补充和增强，能使运维过程更上一层楼。

@张圣林：我也觉得，一些重大的运维决策，比如变更回滚，设备替换，还是得有运维人员的实际参与。仅仅依赖算法的结果，未必可信。

@裴丹：可以用知识图谱的一个分支“事件图谱”来刻画这些领域知识。

@彭鑫：另外，大家如何看到现在运维数据的高效访问和分析问题？

@彭鑫：一些大企业现在运维数据量太大，拉取一点数据可能要很久，动不动还可能限流。因此采样技术可能很重要，因为保存的很多数据不见得有用。另外，基于学习的方法在工业界大规模系统上可能效率还是个问题，不仅包括时间和资源开销也包括上线后的概念漂移问题。

@张圣林：数据模式的概念漂移的确是个大问题。一旦出现概念漂移，此前训练好的模型就不再适用了。

@凌志钧：这块我们投入很大 从三四年前就开始重点建设

一方面 都构建比较强大的时序数据库 [包括分层 冷热存存储 以及不同的TTL 和时序精度]

（1）加强数据治理 [本质上时序是个写多读少的服务]

（2）埋点面向预聚合/计算友好

（3）提供离线数仓报表能力 降低在线查询的诉求

@林庆维：是的。所以我们也经常提到在AIOps领域需要关注整个生命周期各个环节的每一个步骤的提升，而不仅仅是模型。比如数据的生成，传输和存储过程，采样过程，本地和分布式计算，数据摘要，索引和查询优化，也包括模型效率提升等，这些都是很需要关注和提升的问题。

@张晨曦：我有一个问题想请教下各位专家，知识图谱在很多领域已经发挥了很大的作用，但智能运维领域知识图谱好像应用还不是很多，包括图谱的构建也还不是很清晰，这方面各位专家有没有什么展望？

@裴丹：运维数据被关联起来一起分析时才能发挥出它们最大的价值，而关联需要各类复杂的依赖关系知识（逻辑组件之间的调用关系图、流式组件对批式组件的依赖图，批处理依赖关系图，逻辑组件在物理组件上部署关系图、物理组件的网络路径关系图）和专家知识（组件内运维故障间的因果关系图），才能有物理意义地把各类运维信号关联起来进行有效分析。运维知识图谱是一种“领域知识图谱”，需要自己的构建和表征方法，传统“通用知识图谱”的很难直接拿过来套用。

@彭鑫：图结构表示对于智能化运维分析肯定很有用。但如果叫知识图谱可能要先明确其中的概念是什么。一般的通用或行业知识图谱中概念都很丰富，而智能化运维中的概念似乎比较有限？

@凌志钧：这块 我比较期待的是逻辑的排障知识图谱能跨层描述 各层的核心SLI & 报警点 再扩展对应的内因measurement + 日志 /链路的探索分析. 但可能不是传统的知识图谱的范畴

@王含璋：标准拓扑的图是相对好利用的。根因这块，遇到的挑战是基于“事件”的图谱的“下沉”等级很难定义，故障类型的各类可学习/分析特征也很难统一归纳。

@彭鑫：运维知识图谱应该概念性没那么强，很大一部分内容是服务调用图、服务部署图等图状表示的一种统一。

@陈鹏飞：知识图谱在智能运维领域用的不多，确实有些挑战，一个是知识图谱的构建，没有标准的CMDB、元数据管理机制、高质量的运维数据以及专家经验，很难形成有效的知识图谱；另外就是跨场景或者跨系统的挑战，难以通用；再就是系统的动态性比较大，刚建好的也许就不能用了。但是，我也相信随着“因果学习”、软件标准化、运维数据的丰富，知识图谱还会有更大的发展。

@林庆维：同意，而且在实际系统中，这种图谱经常是动态的，它需要随着系统的演化在不断更新。

@裴丹：对，图谱要想用起来，必须是动态构建、动态更新的。

@王峰：大型运维活动涉及的知识面非常广，那些复杂的中间件配置优化知识，网络知识，软件架构知识，及历史案例中吸取的经验教训，目前还没有一种好的方式收集与有效组织起这样的知识图谱（运维专家值钱就在此）。目前IT系统管理的是流程及流程中的事件活动还有运维对象相关的状态属性。

访谈结束

CodeWisdom

一个有知识的软工公众号

发现智能化编程之道