知识花园

最近更新

运维的本质：在人与资源之间持续校准

33分钟阅读

运维的本质：在人与资源之间持续校准

监控、可观测性、SLO、eBPF、OpenTelemetry——这些技术看起来在解决不同的问题，分属不同的年代，背后却是同一件事在反复上演：在”人的注意力”和”机器的资源”这两种稀缺品之间，找一个当下负担得起的平衡点。

这一篇不讲任何产品。它要论证的是：运维工程的所有范式，本质上都是同一个命题在不同时代汇率下的成交价。理解了这个不变的内核，后面九篇文章就不再是一堆孤立的工具清单，而是同一根标尺上的一个个刻度。

一、困境：系统不可读

一屏绿色的悖论

一个服务变慢了。你打开监控仪表盘：CPU 正常，内存正常，错误率正常，磁盘有空间，网络不丢包。每一块图表都是绿的。

但用户在投诉。客服群里在炸。而你，看着一屏绿色，不知道哪里出了问题。

这不是一个罕见的事故现场，这是运维工程师的日常。它之所以令人不安，不是因为”监控失灵了”——监控运转良好，每一个它被设计去观察的指标都被诚实地报告了出来。问题在于：你想知道的那个东西，根本不在这些图表里。

你无法”读完”一个系统

为什么会这样？因为一个足够复杂的系统，你永远无法”读完它”。

一个现代的互联网服务，可能由数十个微服务、数千个容器、跨越多个可用区组成，每秒处理成千上万次请求，每一次请求都在几十个组件之间穿行。它的”内部状态”是一个高维到无法被人脑完整把握的对象——你不可能在任意时刻，知道每一个组件正在做什么、彼此之间正在发生什么。

于是你只能做一件事：从它主动发出或被动暴露的信号，去反推它内部正在发生什么。一条日志、一个指标的抖动、一段追踪的耗时——这些是系统从黑箱里漏出来的光，你靠这些光的形状，去想象箱子里的世界。

运维，天然是一个黑箱推断问题。你不是在”读”系统，你是在”猜”系统——只不过是有证据的猜。

运维的元问题

把这个困境收敛成一句话，它就是这一整个系列要回答的元问题：

一个你无法直接观察内部的系统，你怎么知道它是否健康？出了问题，你怎么理解它？

请记住这句话。监控是对它的一种回答，可观测性是另一种回答，SLO 是回答中关于”什么叫健康”的部分，eBPF 是回答中关于”怎么以更低代价去看”的部分。所有后续的技术，都是这句话在不同约束下长出的不同形状。

而要理解这些形状为什么不同，我们必须先看清：回答这个问题，从来不是免费的。

二、从认识论到经济学：为什么”看见”是一笔支出

第一章把运维定义成一个认识论问题——如何认识一个不可直接观察的对象。但认识论是哲学家的奢侈，工程师要为认识付费。这一章要完成全篇最关键的一跳：把”如何知道系统状态”这个认识论问题，翻译成”如何分配稀缺资源”这个经济学问题。 这一跳立不住，后面整个框架就是空中楼阁。

没有免费的可见性

让系统”被看见”，永远要花钱。只是花的形式不同，藏得深浅不同：

  • 你想看一条指标？它要被采集、传输、存储、索引。一万个序列乘以一年的保留期，是实打实的磁盘和内存。
  • 你想要一条告警？它要在某个深夜打断一个工程师，消耗他的睡眠、他的专注、他对告警系统的信任。
  • 你想让一段代码报告自己的行为？要有人去写那行 tracer.startSpan()，要有人维护它，要有人在系统演进时防止它腐烂。

存储、注意力、人力——“看见”是一笔支出，而且账单永远存在，只是有时记在机器上，有时记在人身上。 这是本篇的第一公理，也是最容易被忽视的一条：人们谈论可观测性时，总在谈”能看到什么”，很少谈”这一眼要花多少钱”。

两种稀缺品

这些支出最终都落到两种稀缺品上：

机器的资源——存储、算力、网络带宽。它的特点是有限、可计量、明码标价。一份全量采样的追踪数据、一个不设上限的高基数标签，会直接变成云账单上的数字。

人的注意力——工程师的认知带宽、on-call 的精力、对系统的信任。它的特点是更有限、更昂贵、且不可计量。你没法给”一次半夜被误报叫醒”开发票，但它真实地消耗着团队最稀缺的东西：清醒的、愿意继续相信告警的人。

这两种稀缺品之间存在一种隐秘的兑换关系：你可以花机器资源去省人——让系统存下更多上下文，工程师就不必靠记忆和猜测排障；你也可以花人去省机器——让工程师精心设计只埋最关键的探针，系统就不必存下海量数据。

认识论的经济学转译

到这里，那一跳就完成了。第一章的认识论问题——“我如何知道系统的状态”——在工程上等价于一个经济学问题：

我愿意在”机器资源”和”人的注意力”之间，以什么样的比例，购买多少可见性？

我把这个比例称为汇率。它是这一整篇文章的核心隐喻：在某个特定的时代、某个特定的团队、某个特定的系统规模下，“一单位机器资源”能换”多少单位人的注意力”，是有一个相对价格的。而一种运维范式，本质上就是在某个给定汇率下，关于”如何分配可见性预算”的一套方案。

为什么是”校准”而非”优化”

如果汇率是固定的，那运维就是一道一次性的最优化题——算出最优解，从此照做。但汇率不是固定的。

系统的规模在变（昨天三个服务，今天三十个）。存储的单价在变（十年前的高基数是奢侈，今天是日常）。团队的人数和能力在变。业务对可靠性的要求在变。每一个变量都在悄悄重新定价那个汇率。

所以正确的动词不是”优化”，是”校准”——像校准一架始终在轻微漂移的天平，你不是调一次就完事，而是随着两端重量的变化，不断地重新找平衡。运维工程的成熟，不在于你找到了某个”正确的范式”，而在于你始终知道此刻的天平偏向了哪边、是否还配得上当下的汇率。

三、五个校准维度：取舍究竟发生在哪里

“在人与资源之间校准”听起来仍然抽象。这一章把它拆开——校准不是一个笼统的动作，它具体发生在五根可滑动的标尺上。这五根标尺，就是运维工程那五个永恒命题（监控与可观测性反复在回答的同一组问题）的可度量形态——把”问题”磨成了”刻度”。它们既是本篇的分析框架，也是后面九篇文章的坐标系：每一种产品、每一个范式，都可以被定位成这五根标尺上的一组坐标。

框架总览

先看全貌。五个维度，每个维度都是一段从”省资源”到”省人/求洞察”的光谱：

维度取舍光谱偏资源端（省机器）偏提问端（求洞察）
① 故障的预判权人预判 ↔ 机器事后回答预先埋点、阈值告警高基数、事后任意提问
② 存储的汇率预聚合 ↔ 高基数时间序列、丢弃细节wide events、保留全量
③ 信号的分工单一信号 ↔ 四类信号协同指标为主指标/日志/追踪/分析各司其职
④ 注意力的阀门基于原因 ↔ 基于症状CPU>90% 就告警SLO 烧损速率才告警
⑤ 仪器化的负担手写 SDK ↔ 内核零侵入显式埋点自动注入、eBPF 零侵入

一种范式，就是这张表上的一行坐标。 下面逐一拆解每根标尺：它在量什么，两端各意味着什么取舍。

维度一 · 故障的预判权（人预判 ↔ 机器事后回答）

第一个、也是最根本的取舍是：“知道哪里会坏”这件事的认知负担，由谁来承担？

一端是让人预判。你在部署前就坐下来想：这个系统会以哪些方式失败？然后在那些位置埋下探针——磁盘会满，所以监控磁盘；依赖会超时，所以监控延迟。这套做法的隐含前提是：你对系统的了解，足以预先列出它的故障清单。

另一端是让机器事后回答。你不预测故障会从哪来，而是让系统保留足够丰富的原始信息，等故障真的发生了，再回过头去提问、下钻、重建现场。

这根标尺的本质，是 Rumsfeld 那个著名三分法在运维里的投影：

  • 已知的已知：你知道会坏、也知道怎么观察的。两端都能覆盖。
  • 已知的未知：你知道可能会坏、但不确定细节的。预判勉强能埋点，事后提问更从容。
  • 未知的未知：你根本想不到的故障模式——分布式系统里多个正常组件在特定条件下涌现出的异常。这一类，人的预判力天然失效，只能靠机器事后回答。

系统越复杂，“未知的未知”占比越高，预判权就越不得不从人移交给机器。这不是品味问题，是复杂度的物理。

维度二 · 存储的汇率（预聚合 ↔ 高基数）

第二根标尺量的是：为了能事后提问，你愿意存下多原始的数据？

一端是预聚合。指标系统在数据落盘之前，就把它压缩成时间序列——http_requests_total{status="200"} 每分钟一个采样点。在这一步，请求级别的细节（是哪个用户、哪个 IP、带了什么参数）已经被永久丢弃。代价是你只能问”过去一小时 P99 是多少”，问不出”慢的是哪 1% 的请求”。收益是成本低到可以忽略、查询快到可以实时。

另一端是高基数。你保留每一条原始事件，带着它全部的维度——用户 ID、设备型号、版本号、地理位置。于是你能问出”iOS 用户在 2.3.1 版本上的 P99 是否比 Android 高”这种指标系统永远答不出的问题。代价是存储成本是预聚合的数十到数百倍。

这里要立一个关键概念：基数（cardinality）是成本的物理量。 一个标签的取值越多（user_id 有百万种取值），它和其他标签的组合就越爆炸，存储与索引的开销就越不可控。可观测性世界里几乎所有的成本失控，都可以追溯到某个失守的高基数维度。“存得起一切”从来不是真的——它只是把”存不起”的边界往后推了几个数量级。

维度三 · 信号的分工（单一信号 ↔ 四类信号协同）

第三根标尺量的是：你动用几种信号，每一种买的是哪种洞察？

四类信号，各自回答一个不同的问题，各自有不可替代的盲区：

  • 指标回答”多少”和”多频繁”——QPS、延迟、错误率。它擅长趋势和告警，但答不出”是哪些请求导致 P99 升高”。
  • 日志回答”发生了什么”——某个事件的完整上下文。它适合”已知某时刻出了问题，需要理解细节”，但在分布式系统里缺少跨服务的因果链。
  • 追踪回答”为什么”——一次请求在多个服务间穿行的完整路径，每一跳耗时多少、阻塞在哪。它是分布式排查的唯一有效工具，但只能重建单次请求，答不出宏观趋势。
  • 持续分析回答”时间花在哪里”——代码级别的 CPU/内存热点，不是某次请求，而是持续运行的累计分布。它填补的是”追踪显示某跳慢、但看不进代码内部”的盲区。

每多动用一类信号，就多一笔资源支出，也多买一种洞察。没有哪种信号是全能的——这正是为什么成熟的系统是四类信号协同，而不是把宝押在一种上。这根标尺的本质，是你愿意为”看得更全”付多少种、多大的代价。

维度四 · 注意力的阀门（基于原因 ↔ 基于症状）

前三根标尺都在花机器资源。第四根，直接花的是那个最贵的稀缺品——人的注意力。

告警，是运维系统里唯一会主动打断人类的机制。所以它的设计，本质上是一道阀门：什么时候，才值得叫醒一个工程师？

一端是基于原因（cause-based）告警：CPU 超 90% 就告警，磁盘超 80% 就告警。这是监控时代的默认。它的问题是双向失准——CPU 高不一定有用户受影响（可能只是批处理），用户受影响也不一定 CPU 高（可能是数据库慢）。于是它同时产生误报（CPU 高但用户没事）和漏报（用户有事但没有任何原因指标过阈值）。

另一端是**基于症状（symptom-based）**告警：不告警”磁盘 80%“，告警”错误率升高、SLO 烧损速率超过阈值”——直接反映用户体验。Google SRE 的结论很硬：只对症状告警，不对原因告警；原因只用于故障时的辅助诊断，不用于触发人类介入。

这里有一个不对称要看清：误报和漏报的代价并不对等。 漏报让你错过真故障，误报则慢性地杀死告警系统——告警太多，工程师习惯性 silence，于是真正的故障被淹没在噪声里。衡量一个告警系统健康与否，不看告警数量，看 actionable rate：每一次告警，是否都既需要、又值得人去处理。这根标尺校准的，是你对团队注意力的尊重程度。

维度五 · 仪器化的负担（手写 SDK ↔ 内核零侵入）

前四根标尺讨论”看什么、何时叫人”，第五根讨论一个更基础的问题：让系统开口说话这件事本身，由谁来付成本？

信号不会凭空出现。必须有人写代码或配置，系统才会”开口”。这就是仪器化（instrumentation）的成本，也是可观测性落地的最大阻力。

这根标尺，是一条清晰的成本递降轨迹：

  • 手写 SDK：开发者在代码里显式调用——metrics.increment()、tracer.startSpan()。精确可控，但代码耦合、工作量大、随系统演进容易腐烂。
  • 框架自动注入：在不改业务代码的前提下，拦截框架层的调用（HTTP、数据库、消息队列）自动生成信号。覆盖了大部分常见场景，但对自定义业务逻辑无能为力。
  • 网格 / eBPF 零侵入：在代理层或内核路径上采集，不改代码、不重启进程、甚至不必知道应用是什么语言写的。代价转移到了平台的复杂度上——但对应用团队而言，仪器化成本逼近于零。

整条轨迹的方向只有一个：让”让系统开口”的人力成本越来越低，覆盖越来越广。 从手写到自动到零侵入，每一步都在把仪器化的负担，从应用开发者身上卸下来。

五维的统一性

到这里你可能觉得，这是五个并列的取舍清单。不是。它们共享同一个隐变量——人与资源的相对稀缺——拨动其中一根标尺，会牵动其余几根。

举一个例子就够了：当存储变便宜（维度二向高基数滑动），你就负担得起保留每一条原始事件；一旦原始事件都在，你就不再需要预先猜测故障会从哪来（维度一的预判权自然让渡给机器）；有了高基数的原始数据，你就能用症状而非原因来定义告警（维度四向症状端滑动）；而要采集这么多数据，手写 SDK 必然撑不住，逼着你走向自动化和零侵入（维度五向零侵入滑动）。

一根标尺动了，其余四根跟着动。 它们不是五个独立的旋钮，是同一个底层变量在五个面上的投影。这就是为什么”范式更替”从来不是单点技术的胜利，而是五个维度的坐标整体迁移——这也正好引出下一章。

四、汇率的漂移：三个时代是同一组标尺的三次定位

如果范式是五维标尺上的一组坐标，那么运维史上的”代际更替”，就是这组坐标的整体迁移。而驱动迁移的，是那个一直在漂的汇率——人与资源的相对价格。下面用同一个框架，定位三个时代。

经典范式：资源稀缺，坐标全偏资源端

回到二十年前。存储以 GB 计价且昂贵，算力金贵，但系统简单——一个单体应用，几台服务器，一个工程师能在脑子里装下整个架构。

在这个汇率下，机器资源贵、而人对系统的预判可靠，于是五维坐标整齐地偏向资源端：

  • 故障预判权交给人（系统简单，预判得准）；
  • 存储用预聚合（存不起原始数据，也不太需要）；
  • 信号以指标为主（够用了）；
  • 告警基于原因（阈值，简单直接）；
  • 仪器化手写（埋点不多，扛得住）。

02-监控-预知故障的经典范式、03-指标-时间序列的量化哲学、04-日志-结构化事件的叙事力量 是这套坐标的产物。它们不落后——在那个汇率下，它们是最优解。 今天在中小规模系统里，这套坐标依然成立。

云原生范式：资源廉价、人贵，坐标整体翻转

云原生改变了汇率的两端。存储变得极其廉价（对象存储以美分计），而系统复杂度爆炸（几十上百个微服务），人的认知带宽再也装不下整个架构——人，成了新的稀缺品。

汇率翻转，五维坐标整体翻向提问端：

这不是”更先进的技术战胜了落后的技术”，是汇率变了，最优解跟着变了。

未来范式：人极贵、成本反噬，第六根标尺浮现

把趋势再往前推。人会越来越贵——工程师的时间是 AI 时代最稀缺的东西；而资源虽然充裕，却开始反噬——可观测性数据的增速正在超过业务本身，“遥测比业务还贵”不再是笑话。

这个汇率会催生两件事。其一，机器接手协调本身：当人贵到一定程度，连”配置信号、判断告警”这件事都开始让渡给机器——这就是 AIOps 的方向（尽管今天它的成熟度仍然参差）。其二，框架本身要长出新的标尺：成本治理升格为第六根标尺。 前五根标尺隐含的前提是”资源足够便宜、可以挥霍”，而当成本开始反噬，“花多少”必须和”看多少”被放在一起权衡——按价值采样、自适应保留期，成为新的纪律。

关于这第六根标尺，本篇点到为止，它的展开见 MOC 第五节（运维的人与经济）与第六节（前沿雷达）。

漂移的规律

把三次定位放在一起看，规律就清楚了：它们不是一条”越来越好”的进步线，而是同一组标尺在不同约束下的三个取值。 经典范式在它的汇率下是对的，云原生范式在它的汇率下是对的，未来范式将在它的汇率下是对的。

这也正是这整个系列能被一根脊椎串起来的原因：后面九篇看似讲九种不同的技术，其实讲的是同一组标尺的不同刻度。读它们的时候，你只需要不断回到一个问题——这个技术，把五维坐标推向了哪边？为了应对什么样的汇率？

五、结论：判断你自己的稀缺

如果这一篇只能留下一句可操作的话，那就是：运维范式的选择，不是追新，是测量你自己系统的汇率。

错配的两种死法

把范式用在错误的汇率上，有两种典型的死法：

  • 小系统过度投资：一个百人团队、几个服务的产品，硬上分布式追踪、全量高基数、复杂的 SLO 体系——结果是可观测性的运维负担超过了它带来的洞察，团队被自己的工具拖垮。这是浪费。
  • 大系统投资不足：一个几十上百微服务、日均千亿调用的平台，还死守阈值告警和指标——结果是跨服务的性能退化根本定位不了，事故时对着一屏绿色干瞪眼。这是失明。

两种死法，都源于同一个错误：没有诚实地测量自己当下的汇率，就照搬了别处的坐标。

测量你的汇率

所以，在选型之前，先对着五根标尺做一次自检：

  1. 你的故障，多少是”已知的已知”，多少是”未知的未知”？（决定预判权该给人还是给机器）
  2. 你真的需要请求级的细节吗，还是聚合趋势就够？（决定预聚合还是高基数）
  3. 你现在缺的是哪种洞察——“多少”、“发生了什么”、“为什么”、还是”时间花在哪里”？
  4. 你的告警，actionable rate 是多少？工程师还信任它吗？
  5. 你的团队，仪器化的人力是瓶颈吗？

这五个问题的答案，就是你系统当下的真实坐标。 范式不该从别人的博客里抄，该从这五个答案里长出来。

校准是持续动作

最后，记住第二章那个词——校准，不是优化。

你今天测出的汇率，明年就会变：服务变多了，团队变大了，存储更便宜了，业务对可靠性的要求更高了。每一个变量都在重新给那架天平的两端称重。所以范式选择不是一次性的决定，是一个随系统演进不断重做的动作。昨天正确的坐标，今天可能已经偏了。

通往全系列

后面九篇文章，是这五维标尺上的一个个具体落点——经典三篇是偏资源端的坐标，云原生六篇是偏提问端的坐标。读每一篇的时候，请始终带着这一篇给你的那把尺子，回到同一个问题：

这一步，把人与资源的天平，推向了哪一边？

这把尺子，就是这整个系列共享的脊椎。

返回 可观测性与运维工程 MOC

关系图谱