Mango：斯坦福CS146S：分布式追踪，你的系统出了问题，你为什么找不到？

Mango：斯坦福CS146S：分布式追踪，你的系统出了问题，你为什么找不到？ Mango：斯坦福CS146S：分布式追踪，你的系统出了问题，你为什么找不到？ Modified March 12 反面案例之外，也值得看一个"追踪用对了"的样本。 Shopify在2024年黑色星期五创下多项记录：57.3 PB数据处理量、10.5万亿次数据库查询、边缘节点每分钟峰值2.84亿次请求，单日数据吞吐量达12TB每分钟。 这不是靠运气撑过去的。Shopify从每年3月就开始容量规划，每一项架构变更和迁移都在黑色星期五前数月完成，而不是把大促当作发布截止日。 他们还模拟了真实用户行为：店面浏览与结账、应用API流量、分析报告负载，以及后端webhook处理，同时测试了关键场景：峰值负载、区域故障转移，以及多个系统同时故障的级联崩溃。 追踪在这里扮演的角色，是提前把"如果……那么……"变成有数据支撑的判断，而不是等到故障发生后再事后诸葛。 数据量的代价 追踪一切听起来很美，但现实的约束是数据量。高并发系统每秒产生成千上万次请求，全量追踪意味着每天TB级数据，存储与查询成本会失控。 几乎所有系统都使用 采样 ：头部采样在请求进来时就决定要不要记录，简单但可能丢掉低频错误；尾部采样在请求完成后再决定，能优先保留出错的请求，但实现复杂、延迟高。 如果你只保留5%的请求追踪，那出现概率低于5%的故障，你几乎看不到。 工具选择的实质 目前主流实现方案是 OpenTelemetry ——一套厂商中立的开放标准，支持主流编程语言，很多框架无需改代码就能采集数据。 国内工程团队有两条路：SkyWalking这类国产开源方案，社区活跃、对Java生态支持成熟，自托管成本相对可控；阿里云ARMS、腾讯云APM等商业托管方案，省去运维负担，但同样面临数据量增长时的账单预期问题。 如果你选自建，问题不在于能不能用，而在于 谁来维护、维护成本是否真的比商业方案低 。 真正值得追问的 从阿里云的3小时故障、到腾讯的一级事故、到Coinbase的巨额账单，这些案例指向三个相同的结构性问题： 可观测性基础设施本身的可靠性 。 如果追踪系统依赖了被追踪的组件，当核心组件崩了，你恰好在最需要数据的时刻什么也看不见。 谁在维护追踪逻辑 。 系统每次变更，插桩代码是否同步更新？如果没有，Span会逐渐失真，追踪结果开始误导判断——这比没有追踪更危险。 数据的主权归谁 。 追踪数据里有用户行为、调用路径、业务参数。全链路错误寻根，即从发现请求指标异常，到逐层下钻到明细Trace追踪和具体Error Log，全流程实现从宏观到明细的错误定位。这些数据存在哪里、谁能查看、是否合规——在监管日趋收紧的环境下，这是一个被低估的风险点。 工具只是工具。它解决的是"看不见"的问题。至于看见之后，谁来负责、怎么行动——那是另一套问题。 术语速查 基础概念 微服务（Microservices） 把一个大系统拆成很多小服务，每个服务只负责一件事。比如"登录"是一个服务，"支付"是另一个服务，"推荐算法"又是一个。好处是灵活，坏处是服务一多，出了问题不知道哪里坏了。 分布式系统（Distributed System） 程序不跑在一台机器上，而是同时跑在很多台机器上，互相配合。现在几乎所有大型互联网产品都是分布式的。 Trace（追踪） 一次用户请求从头到尾的完整记录。你点了"下单"，这个请求经过了哪些服务、每一步花了多少时间、哪里出了错——全部记下来，就是一条Trace。 Span（跨度） Trace里的每一个小步骤。"查了一次数据库"是一个Span，"调用了支付接口"是另一个Span。多个Span拼在一起，构成完整的Trace。 Trace ID 给每一次请求分配的唯一编号，像快递单号。请求经过多少个服务，这个编号一直跟着，最后才能把所有Span串成一条完整链路。 系统监控相关 可观测性（Observability） 不只是"系统有没有报警"，而是"系统出了问题，我能不能搞清楚为什么"。可观测性好的系统，出故障时工程师能快速定位；可观测性差的系统，出故障只能靠猜。 日志（Log） 系统运行时记录的文字信息，类似流水账。"某时某刻某台机器发生了什么事"——日志能告诉你，但它不告诉你请求的完整路径。 指标（Metrics） 数字化的系统状态，比如CPU使用率、每秒请求数、错误率。适合看整体健康，不适合定位具体问题。 采样（Sampling） 不记录所有请求，只记录其中一部分。比如每100个请求只追踪5个。目的是控制数据量和成本，代价是可能漏掉低概率的故障。 SLO（Service Level Objective，服务级别目标） 对系统性能的量化承诺。比如"99.9%的请求必须在200毫秒内返回"。有了追踪数据，才能知道自己是否达标。 MTTR（Mean Time To Recovery，平均恢复时间） 从故障发生到恢复正常，平均需要多久。这是衡量一个团队故障响应能力的核心指标。追踪工具能有效压缩这个时间。 工具与标准 OpenTelemetry 一套开放标准，定义了追踪数据应该长什么样、怎么传递。由Google、微软等公司联合推动，目的是让不同工具之间的数据可以互通，避免被某一家供应商锁定。类比：相当于追踪领域的"USB接口标准"。 SkyWalking 国产开源追踪框架，2015年由中国工程师吴晟发起，后来进入Apache基金会。在国内Java技术栈里使用广泛，是OpenTelemetry之外另一个主流选择。 Jaeger / Zipkin 两个开源的追踪后端工具，负责收集、存储和展示Trace数据。自己搭建，免费，但需要自己维护。 Datadog 美国商业可观测性平台，功能强大，按数据量收费。Coinbase因为用它花了6500万美元上了新闻。 Prometheus / Grafana 两个常配合使用的开源工具。Prometheus负责采集和存储指标数据，Grafana负责可视化展示。很多公司从Datadog迁出后选择这套组合自建。 架构与故障相关 上下文传播（Context Propagation） 把Trace ID随着请求一起传递下去的机制。请求从服务A跳到服务B时，ID不能丢，否则追踪链路就断了。通常藏在HTTP请求头里。 插桩（Instrumentation） 在代码里埋入追踪逻辑，让系统自动记录Span。有些框架支持"自动插桩"，不用改代码；有些需要手动在关键位置加代码。 灰度发布（Canary Release） 新版本不一次性推给所有用户，先推给1%或5%，观察有没有问题，再逐步扩大。CrowdStrike事故的教训之一，就是更新缺乏灰度机制。 级联故障（Cascading Failure） 一个服务出问题，导致依赖它的服务也跟着出问题，像多米诺骨牌。阿里云2023年故障的核心机制：鉴权服务异常，依赖它的OSS和MQ跟着崩，再往下所有依赖OSS和MQ的业务全部受影响。 对应关系： 想 知 道系统整体健不健康，看指标； 想知道某台机器发生了什么，翻日志； 想知道一次请求经过了哪里、卡在哪里，用追踪。 三者结合起来，是可观测性。 你想知道 用什么 系统整体健不健康 指标（Metrics） 某台机器发生了什么 日志（Log） 一次请求经过了哪里、卡在哪里 追踪（Trace/Span） 三者结合起来 可观测性（Observability） 编者按：我们花了三十年，学会"看见"自己造的东西 有一个问题值得先想清楚：人类历史上，有哪一次大规模的工程事故，是因为"看的信息太多"而发生的？ 几乎没有。绝大多数崩溃，都源于 看不见 。 分布式追踪这件事，表面上是一个工程工具的演进故事，背后其实是一个更长的问题：我们造出了比自己理解能力更复杂的系统，然后怎么办？ 回顾：三条线索 第一条线索：复杂度的自我繁殖。 2000年代初，一个网站后端可能就是一台服务器、一个数据库。出了问题，登录上去看日志，基本够用。 后来微服务来了。一个"结账"按钮背后，开始有十几个服务在协同工作。再后来是容器、是Serverless、是多云部署。系统的边界越来越模糊，调用链越来越长。工程师们发现，原来那套"登录上去看日志"的方法，开始对付不了了——就像你试图用手电筒照亮一座迷宫。 这不是坏事造成的，是 好事堆叠的副作用 。每一次架构升级，都是为了更快、更稳、更便宜；但累积到一定程度，系统整体的可理解性，开始以比预期快得多的速度下降。 第二条线索：工具追着问题跑。 Google在2010年发表了Dapper论文，系统性描述了分布式追踪的原理。那是这个领域的起点。 此后十年，Zipkin、Jaeger相继出现，解决了"能不能追踪"的问题。但工具是碎片化的，A公司用这套，B公司用那套，数据格式不兼容，服务一旦跨组织边界，追踪链路就断了。 2019年，OpenTelemetry出现，把竞争对手的两个项目合并成一个中立标准。这一步的意义，不只是技术统一，更是 承认了一件事：可观测性是基础设施，不是竞争壁垒 。就像TCP/IP协议不属于任何一家公司，追踪数据的格式，也不应该被某个供应商锁定。 第三条线索：代价从隐性变显性。 早期，可观测性的代价藏在工程师的加班时数里——出了故障，靠人肉排查，靠经验猜测，靠运气。这个成本是真实的，但它分散在无数个深夜，没有人汇总成一个数字。 Coinbase的6500万美元Datadog账单，让这个代价第一次以财务报表的形式出现在公众视野里。CrowdStrike的故障，让Delta航空损失5亿美元，诉诸法庭。阿里云2023年的3小时中断，让停车场不抬杆、外卖骑手进不了系统——这些都是可观测性缺口的外部性，只是以前没人这么叫它。 从隐性到显性，意味着这件事开始被当作一个 治理问题 ，而不只是技术问题。 展望：三个预测 预测一：追踪数据会成为监管对象。 这不是危言耸听。追踪数据里有什么？用户行为路径、调用的第三方服务、每一笔交易经过哪些系统、哪个服务读取了哪些数据。这是一份比日志更精确、比指标更丰富的系统档案。 反面案例之外，也值得看一个"追踪用对了"的样本。 Shopify在2024年黑色星期五创下多项记录：57.3 PB数据处理量、10.5万亿次数据库查询、边缘节点每分钟峰值2.84亿次请求，单日数据吞吐量达12TB每分钟。 这不是靠运气撑过去的。Shopify从每年3月就开始容量规划，每一项架构变更和迁移都在黑色星期五前数月完成，而不是把大促当作发布截止日。 他们还模拟了真实用户行为：店面浏览与结账、应用API流量、分析报告负载，以及后端webhook处理，同时测试了关键场景：峰值负载、区域故障转移，以及多个系统同时故障的级联崩溃。 追踪在这里扮演的角色，是提前把"如果……那么……"变成有数据支撑的判断，而不是等到故障发生后再事后诸葛。 数据量的代价 追踪一切听起来很美，但现实的约束是数据量。高并发系统每秒产生成千上万次请求，全量追踪意味着每天TB级数据，存储与查询成本会失控。 几乎所有系统都使用 采样 ：头部采样在请求进来时就决定要不要记录，简单但可能丢掉低频错误；尾部采样在请求完成后再决定，能优先保留出错的请求，但实现复杂、延迟高。 如果你只保留5%的请求追踪，那出现概率低于5%的故障，你几乎看不到。 工具选择的实质 目前主流实现方案是 OpenTelemetry ——一套厂商中立的开放标准，支持主流编程语言，很多框架无需改代码就能采集数据。 国内工程团队有两条路：SkyWalking这类国产开源方案，社区活跃、对Java生态支持成熟，自托管成本相对可控；阿里云ARMS、腾讯云APM等商业托管方案，省去运维负担，但同样面临数据量增长时的账单预期问题。 如果你选自建，问题不在于能不能用，而在于 谁来维护、维护成本是否真的比商业方案低 。 真正值得追问的 从阿里云的3小时故障、到腾讯的一级事故、到Coinbase的巨额账单，这些案例指向三个相同的结构性问题： 可观测性基础设施本身的可靠性 。 如果追踪系统依赖了被追踪的组件，当核心组件崩了，你恰好在最需要数据的时刻什么也看不见。 谁在维护追踪逻辑 。 系统每次变更，插桩代码是否同步更新？如果没有，Span会逐渐失真，追踪结果开始误导判断——这比没有追踪更危险。 数据的主权归谁 。 追踪数据里有用户行为、调用路径、业务参数。全链路错误寻根，即从发现请求指标异常，到逐层下钻到明细Trace追踪和具体Error Log，全流程实现从宏观到明细的错误定位。这些数据存在哪里、谁能查看、是否合规——在监管日趋收紧的环境下，这是一个被低估的风险点。 工具只是工具。它解决的是"看不见"的问题。至于看见之后，谁来负责、怎么行动——那是另一套问题。 术语速查 基础概念 微服务（Microservices） 把一个大系统拆成很多小服务，每个服务只负责一件事。比如"登录"是一个服务，"支付"是另一个服务，"推荐算法"又是一个。好处是灵活，坏处是服务一多，出了问题不知道哪里坏了。 分布式系统（Distributed System） 程序不跑在一台机器上，而是同时跑在很多台机器上，互相配合。现在几乎所有大型互联网产品都是分布式的。 Trace（追踪） 一次用户请求从头到尾的完整记录。你点了"下单"，这个请求经过了哪些服务、每一步花了多少时间、哪里出了错——全部记下来，就是一条Trace。 Span（跨度） Trace里的每一个小步骤。"查了一次数据库"是一个Span，"调用了支付接口"是另一个Span。多个Span拼在一起，构成完整的Trace。 Trace ID 给每一次请求分配的唯一编号，像快递单号。请求经过多少个服务，这个编号一直跟着，最后才能把所有Span串成一条完整链路。 系统监控相关 可观测性（Observability） 不只是"系统有没有报警"，而是"系统出了问题，我能不能搞清楚为什么"。可观测性好的系统，出故障时工程师能快速定位；可观测性差的系统，出故障只能靠猜。 日志（Log） 系统运行时记录的文字信息，类似流水账。"某时某刻某台机器发生了什么事"——日志能告诉你，但它不告诉你请求的完整路径。 指标（Metrics） 数字化的系统状态，比如CPU使用率、每秒请求数、错误率。适合看整体健康，不适合定位具体问题。 采样（Sampling） 不记录所有请求，只记录其中一部分。比如每100个请求只追踪5个。目的是控制数据量和成本，代价是可能漏掉低概率的故障。 SLO（Service Level Objective，服务级别目标） 对系统性能的量化承诺。比如"99.9%的请求必须在200毫秒内返回"。有了追踪数据，才能知道自己是否达标。 MTTR（Mean Time To Recovery，平均恢复时间） 从故障发生到恢复正常，平均需要多久。这是衡量一个团队故障响应能力的核心指标。追踪工具能有效压缩这个时间。 工具与标准 OpenTelemetry 一套开放标准，定义了追踪数据应该长什么样、怎么传递。由Google、微软等公司联合推动，目的是让不同工具之间的数据可以互通，避免被某一家供应商锁定。类比：相当于追踪领域的"USB接口标准"。 SkyWalking 国产开源追踪框架，2015年由中国工程师吴晟发起，后来进入Apache基金会。在国内Java技术栈里使用广泛，是OpenTelemetry之外另一个主流选择。 Jaeger / Zipkin 两个开源的追踪后端工具，负责收集、存储和展示Trace数据。自己搭建，免费，但需要自己维护。 Datadog 美国商业可观测性平台，功能强大，按数据量收费。Coinbase因为用它花了6500万美元上了新闻。 Prometheus / Grafana 两个常配合使用的开源工具。Prometheus负责采集和存储指标数据，Grafana负责可视化展示。很多公司从Datadog迁出后选择这套组合自建。 架构与故障相关 上下文传播（Context Propagation） 把Trace ID随着请求一起传递下去的机制。请求从服务A跳到服务B时，ID不能丢，否则追踪链路就断了。通常藏在HTTP请求头里。 插桩（Instrumentation） 在代码里埋入追踪逻辑，让系统自动记录Span。有些框架支持"自动插桩"，不用改代码；有些需要手动在关键位置加代码。 灰度发布（Canary Release） 新版本不一次性推给所有用户，先推给1%或5%，观察有没有问题，再逐步扩大。CrowdStrike事故的教训之一，就是更新缺乏灰度机制。 级联故障（Cascading Failure） 一个服务出问题，导致依赖它的服务也跟着出问题，像多米诺骨牌。阿里云2023年故障的核心机制：鉴权服务异常，依赖它的OSS和MQ跟着崩，再往下所有依赖OSS和MQ的业务全部受影响。 对应关系： 想 知 道系统整体健不健康，看指标； 想知道某台机器发生了什么，翻日志； 想知道一次请求经过了哪里、卡在哪里，用追踪。 三者结合起来，是可观测性。 你想知道 用什么 系统整体健不健康 指标（Metrics） 某台机器发生了什么 日志（Log） 一次请求经过了哪里、卡在哪里 追踪（Trace/Span） 三者结合起来 可观测性（Observability） 你想知道 你想知道 用什么 用什么 系统整体健不健康 系统整体健不健康 指标（Metrics） 指标（Metrics） 某台机器发生了什么 某台机器发生了什么 日志（Log） 日志（Log） 一次请求经过了哪里、卡在哪里 一次请求经过了哪里、卡在哪里 追踪（Trace/Span） 追踪（Trace/Span） 三者结合起来 三者结合起来 可观测性（Observability） 可观测性（Observability） 编者按：我们花了三十年，学会"看见"自己造的东西 有一个问题值得先想清楚：人类历史上，有哪一次大规模的工程事故，是因为"看的信息太多"而发生的？ 几乎没有。绝大多数崩溃，都源于 看不见 。 分布式追踪这件事，表面上是一个工程工具的演进故事，背后其实是一个更长的问题：我们造出了比自己理解能力更复杂的系统，然后怎么办？ 回顾：三条线索 第一条线索：复杂度的自我繁殖。 2000年代初，一个网站后端可能就是一台服务器、一个数据库。出了问题，登录上去看日志，基本够用。 后来微服务来了。一个"结账"按钮背后，开始有十几个服务在协同工作。再后来是容器、是Serverless、是多云部署。系统的边界越来越模糊，调用链越来越长。工程师们发现，原来那套"登录上去看日志"的方法，开始对付不了了——就像你试图用手电筒照亮一座迷宫。 这不是坏事造成的，是 好事堆叠的副作用 。每一次架构升级，都是为了更快、更稳、更便宜；但累积到一定程度，系统整体的可理解性，开始以比预期快得多的速度下降。 第二条线索：工具追着问题跑。 Google在2010年发表了Dapper论文，系统性描述了分布式追踪的原理。那是这个领域的起点。 此后十年，Zipkin、Jaeger相继出现，解决了"能不能追踪"的问题。但工具是碎片化的，A公司用这套，B公司用那套，数据格式不兼容，服务一旦跨组织边界，追踪链路就断了。 2019年，OpenTelemetry出现，把竞争对手的两个项目合并成一个中立标准。这一步的意义，不只是技术统一，更是 承认了一件事：可观测性是基础设施，不是竞争壁垒 。就像TCP/IP协议不属于任何一家公司，追踪数据的格式，也不应该被某个供应商锁定。 第三条线索：代价从隐性变显性。 早期，可观测性的代价藏在工程师的加班时数里——出了故障，靠人肉排查，靠经验猜测，靠运气。这个成本是真实的，但它分散在无数个深夜，没有人汇总成一个数字。 Coinbase的6500万美元Datadog账单，让这个代价第一次以财务报表的形式出现在公众视野里。CrowdStrike的故障，让Delta航空损失5亿美元，诉诸法庭。阿里云2023年的3小时中断，让停车场不抬杆、外卖骑手进不了系统——这些都是可观测性缺口的外部性，只是以前没人这么叫它。 从隐性到显性，意味着这件事开始被当作一个 治理问题 ，而不只是技术问题。 展望：三个预测 预测一：追踪数据会成为监管对象。 这不是危言耸听。追踪数据里有什么？用户行为路径、调用的第三方服务、每一笔交易经过哪些系统、哪个服务读取了哪些数据。这是一份比日志更精确、比指标更丰富的系统档案。 当金融监管机构开始关注"系统性风险"，当数据安全法规要求企业说清楚"数据流向了哪里"，追踪数据将成为审计的直接证据。 《黑客军团》里有一句台词："你以为你在控制系统，其实系统在控制你。"如果追踪数据没有被纳入合规框架，那些拥有最完整追踪数据的平台，事实上掌握了比数据主体更清晰的系统图谱。 预测二：AI会接管大部分追踪分析工作——但不会接管判断。 当前阶段，追踪数据需要人来解读：哪个Span异常、根因在哪、影响范围多大。这需要经验，需要上下文理解，需要跨系统知识。 大模型在这里有明显的优势：它可以同时阅读数千条Span，关联日志、指标和告警，给出比人更快的初步判断。部分公司已经在这条路上走了——用LLM辅助On call工程师做根因分析。 但真正值得追问的是： 如果AI给出了错误的根因判断，工程师却因为"AI说了"而选择相信，谁来承担后果？ 工具的智能化，不会自动解决责任归属的模糊性。追踪数据告诉你发生了什么，判断还是需要人来做。 预测三：可观测性会变成一项公共基础设施能力。 听起来有点远，但逻辑并不跳跃。 电网有统一的安全标准，食品有统一的检测体系，金融系统有统一的压力测试框架。这些都是因为：当基础设施足够关键，私人治理的激励机制开始失效，社会需要一套共识标准介入。 互联网基础设施已经到了这个门槛。2023年阿里云故障影响的不只是互联网用户，而是停车场、超市、医院系统。当数字基础设施的故障开始产生物理世界的后果，可观测性的标准化——谁必须做、做到什么程度、数据保留多久——就不再只是工程团队内部的讨论议题了。 这个领域走到今天，核心进步不是工具变得更强，而是 我们终于开始正视一件事：复杂系统需要被设计成可理解的，而不只是可运行的。 能运行的系统很多。能被理解、能被追溯、出了问题知道为什么——这才是真正意义上的"可靠"。 这不是技术问题，是一种工程文化的成熟。 🔗 原文链接： https://mp.weixin.qq.com/s/eRrQXOSM... https://mp.weixin.qq.com/s/eRrQXOSM... 原创 Mango Mango 烂芒2026年3月12日 08:08 上海 问题不在于系统复杂，而在于你根本看不见它内部在发生什么。 一个用户点击"结账"，请求穿越API网关、鉴权服务、库存系统、支付接口，最终返回一个结果。整条链路可能经过十几个服务。如果某一环慢了，你怎么知道是哪一环？ 靠日志？日志告诉你某台机器发生了什么，但不告诉你请求的完整路径。靠监控指标？指标告诉你系统整体健康与否，但定位不到具体那一刀切在哪里。 真正值得追问的是： 谁在 承担排查成本， 谁在享受系统的不透明？ 两个概念，trace 和 span Trace（追踪） ，是一次请求从进入系统到返回结果的完整旅程记录。 Span（跨度） ，是这段旅程中每一个具体操作的计时单元。一次数据库查询是一个Span，一次外部API调用是一个Span，它们嵌套在一起，构成整棵调用树。 如果Span是每一段路程的里程碑，Trace就是整张地图。每个Span携带什么？名称、起止时间、状态（成功/报错）、自定义属性（比如用户ID、订单金额）。这些数据拼在一起，才能还原出一次请求的完整现场。 它怎么跨越服务边界？ 难的不是单服务内部追踪，而是：请求离开服务A，进入服务B，追踪如何不断链？ 答案是 上下文 传播 。请求进入系统时被分配唯一的Trace ID，这个ID通过HTTP Header随请求一路传递。每个服务创建自己的Span，但都挂在同一个Trace ID下。W3C已将这套机制标准化，字段叫 traceparent 。 如果某个服务忘记传递这个Header，追踪链路就会断掉。这是最常见的反模式： 不是追踪做错了，而是上下文在中途丢失了 。 案例一：阿里云，3小时16分钟的多米诺骨牌 2023年11月12日——双十一刚落幕的第二天。 17:44，全球范围内所有可用区、所有服务全部出现异常，持续时间从17:44到21:11，共计3小时16分钟。淘宝买不了东西、饿了么点不了外卖、骑手进不了系统、停车场不抬杆、超市无法结账。 故障期间阿里云控制台无法正常登录，一些用户抱怨由于DNS服务也出现问题，导致无法做故障转移，"想跑都跑不了"。 根源是什么？据内部人士透露，此次主要是阿里云的AK鉴权发生异常，进而影响到了OSS和MQ这两个核心组件，而其他公司很多服务都强依赖这两个组件，所以当它们受损时便被牵连。 RAM这样的系统会使用大量配置来控制策略，而配置的发布通常不会有像代码变更那样长时间的灰度过程。有时一个全局配置推送出去后，经过简单检查便迅速同步到各个分区，坏的配置因此更容易造成全球故障。 这里有一个值得追问的结构性问题：全链路追踪本可以在鉴权服务出现异常的早期，通过Span错误率的异常攀升触发告警。但如果追踪系统本身依赖了同一套鉴权组件，那当鉴权崩了，追踪数据还能正常上报吗？ 可观测性基础设施，一旦和被观测的系统共享了关键依赖，就会在最需要它的时刻一起失效。 这不是阿里云独有的问题，而是整个行业的结构性盲点。 案例二：腾讯微信，一台冷却机引发的一级事故 2023年3月底，微信、QQ等业务出现大面积功能异常，涉及微信语音呼叫、账号登录、朋友圈、支付在内的多个功能。据媒体报道，此次事故由广州电信机房冷却系统故障导致，腾讯将其定义为公司一级事故，多个管理层因此受到通报批评和处罚。 物理基础设施的失效，在分布式追踪层面会呈现成什么样子？是某个机房内所有Span突然超时，还是请求开始大规模路由失败？如果追踪链路足够完整，工程师本可以在冷却系统报警的同时，同步看到微服务调用链上哪一段开始出现异常热点，而不是等到用户投诉涌上热搜才开始定位。 问题不在于物理故障难以避免，而在于 从机房温度异常到业务层面感知故障，中间那段时间差，是有机会被追踪数据压缩的。 案例三：SkyWalking，一个中国工程师造出来的全球标准 值得单独说一个正面案例。 SkyWalking是一个国产开源框架，2015年由吴晟开源，2017年加入Apache孵化器，专为微服务、云原生架构和基于容器架构而设计。 它解决了一个国内工程师遇到的实际问题：掌门教育工程师在升级内部框架后，压测吞吐量从53.9/s下降到6.4/s，CPU负载异常。正是通过公司全链路监控系统SkyWalking中查询到的链路信息，发现了Feign调用的耗时异常（390ms），最终定位到根因。 腾讯云在落地全链路追踪时总结了一个实践：通过打通前后端链路数据，如果在前端浏览器或小程序侧作为第一跳产生TraceId，就可以实现前后端调用链的互通。当服务端出现异常导致前端调用失败时，站在客户端的视角，可以根据TraceId快速找到服务端错误的原因。 这套"前端Span串联到后端Span"的思路，实际上把可观测性的边界从服务器端延伸到了用户浏览器——这意味着一个外卖骑手看到"系统异常"时，工程师理论上可以追溯到他那一次点击触发了哪条调用链、卡在了哪个Span。 案例四：CrowdStrike，8500万美元的更新 2024年7月19日，CrowdStrike向其Falcon传感器推送了一个配置更新，导致全球约850万台Windows设备崩溃，触发蓝屏死机。这被称为信息技术史上规模最大的单次故障。 从可观测性角度看，问题不在于出了bug。CrowdStrike在78分钟后就发现了错误并回滚，但对许多已接收更新的设备而言，为时已晚，损失无法挽回。Delta航空声称此次事故造成约5亿美元损失，并对CrowdStrike提起诉讼。 如果更新采用了分阶段发布与追踪结合的策略——先向1%的设备推送，观察Span中的错误率是否异常攀升，再决定是否继续——这场波及全球的故障，可能只是一次内部警报。 案例五：Coinbase，一张6500万美元的账单 追踪工具本身，也可以成为风险来源。 Coinbase在2021年牛市期间IPO后，没有人关心基础设施成本，唯一的焦点是增长。结果公司在AWS、Snowflake和Datadog上积累了巨额账单，其中仅Datadog一项就高达6500万美元，并在2022年第一季度结清。 工程师们为了更好地"看见"系统，给每个Span添加了大量属性——结果每一个属性都在悄悄计费。加密市场随后急剧降温，Coinbase被迫组建专门团队，目标是迁出Datadog，转向Gra