IT系统为什么需要可观测性

本文为云杉网络原力释放 - 云原生可观测性分享会第一期直播实录。回看链接，PPT 下载。

大家好，我叫亓亚烜，云杉网络创始人和 CEO，非常荣幸能够参与云杉的首次直播活动，跟大家分享自己对可观测性的一些认知。

可观测性是监控领域非常火的技术，尤其是面对云原生场景，可观测性几乎成了 IT 系统必备的能力。我的很多朋友、客户、合作伙伴、投资人，当然也包括诸位，都对可观测性的发展充满了好奇与期待。

今晚，我分享的主题是“IT 系统为什么需要可观测性？”，我希望自己能够从价值、技术等多个层面，回答好这个问题，阐明自己的独立思考。当然更希望与诸位听众能一起互动交流，共同探讨可观测性的发展趋势。

我分享的议题包括可观测性的五个方面。我会直入主题，先把结论告诉大家。

首先，为什么需要可观测性？答案是”赋能“。可观测性的根本价值，是给 IT 人员赋能。让工程师、架构师、乃至 CTO、CIO 能够随技术进步而进步。

关于如何理解可观测性，我总结了几位业界大神的定义，他们的观点非常有参考价值。同时我也根据自己的分析和理解，提出了独立的见解，可观测性即白盒监控。

如果不能评估他，你就不能改进他。可观测性的评估至为重要，基于白盒监控的理解，我给出了三类可观测性评估判据，以此帮助大家选择合理的可观测性技术。

关于如何构建可观测性，无外乎三种方式：SaaS 服务、开源开发、集成产品，这三种方式对大多数企业都非常重要，SaaS 满足快速体验，开源满足业务需求，集成满足行业合规。

最后，关于如何使用可观测性，我会分享多个行业的十多个实战用例。着重讲智能汽车和股份制银行两个用例，并简要分享十个其他行业案例，以此增强大家对可观测性的认知。

0x0：为什么需要可观测性？

May the force be with you. 云杉内部的研发团队经常引用“the force”，即原力，来描述可观测性的作用。可观测性无论对工程师、架构师还是技术主管都是一种赋能。

为什么需要可观测性

对工程师而言，可观测性能够让大家抓住技术趋势，深入理解云原生技术和分布式系统。让开发工程师理解基础设施，让系统和网络工程师理解应用。云原生时代，全栈能力是一个工程师自我修养的重要部分，当然也是大家未来职业道路中升职加薪的保证。

对于架构师而言，通常面临的挑战是如何让 IT 系统能够支撑业务量以十倍速增长。这样的增速，不采用云原生等新技术是无法实现的。然而，技术创新的背后是巨大的风险，可观测性为新技术的采用奠定了坚实基础。一方面通过监控自服务，大大加快新业务的开发测试速度，另一方面通过全栈链路追踪，保障业务上生产之后的稳定运行。

对于 CTO 等技术领袖而言，组织能力的提高极为重要。公司数字化业务虽在快速增长，但 IT 团队组织架构，人力资源等却难有大的变化。因此，需要借助可观测性建立“数据即事实”的团队协作原则，以此消除部门之间的协作壁垒，有效提升组织的协同作战能力。

说到这里，解释下可观测性为何可以比做“原力”。

可观测性的数据，本就存在，只是散布在各个部门。而可观测性平台的建立，就是数据的汇聚，可以认为是从各个部门收集到了原力。

可观测性服务，则是通过汇聚的数据去反哺各个部门，即形成能够控制的“原力”，成为 yoda 老师那样的绝地武士。

0x1：如何理解可观测性？

可观测性有很多种不同的定义，最广为流传的是三大支柱说。三大支柱即 metrics、tracing、logging。三大支柱说广为流传的原因，在于他最容易被工程师理解并接受。然而，三大支柱的提出者，Peter Bourgon 的原意恐怕不是所有人都真正理解。

Peter Bourgon 非常务实的指出，讨论可观测性，需要明确讨论对象，对不同的数据类型应该有不同的优化处理方法。注意，Peter Bourgon 原意并不是说可观测性就是三大支柱，而是让大家具体问题具体分析。即便是 Metrics，在不同场景下也有不同的含义和处理方法。

Google Dapper（谷歌的分布式追踪系统）作者 Ben Sigelman 更是直言，metrics、tracing、logging 只是三种数据类型。言外之意，还是具体问题要具体分析。Google Dapper 的论文，大家多少应该去了解一下。看看 google 是如何通过零侵扰、轻量级的追踪技术，帮助团队调试和诊断分布式应用的。

因此，三大支柱说的合理解读，应当是可观测性需要多类数据类型，每类数据也要在不同场景下选择不同的处理方法。希望大家能够记住这点。如果将来看到把可观测性等同于三类数据结构的兄弟，最好建议他去读读 Peter Bourgon 的 Blog 原文。

Charity Majors 是我非常尊重的一位创始人，她是连续创业者，也在 Facebook 工作过，近几年创立了 Honeycomb 公司，专注可观测性。她提出了一个非常独到的看法，即可观测性是用来解释“unknown-unknown“问题的，这个说法听起来似乎有点儿玄而又玄的感觉。

我跟大家解读下：unknown-unknown 可以简单理解为探索未知问题。

软件工程中，有一套完整的 debug 工具，帮助开发人员发现软件中的未知问题。分布式系统监控中，可观测性扮演了类似 debug 工具的角色，通过交互式的追踪，定位未知问题。这里请大家注意，探索未知的说法，其实是 Charity Majors 借用了软件工程的理论来做可观测性。这样的思路，跟 Google SRE 的思路完全一致。

在 Google SRE book 的第十二章中，明确说到了，可观测性的目的就是：快速排障。由此可见，软件工程是可观测性绕不过去的门槛。要想唤醒大家对软件工程的记忆，不妨重读下《人月神话》，必然会有新的体会。

比起这位老哥（鲁道夫卡尔曼），Peter、Ben、Charity 再牛，也只能算是三体文明，而这位是真正的神级文明，因为他发明定律。鲁道夫卡尔曼，现代控制理论之父，他提出了系统的可观测性理论，并且基于这个理论，把人类送上了月球。

那么，在神级文明的定义下，可观测性是什么呢？以下定义均来自维基百科。首先，控制理论中的可观测性是指：系统可以由其外部输出推断其内部状态的程度。其次，一系统具有可观测性当且仅当：针对所有的状态向量及控制向量，都可以在有限时间内，只根据输出信号来识别目前的状态。

这样定义非常抽象，但我可以帮大家划重点：首先是外部输出，其次是内部状态，最后是有限时间。

比如新冠核酸检测：外部输出是被棉签捅着的东西。内部状态是肺部是否被冠状病毒感染，有限时间是 3~8 个小时。如果不是外部输出，那就意味着需要抽血或者开刀；如果不是内部状态，那就无法进行分诊治疗；如果不是有限时间，那要么疫情泛滥，要么没法出行。

理解了这三个重点在防疫中的含义，下面就可以讲讲他们在 IT 系统中的解读。

现代控制理论，用状态空间来描述系统，通过可观测性和可控性解决复杂系统的控制问题。借用控制理论中可观测性理论，引出我对 IT 系统可观测性的认知。

首先，状态空间代表白盒监控，即对系统内部状态要有清晰的理解，否则难以实现复杂应用的诊断。其次，外部输出意味着对系统应是零侵扰的，尤其是对业务是零侵扰的，否则干扰系统运行，无法实现控制目的。再次，内部状态一定是多维度的，对 IT 系统而言，就是我们常说的全栈，包括应用、系统、网络及各类中间件。

最后，有限时间意味着实时性，从开发测试角度而言，调试速度应该是分钟级的，从生产保障而言，故障响应速度至少也是分钟级的。因此，要支持分钟级的工作流，可观测性平台的响应速度必须是秒级的。

基于上述分析，我也提出自己对可观测性的理解。简单而言，可观测性就是为复杂 IT 系统寻求白盒监控能力。IT 系统的可观测性应具备零侵扰、多维度、实时性等关键特性。以上便是我对可观测性的理解。如有不准确的地方，希望与大家讨论学习。

要做真正的技术创新，必须有独立的观点。舶来品虽好，但难得其真谛。我希望国内做可观测性的朋友们，能够多多交流，迸发出更多更深入的理解。后面，我将基于上述理解，进一步阐明可观测性的技术和价值。

0x2：如何评估可观测性？

去年 12 月跟某保险公司的 IT 架构部门交流，谈到传统 APM 要给应用插码，腾讯会议对面的一个小姑娘突然跳出来说：“你们咋打桩？”。当时我就非常吃惊，原来插码这种工作，已经上升到了“打桩”的难度。但“打桩”，为何要小姑娘来做？

另一个真实的 case，去年 10 月给某股份制银行做 POC 汇报，观测到对方普罗米修斯服务响应时间超过 30s，客户说，“这个正常”。

让 985 毕业的小姑娘去打桩？让每一次检索数据消耗写一行新代码的时间？这不是新一代 IT 人该有的样子，残酷的现状需要改变。

可观测性，必须要解决以下问题：

1. 在数百个服务中发现瓶颈：提供非采样，秒级精度，提供 HTTP/DNS/GRPC 等性能指标数据
2. 在数千个访问中追踪应用：提供应用层 Trace 追踪数据，网络层 Flow 追踪数据
3. 在数万个容器中定位根因：提供全栈（API、主机、基础设施）端到端指标数据、日志数据

注意，解决上述问题，还需要零侵扰和实时性。

关于零侵扰判据：

传统 APM/NPM 等工具，要么需要应用程序中打桩插码，要么需要基础设施中分光镜像，均会对 IT 系统进行侵扰。

可观测性要求使用外部数据做分析，因此需要采用零侵扰的方式获取监控数据。不需要打桩插码、分光镜像，而是通过开放系统架构直接获取监控数据。零侵扰的另一方面是要求低功耗，不能因为采集数据而影响应用或基础设施性能，例如，通常采集点功耗不能超过业务功耗的 1%。

关于多维度判据：

要保障云原生应用稳定运行，可观测性必须包含多维度数据分析能力。具体来说，要将应用的 API、容器、主机、网络等监控数据进行全栈关联分析。传统的 APM 工具，可以定位代码层问题，却无法追踪容器或主机网络服务引起的故障。而传统的 NPM 工具，又不能关联应用的 TraceID 从而追踪穿越 NAT、LB 等网元的流量。因此，多维度的全栈数据分析，是可观测性的第二个需求。

关于实时性判据：

自动控制中，过大的传感器反馈时延，会导致系统震荡而不可控。与之类似，云原生应用的动态性要求可观测性平台必须具备实时性。如果应用的升级/扩容在分钟级完成，那么监控系统就必须提供秒级的反馈能力。注意，这里的反馈需要对海量指标/追踪/日志数据进行查找分析，因此对可观测性平台的海量数据实时处理能力提出了极高要求。

再回到原力的类比，如果没有零侵扰，可观测性平台，也就是原力收集平台，无法被大家接受。如果没有多维度，原力无法关联，自然失去了其意义。如果没有实时性，原力无法有效释放，被大家掌控。人的感知时间是秒级别的，因此实时性必须做到秒级。

有了上述判据，就可以定量评估可观测性技术了。

为了说明可观测性的技术评估，我这里依据自家产品，聚焦到两个核心技术趋势之上：eBPF 和 OLAP。eBPF 解决了零侵扰，以及部分多维度问题。

如何评估可观测性

如上图所示，左图中是一个接近全栈的多维度监控对象，其实就是一台服务器。可以看出，自下而上有，主机 HOST 系统，HOST 的网络协议栈，虚机 VM 系统，虚机网络协议栈，容器 POD，进程容器、Sidecar 容器、应用进程等等。

传统 APM，通过“打桩”，也就是插码，或者 java agent 的方式，能够对应用进程进行监控，即使扩展，也只能监控到部分 sidecar。传统 NPM，通过对设备的分光镜像流量，可以监控主机出入的流量，扩展后可以监控主机上虚拟交换机流量。

云杉 DeepFlow v5.0 产品，在 NPM 基础上，利用 classic BPF 技术，通过 host 的用户态（零侵扰）监控到主机及虚机的系统和网卡流量。DeepFlow v6.0 产品，利用 eBPF 技术，进一步在零侵扰的前提下获取了应用和 sidecar 的信息，扩展了多维度的能力。

做分析，离不开 OLAP。可观测性的工程师，自然就是数据分析的工程师，OLAP 能力不可缺失。过去三年时间，云杉 DeepFlow 产品中的关键数据组件，经历了两次重要的升级。

2018 年使用 ES 作为主要引擎，读写速度无法满足实时性要求，只能为数百台规模的业务集群实施可观测性。2020 年初，DeepFlow v5.5 发布，融入了深度优化的 InfluxDB 作为 Metrics 引擎，使平台性能提升 10 倍，可以解决数千台服务器集群的可观测性。

2021 年 12 月，DeepFlow v6.0 的第一个版本发布，进一步融入了深度优化的 ClickHouse 作为观测数据的 OLAP，读写性能再提升 10 倍，满足金融及互联网客户的数万规模的集群部署。

如果说摩尔定律是芯片演进的金科玉律，每 18 个月芯片效能增长 2x。那么云时代的可观测性也不难预测：即每 18 个月观测数据读写速率增长 10x。关于可观测性的概念和技术，讨论到此为止。

然而，纸上得来终觉浅。可观测性实战要真正落地，大家又面临哪些问题呢？

既然可观测性是一种原力，而原力的掌控能力是一种增长的过程，那么我这里就借亚马逊的飞轮模型，来说明如何增长可观测性。

增长的第一步是理解和体验，体验可观测性的最佳方式当属各类 SaaS 服务，这些可观测性的 SaaS 服务可以让大家快速理解可观测性的价值。

增长的第二步是加速业务创新，也就是要满足业务部门的快速发展需求。开源是技术团队应对快速创新的最佳路径。因此，如何用开源技术构建可观测性平台是增长飞轮的第二步。

增长的第三步是满足生产需求，创新一旦完成，就要面临合规性、稳定性、安全性等一系列挑战，集成能力之于可观测性，就是赋能本身，让业务团队、基础设施团队、安全团队都能有效运转起来。

由于技术的不断进步，可观测性的飞轮将往复运行。K8S 的体验之后，是 Serverless，Prometheus 之后是 Skywalking，APM 的作战半径不到 20%，全链路成为永远的梦想？可观测性的增长飞轮，将引领大家解决上述问题。

0x3：如何构建可观测性？

构建可观测性的第一种方法，也是最快捷高效的方法，就是使用 SaaS 服务。目前，云厂商独立第三方企业均提供可观测性的 SaaS 服务。云厂商，比如阿里云，提供了 ARMS 应用实时监控服务，近期推出的 K8S 监控服务大家可以去体验一下，代表了可观测性的发展趋势。阿里云上还有一个更基础的可观测性服务，就是 SLS 日志服务，用户可以将自己采集的观测数据存入 SLS 服务中，并按需使用。

相比而言，ARMS 提供的是一站式服务，而 SLS 则给予了更多的自由度。国内的腾讯云、华为云等，也都提供了可观测性服务。如果是 AWS、Azure 的客户，那么可以直接使用 Datadog，这个 500 亿美金市值的公司，可以看做是可观测性的领军企业，而且主要以提供 SaaS 服务为主。

国内的第三方提供商，目前看到的有观测云、乘云等，云杉也提供名为 DeepFlow Cloud 的 SaaS 产品，方便大家体验。

SaaS 服务的主要问题，是用户的应用大概率需要跑在公有云上，并且观测数据要由第三方管理。此外，SaaS 的计费模式相当复杂，有按主机规模计算的部分，也有按数据量计算的部分，总之很难准确规划这方面的预算。

因此，对于中小企业 SaaS 是首选，但对于中大型客户，尤其是采用混合云架构，合规性要求高，项目预算制的大型行业客户来说，很难仅仅依赖 SaaS 提供可观测性服务。

因此，才有了飞轮中的另外两种构建模式，开源和集成。

这个时代，整个 IT 系统都是构建在开源之上的，可观测性也不例外。依托开源技术构建可观测性平台，是快速技术创新的必由之路。

如何构建可观测性

如图所示，自底向上构建基于开源的可观测性平台，可供选择的开源组件非常丰富。采集层，要实现零侵扰采集，可以采用 K8S 的 daemonset 采集器，java agent，普罗米修斯的部分 exporter 等等。

采集层要注意的是，云原生体系下，监控数据要遵循开放标准，这样整套系统框架才能不断演进，扩展。采集层的开放标准主要是 statsd 和 opentelemetry，尤其是 opentelemetry，大有一统江湖的趋势。

采集层之上是数据层，之所以是数据而不是存储层，是因为要满足实时性要求，读存写必须分离。本质上数据层就是一个实时数仓，要针对应用场景，进行深度的读存写优化。实时数仓方面对技术要求较高，可以跟有经验的团队或厂商一起开发。

数据层之上，是展示层。指标、追踪、日志、告警，分别由 grafana、skywalking、kibana、prometheus 等常用组件支持。让这些开源项目支持更多种类的数据展示，同时为不同部门提供不同场景的 APP、WEB、CLI、API，是可观测性平台团队的主要工作。

下面我们来看一个我们的客户，是如何改造 Grafana，为微服务提供可观测性的。

客户的开发团队，要求对每一个微服务提供精细的指标监控，包括 HTTP、DNS 的 RED 指标，即用量、错误、时延指标，也同时要求 TCP 和网络层的各类指标，形成全栈链路监控能力。客户的业务团队还要求把每个微服务的全局调用关系实时展示出来，这些工作都是客户的平台团队基于 Grafana 二次开发完成的。

如何构建可观测性

如图所示，虽然每一个展示的子视图，大多是 Grafana 自带的，但视图中的数据，都不是开源的 telegraph 可以直接获取到的。

事实上，客户在数据层与采集层与云杉团队合作，解决了上述数据的零侵扰采集和实时读存写问题，客户团队更多专注于 Grafana 的二次开发，快速满足业务需求。由此可见，开源项目并不是拿来就能用的，而是需要依据业务需求进行快速开发。如果把时间花在改进开源项目的性能上，那应该由专业团队来做，并依据开源协议为社区做出贡献。

第三种构建可观测性的方式就是集成，integration。集成听起来没有 SaaS 和开源性感，但我认为，集成的难度最大，因为集成的约束条件太多。这些约束条件包括，理解业务需求，提出合理预算，满足行业合规，推动部门合作等等。

每一个地方出现问题，都会造成集成项目无法落地，或者无法创造价值，最终导致项目失败或难以持续发展。集成的问题非常复杂，我这里提出两种解决思路。

第一个思路是”数据即事实“，部门之间的协作应该建立在数据事实的基础之上，而不是个人主观的描述，避免责任推诿，促进团队协作。

第二个思路是”业务为中心“，无论开发、测试、系统、网络、安全等团队，均需要深入理解业务，从对代码、系统、设备的负责，变为对业务上线速度、交易量、健康度的负责。

思路好理解，但落地仍然不明确，下面我们举一个栗子来进一步说明集成的复杂性。

这是某大行网络工程师给我们的发展规划。诸位听众中如果有网络工程师，可以对比下是否有这样的先进思路？

首先，集成的第一步是全栈流量采集能力，而这里考虑最多的是零侵扰特性。零侵扰被进一步划分为：稳定性、可用性、资源耗损、通用性、存储消耗、网络消耗等问题。每一个问题都需要严格的长期测试才能验证。

第二步是建立分布式系统的诊断能力。这里面考虑最多的是多维度分析能力。协议栈设计到了物理机、虚拟机、容器、业务码等，并且要求提供全栈链路追踪。另外要求能够被大数据平台和其他监控平台通过 API 集成。

第三步是对外服务能力。也就是之前所说的原力释放阶段。这里考虑最多的是场景和自服务。场景包括了全网监控、应用监控、客户监控、安全监控等，自服务则要求主要功能均通过用户自行完成。由于不同场景需要不同的数据支持，背后技术涉及到了实时数仓的建立和集成。

新一代的网络工程师，借助可观测性，实现了自我价值，并提升了团队间的协作能力。与之类似，系统团队、开发团队、SRE 团队等，均可以通过集成方法构建可观测性平台，以提升团队的自身价值和协作能力。

0x4：如何使用可观测性？

前面分享了可观测性的三种构建方式，下面我们来看看可观测性如何在实战中发挥价值。这里我会较详细讲述两个典型用例，同时也会快速介绍其他 10 个用例，以此打开大家的思路，体会可观测性的不同用途。

第一个用例来自某智能车企，其业务变化非常快，公司采用公有云+容器化部署核心业务，并通过整合各类开源监控软件，构建“统一业务监控平台”。公司业务迭代速度非常快，但微服务观测不全一直是困扰着业务快速上线的一大问题。业务上线后遇到故障只能靠猜、靠逐段抓包诊断故障原因，费时费力。

近期在生产环境中，nginx-control 上线过程中出现了某 API（xxx-api）调用某服务（xxx-service.prod.k8s.xxx.com）超时的情况。虽然现有系统能定位到工作负载和服务域名（即源和目的），但其间经过多个微服务和网络服务，到底是谁引发了访问中断却不得而知。

由于客户端、服务端均没有（或无法）部署 Skywalking 监控、没有采集日志，开发人员不知道超时原因。这个问题经过一整天排查未有结论，严重影响业务上线进度。借助可观测性的全栈能力，SRE 团队在 15 分钟内定位到了根因，即问题出自一个特定的 Ingress Control 的容器 POD。反馈到开发人员后通过修复 Nginx 快速恢复了故障。

第二个用例来自某股份制银行，该行在国内外的 100 多个城市设立了服务网点。很多业务部署在云平台的容器上。该行私有云平台上运行着 10 万多个微服务，数十万个 POD 支撑业务，每分钟业务产生的访问数亿次。

该行业务运维人员经常遇到关键资源访问量徒增问题，尤其是云上云下互访时，“谁动了我的数据库！”是常见抱怨。要追查出到底是谁动了关键资源，难点重重。

难点之一是可疑分子太多，可疑分子隐藏在 8 万多个 POD，8 千多个 Node、1 千多 VM、1 千多 Host 之中。难点之二是每个可疑分子到关键资源之间，至少经过两次地址转换，且 POD、Node、VM、Host、PIP、GW 的访问路径非常复杂。难点之三是业务 POD 上不允许抓包，网关 GW 上也难以抓包（网关抓包丢包率高达 40%)。

上述问题通过可观测性就得到了良好解决。首先，可观测性平台提供 POD、Node、VM、Host、GW 资源上全量网络流量采集，解决了 POD、MUX 上流量采集难的问题其次，可观测性平台同步了云平台 NAT、LB 等转换规则，通过服务端源 IP 地址、目的 IP 地址，分钟级在海量数据中，找到对应的 POD、Node、VM、Host；最后，可观测性平台为业务部门梳理出来常见的全栈链路观测模板，助力业务部门分钟级定位业务性能峰值问题。

如何使用可观测性

如图所示，根据业务场景，访问路径非常复杂，需要层层梳理。否则不可能解决”谁动了我的数据库！“问题。

第一个用例，是某银行在开发测试中遇到业务周期性抖动，持续一周无法上线。最终通过可观测性发现了底层路由器环路导致。

第二个用例，某地产商的电子流应用，上云后每周都出现问题。最终通过可观测性发现了服务商 DNS 不稳定、开发团队违规升级代码、依赖第三方服务异常等一系列问题。

第三个用例，某大型金融企业，电商业务运行的容器平台，每扩展一个 POD 竞耗时超过 1 小时，而且要反复不停重试。后根据可观测性分析，逐步定位到某物理网卡对 ARP 请求产生了内部回路，更换机器后恢复正常。

第四个用例，某运营商省公司在集团对应用的可用性考核中，年年全省垫底。最终通过可观测性，发现了 LVS、nginx 和某物理交换机之间的链路有丢包，彻底排除了困扰已久的问题。

第五个用例，某大型私有云客户，发现其关键业务中的 SQL 集群频繁主备切换，虽然业务没有中断，但风险极高。后经可观测性平台分析，发现是 SQL 切换仲裁在并发并不高的情况下就停止了服务，最终导致了不必要的切换。

第六个用例，某银行个人贷款业务突然访问变慢，在大家都怀疑是网关丢包的情况下，通过可观测性平台，定位到了 DNS 服务异常。而且，进一步发现不仅仅是该业务的可用区 DNS 异常，其他区域也有普遍现象，根本原因是 DNS 配置错误。

第七个用例，某 BI 业务，运行过程中出现性能抖动。业务侧看到的只是客户端到 BI 的访问路径，而可观测性平台看到的是业务端-NGINX-BI-RPC-MongoDB 的整体依赖。后定位为 RPC 服务中有一个容器出现问题，排除此容器后业务恢复正常。

第八个用例，某省消防队，经常被省里通报，尤其是护网期间通报，必须排除通报的安全问题。由于全省消防内网复杂，而通报又只针对不到 10 个对外服务的 IP，如何追查内部攻击源变得非常困难。通过可观测性平台，该省消防队实现了 10 分钟内应答通报的能力。

第九个用例，某大型容器云平台，按传统 pcap 分析方式运维，一次简单故障平均查找数千个数据包，耗费专家数小时的宝贵时间。通过可观测性平台，业务排障由抓包分析变为微服务 RED 指标监控和全栈链路追踪，排障效率从小时级变为分钟级。

第十个用例，某农商行，视频业务上云后访问量增长近 10 倍，经常出现业务访问慢问题，几次扩容都不能解决问题。后根据可观测性平台分析，发现是某个隐藏服务异常发送 RST 包导致，优化服务的队列和超时设置之后，业务恢复正常。

我这里先简单介绍 10 个用例，更多更精彩的用例分享，会由我们的同事、客户和合作伙伴在后面的直播中跟大家继续分享。

好了，总结一下今天介绍。

为什么需要可观测性，就是给大家”赋能“。让工程师、架构师、以及技术管理人员能够提升自我的认知能力、创新能力和组织能力。

如何理解可观测性，介绍了三种不同的视角：

• 三大支柱说，也就是 three pillars，来自 Peter Bourgon，背后是数据结构理论。
• 探索未知说，也就是 unknown-unknown，来自 Charity Majors，背后是软件工程理论。
• 白盒监控说，也就是 white-box monitoring，是我根据控制理论中可观测性的定义推导出来的。

如何评估可观测性，主要三个方面，零侵扰、多维度、实时性。之前的介绍中也给出了详细的判据和背后的技术趋势。

至于如何构建可观测性，介绍了三种方法，SaaS 用于体验、开源用于创新、集成用于合规。