L1-1 · 可观测性的原始定义：从 Kalman 到 Honeycomb

TL;DR · 本文论证：observability 不是工具的清单，是被观测系统的一个数学性质——这件事六十年前 Kalman 就讲清楚了，我们后来弄丢了。 · 写给已经在用 Prometheus / Datadog / Honeycomb 但没认真想过"为什么"的工程师与架构师。 · 不读会错过：为什么 dashboard 加得越多反而越说不清状态、为什么"接入了可观测平台"≠ 可观测做完了、为什么 SLO + error budget 是 SRE 体系的真正核心。

很多人——包括做了多年可观测平台的工程师——以为"observability"这个词起源于云原生时代。其实它早于互联网、早于 Linux、早于 Unix，甚至早于阿帕网。1960 年，一个匈牙利裔美国工程师在控制论里写下了它，作为一个严格的数学性质。

这件事重要，不是因为它有怀旧价值。它重要，是因为今天我们用"可观测性"这个词时遇到的所有混乱——为什么厂商卖的"可观测平台"听起来更像在卖工具，为什么 dashboard 越多反而越说不清系统状态，为什么"加日志"似乎永远不够——都可以追溯到一件事：我们把它的原始定义弄丢了。

这一篇要做的，就是把它捡回来，再看看它能解释什么。

1. Kalman, 1960：可观测性是被观测对象的一个性质

1960 年，Rudolf Kalman 在国际自动控制联合会（IFAC）第一届世界大会上提交了 “On the General Theory of Control Systems”（Proceedings of the First IFAC Congress, Moscow, 1960）。

在这篇论文以及随后几年的工作（特别是 1963 年的 “Mathematical Description of Linear Dynamical Systems”, SIAM Journal on Control）中，他确立了两个孪生概念：controllability（可控性）和 observability（可观测性）。

定义粗略说是这样的：

给定一个动态系统，如果通过有限时间内的输出序列 y(t)，能够唯一确定其内部初始状态 x(0)，那么这个系统就是可观测的。

这个定义里有三件事容易被忽略。

第一，它是被观测系统本身的性质，不是观测者的性质，也不是工具的性质。一个系统要么可观测、要么不可观测，取决于它的状态空间结构、输出方程、是否存在看不见的隐藏状态。

第二，它在原始定义里是一个二元判定，不是程度。当代工程界说"我们的系统可观测性还不够"，使用的其实是一个被泛化、被工程化的版本。

第三，它与可控性是对偶的——两个性质在数学上互为镜像，一个回答"能否看清内部"，一个回答"能否驱动到任意状态"。一个无法被驱动的系统再可观测也没用，一个无法被看清的系统再可控也是盲目操作。它们成对出现绝非偶然。

第三点是当代可观测话语里被遗忘的部分。后面 §4 会回到它。

flowchart LR
    U["输入 u(t)"] --> SYS["系统
(内部状态 x(t) 不可见)"]
    SYS --> Y["输出 y(t)"]
    Y -.->|"能否唯一反演 ?"| X0["内部初始状态 x(0)"]
    classDef hidden stroke-dasharray:5 5,fill:#f5f5f5
    class X0 hidden

图 1·Kalman 的可观测性：通过有限的输出序列 y(t)，能否唯一确定不可见的内部状态 x(0)。

flowchart LR
    subgraph O["Observability  可观测性"]
        direction LR
        O1["内部状态"] -->|"产生"| O2["输出"]
        O2 -.->|"反演"| O1
    end
    subgraph C["Controllability  可控性"]
        direction LR
        C1["输入"] -->|"驱动"| C2["内部状态"]
    end
    O <-.->|"数学对偶"| C

图 2·两个孪生概念：一个回答"能否看清内部"，一个回答"能否驱动内部"。当代可观测体系经常只补一边。

2. 中间的五十年：术语的睡眠

从 1960 到 2010 年前后，observability 这个词主要活在控制论、系统工程、机器人、过程控制（化工、电网、航天）这些领域。IT 运维领域几乎不用这个词——我们用的是 monitoring、alerting、logging、APM。

但工业界对"系统状态可推断性"的关注其实从未停过——只是它穿了别的衣服。SNMP、syslog、Nagios、Munin、StatsD、Graphite 都是这个谱系上的努力。它们共享一个隐含预设：你提前知道要监控什么。设阈值、画曲线、收告警——这是已经识别了问题模式的工程实践。

后来我们才意识到，这个预设正好是 monitoring 和 observability 的分水岭。

直到分布式系统的复杂度突破某个临界点。

timeline
    title observability 一词的旅行
    1960 : Kalman 在 IFAC 大会提出 controllability / observability
    1960–2010 : 术语沉睡于控制论 / 系统工程 / 过程控制
              : IT 运维使用 monitoring / logging / APM
    2013 前后 : 分布式系统复杂度突破临界点
             : Twitter / Netflix / Google 内部借用术语
    2017 : Charity Majors / Honeycomb 把它立为工程哲学
    2020+ : OpenTelemetry 标准化遥测数据
    今天 : 三支柱占主流但开始自我解体

图 3·observability 这个术语从控制论旅行回到分布式系统的时间线。

3. 2013–2017：术语的重激活

分布式系统让 monitoring 范式开始失效。

一次请求穿越十几个服务，每个服务有几十个实例，部署在不同 region、连着不同版本的依赖。当一个 p99 突然飙高，没有人能提前画出"这个具体场景"的 dashboard——因为场景本身是组合爆炸的。

2013 年前后，Twitter、Netflix、Google 内部开始有人把 Kalman 的术语借过来描述这种新的需求。Zipkin 的早期推广（Adrian Cole 等）、Borgmon / Monarch 的内部文档都开始重新使用 observability 这个词。

到 2017 年前后，Cindy Sridharan 的系列博客和后来的 O’Reilly 报告 Distributed Systems Observability 把这种用法系统化、扩散到更广的工程圈。

但真正把它立成一种工程哲学、让它从控制论术语回到主流工程视野的，是 Charity Majors 与 Christine Yen 在 2016 年共同创立的 Honeycomb。从 2017 年起，Charity 发表了一系列博客文章，做了一件关键工作：她把 Kalman 的数学定义翻译成了工程从业者能用的语言。

她的翻译是这样的：

Monitoring 是为已知的未知（known-unknowns）准备的——你预先知道要问什么问题。 Observability 是为未知的未知（unknown-unknowns）准备的——你不知道要问什么问题。

这是一句话级别的洞察。它把"系统状态能否被推断"这个数学问题翻译成了"系统能否回答未曾预设的问题"这个工程问题。两个问题严格说不完全等价，但等价的程度足够支撑一种新的产品哲学。

围绕这个核心，Charity 给出了三个操作化标准：

• 高基数（high cardinality）：能携带高基数维度（user_id、build_sha、experiment_id），否则提不出细粒度问题。
• 高维度（high dimensionality）：每个事件能携带任意多个维度，否则维度组合被预先限制。
• 可探索（explorable）：能在查询时任意切换维度、做 group by 和 filter，而不是只能看预设 dashboard。

我读到这三条的时候反应是：“这其实就是 Kalman 原始定义的工程语言版本”——它们都是关于状态空间分辨率和反演自由度的。Charity 在 Observability Engineering（O’Reilly, 2022）里把这三条系统化成了一种产品哲学，我大体同意，但在 dashboard 那一节有点保留：她倾向于把 dashboard 几乎贬为反模式，我觉得更准确的说法是"dashboard 是 monitoring 的合法形态，只是不应该被当作可观测的全部"。这一点 §4 误读二会展开。

4. 现代误读：三件被丢掉的东西

理解了原始定义之后再回头看主流话语，你会发现有三件事被悄悄丢掉了——而这些丢失正是当下混乱的根源。

误读一：它是对象的性质，不是工具的清单

当一家厂商说"我们提供可观测平台"，严格说他们卖的是观测工具（observation instruments），不是 observability。Observability 永远是被观测系统的属性。

这听起来像文字游戏，但其实不是。买一个 Datadog 不会让你的系统变得可观测，正如买一个示波器不会让一个电路变得可被诊断——如果系统本身没有暴露足够的内部状态信号，再贵的工具也只能采集噪音。

这也解释了"接入可观测平台 = 可观测做完了"这个常见错觉。真正的工作在于让系统本身愿意被看：埋点、attribute 设计、上下文传播、敏感字段治理——这些是软件设计层面的工作，工具只是看的方式。

误读二：可观测性回答的是未预设的问题；dashboard 是已预设问题的固化

每加一个 dashboard，你都在把一个"未知未知"降级成"已知未知"。这件事本身有价值——它是 monitoring 的正当工作。但一旦你的可观测体系只剩下 dashboard，你已经悄悄地从可观测性退回到 monitoring。

可观测性的核心能力不是"看着仪表盘"，而是"能在事故现场提出一个从没人想过的问题，并立刻得到答案"。Honeycomb、ClickHouse / Apache Doris on events 这一脉路线在数据模型上选择宽事件而非预聚合指标，背后的考虑就是这个：预聚合把问题预先固化，宽事件把可问性留在查询时。

误读三：观测的目的是控制，而不是凝视

Kalman 原始论文里，observability 和 controllability 永远配对。但当代可观测体系经常只补一边——只观测、不控制。

关键洞察： 如果你能看到内部状态但不能据此调整系统，你的观测仅仅是审美活动。

翻译成工程语言：

• 一个没有部署管控、没有降级开关、没有熔断与限流的系统，再多 telemetry 也只是事故的实况转播。
• SLO + error budget 是 SRE 体系的核心，正是因为它构成了观测—决策—行动的反馈闭环。
• AIOps、自愈、闭环根因分析这些当下热词，本质都是在补齐"观测对应控制"那一半。

我见过几家公司在 observability 上加了 10 倍预算，但事故率几乎没变——因为运维响应能力没变。这种投入换来的是更高清的事故录像，不是更少的事故。

5. 三个数学回声：Kalman 怎样仍在影响今天

把 1960 年的数学性质和今天的可观测平台并置，能听到三个清晰的回声。

回声一·状态可推断性 → trace + log 能否还原系统当时在想什么

工程上的 debugging 体验，本质上就是 Kalman 意义上的状态反演。一条 trace、它的所有 span 属性、它周围的日志，能否让你唯一确定故障时刻的系统状态？“唯一"是奢望，但它给出了一个判别尺度——你的可观测覆盖里是否还有结构性盲区。

回声二·可控性对偶 → 没有 actuator 的观测体系不构成闭环

任何观测体系都应被追问一个问题：你看到 X 之后能做什么？如果答案是"没法做什么"或"只能告警让人来做”，那么你缺少 Kalman 意义上的 controllability 那一半。

回声三·状态空间维度 → cardinality 之争是分辨率之争

为什么所有可观测后端最终都被"基数"这个词困住？因为基数等价于状态空间的分辨率——低基数是粗粒度划分（同 region 的所有用户被看成一个状态），高基数是细粒度（每个用户、每个会话都是一个状态点）。基数的代价就是分辨率的代价，这是物理约束，不是工程缺陷。L1-3 全篇会展开这一条。

这三个回声会贯穿 L1 剩余三篇：L1-2 用"回声一"解构三支柱，L1-3 深挖"回声三"，L1-4 追问当被观测对象是 LLM 时这三个回声是否还成立。

flowchart TD
    K["Kalman 1960
可观测性 = 输出反演状态"]
    K --> E1["回声一
状态可推断性"]
    K --> E2["回声二
可控性对偶"]
    K --> E3["回声三
状态空间维度"]
    E1 --> M1["trace + log
能否还原系统状态"]
    E2 --> M2["观测必须配 actuator
否则不构成闭环"]
    E3 --> M3["cardinality 之争
= 状态空间分辨率之争"]
    M1 -.->|"展开"| L12["L1-2  三支柱解构"]
    M3 -.->|"展开"| L13["L1-3  采样的认识论"]
    M3 -.->|"延伸"| L14["L1-4  LLM 状态空间"]

图 4·三个数学回声如何映射到后续三篇正文。

6. 自我证伪

如果以下任一条件成立，本文的核心论证就会塌陷： ① 如果 Kalman 的 observability 定义只是"经典控制论的一个旁支技术性质"，与工程实践完全无关——那么我把它当作锚点就是过度类比。反驳： 这一条至少在状态推断和基数这两点上无法成立，状态空间论本来就是工程上的基础语言。 ② 如果"被观测对象不是动态系统"——比如纯静态资源（文件、配置），那么状态可推断性不是核心问题。反驳： 这种场景确实存在（配置审计），但绝大多数生产系统是动态的。 ③ 如果未来 LLM 应用让"系统能直接自述自己出错了什么"——那么外部观测的整个范式都被颠覆。这一条我无法反驳，但它远未发生，且即使发生，“自述"本身也需要被可观测才可信。

7. Key Takeaways

• Observability 是被观测系统的性质，不是观测工具的清单——这是这一切的锚点。
• 三个数学回声仍在主导今天的设计：状态可推断性、可控性对偶、状态空间维度。
• Dashboard 是 monitoring 的合法形态，但只剩下 dashboard 就是退化。
• 没有 actuator 的观测体系不构成闭环——再多 telemetry 也只是高清的事故录像。
• 每次有人说"我们可观测做完了”，正确的回应是问"做完了什么状态推断？"

8. 通向下篇

把可观测性还原为"系统的一种性质"——而非"一组工具的清单"——之后，一个尴尬的问题浮现：

如果可观测性是一个性质，为什么我们需要三套独立的系统（metrics、logs、traces）来表达它？为什么它被切成"三支柱"？这种切分有理论依据，还是只是历史路径依赖和厂商惯性？

下一篇 L1-2 回答这个问题。

参考

• Kalman, R. E. (1960). On the General Theory of Control Systems. Proceedings of the First IFAC Congress, Moscow.
• Kalman, R. E. (1963). Mathematical Description of Linear Dynamical Systems. SIAM Journal on Control, 1(2), 152–192.
• Majors, C. (2017). Monitoring and Observability. Honeycomb blog (Sep 2017).
• Majors, C., Fong-Jones, L., & Miranda, G. (2022). Observability Engineering: Achieving Production Excellence. O’Reilly.
• Sridharan, C. (2018). Distributed Systems Observability. O’Reilly Report.