1.5 数据来源与埋点

概述与动机

一个指标的可信度，取决于其底层数据的可信度，而大多数指标项目花在设计仪表盘上的精力，远远超过花在核实为其供数的流水线上的精力。这本末倒置。一张设计精美、却建立在不一致、自我报告或悄然损坏的埋点之上的图表，比没有图表还要糟糕，因为它看起来权威，实则错误。本主题要讲的，正是本书其余部分所假定的那个不那么光鲜的基础：工程数据究竟从何而来、什么时候该信任自动化埋点而不是自我报告，以及那些在无人察觉时悄然让一个指标失效的数据质量故障。

软件工程数据来自少数几类来源，每一类都有不同的可靠性特征。版本控制与CI/CD流水线生成的是客观、带时间戳、难以造假的实际发生记录。工单跟踪器与项目管理工具生成的记录，依赖于人类正确及时地更新状态，而人类做这件事往往并不一致。调查问卷生成的是自我报告数据，对于任何系统都无法观察的事物（例如满意度）而言弥足珍贵，但会受到回忆偏差与社会期许效应的影响。可观测性平台生成的是系统层面的遥测数据，客观，但只覆盖已被埋点的部分。知道某个指标的数据来自哪一类，就能知道该在多大程度上信任它，以及该留意哪些失效模式。

在企业与政府规模上，数据质量问题会累积，因为数据的源头与其在仪表盘上的最终用途之间，要经过多个系统、集成和转换，距离不断拉长。一个字段在源系统中意味着一件事，等它到达报告层时，可能已经意味着一件微妙不同的事，而下游没有人察觉，因为这个数字看起来依然合理。把埋点做对，不如把框架做对那样令人兴奋，但它正是本书其余一切内容所立足的基础。

核心原则

只要系统能够直接观察某个事件，就优先选择埋点，而不是自我报告。 来自流水线的部署时间戳，比团队自我报告的部署次数更可信。
只在无法直接观察之处使用自我报告。 满意度、感知到的摩擦与幸福感，都没有可替代的系统记录；直接询问，并把调查问卷设计好（主题 3.7）。把自我报告专门留给这一类。
每个指标的数据都有一个源系统、一种采集方法与一种已知的失效模式。 三者都要记录下来，而不只是定义。
数据质量会悄然衰变。 一年前正常运作的流水线，今天可能已经悄悄损坏了，而仪表盘会毫无怨言地继续渲染一个错误的数字。
在真相发生的那一点埋点，而不是在某次转译之后的下游。 事件与仪表盘之间的每一次跳转，都是含义漂移的一次机会。

建议

在信任某个指标之前，先把它映射到其真实的源系统

对仪表盘上的每一个指标，指名生成其底层事件的具体系统：部署事件对应CI/CD流水线，提交与合并事件对应版本控制托管平台，停机记录对应事故跟踪器，自我报告的满意度对应调查平台。如果你说不出确切的系统，你其实并不知道这个数字从何而来，也就无法评估它的可靠性。这种映射是主题 1.4 治理章程的前提条件，而不是一项独立的练习。

在事件发生处埋点，而不是在报告处

最可靠的数据，是在事件发生的那一刻自动捕捉的：流水线在部署完成的瞬间就记录一次部署，版本控制系统在合并落地的瞬间就记录一次合并。依赖人类事后记得去更新状态字段的数据（把工单标记为”完成”、把一次部署手动记录进电子表格）离实际事件的时间越远、负责人越忙碌，其准确性就越会下降。只要存在自动化事件，就优先选用它，而不是关于同一事实的人工报告代理。

把调查问卷留给只有人才能告诉你的事情

有些事情确实无法从系统遥测中观察到：工程师是否觉得自己的工作有意义、某个流程是否让人感到沮丧、耗竭风险是否在上升。这些都需要直接询问，而一份设计良好的调查问卷（机制见主题 3.7）正是合适的工具。真正的错误，是把自我报告用在了系统本可以直接观察的事情上（让工程师自己估算他们的部署频率，而不是直接从流水线中取数）这会把不必要的噪声和偏差，引入本可以是客观的数据之中。

把数据质量检查内建到流水线本身之中

用对待生产代码同样的严谨来对待指标流水线：添加自动化检查，在某个来源停止发送数据、某个字段的分布出现意外偏移，或某个计数意外归零时予以标记。一个悄悄把陈旧或损坏的数据渲染得像是最新数据一样的仪表盘，比一个明确显示”数据不可用”的仪表盘更糟糕，因为前者在无形中侵蚀信任，而后者至少如实说明了自身的局限。

把采集方法与定义一并记录下来

一个指标的定义（“变更的交付周期”）如果没有其采集方法（从版本控制中的首次提交时间戳，测量到流水线中的生产部署时间戳，不含热修复分支），就是不完整的。两个团队即便拥有相同的定义，只要采集方法不同，产生的数字依然不可比。把两者都记录在主题 1.4 所述的指标章程中，并把对其中任何一者的变更，都当作需要同等文档化评审的变更来对待。

权衡取舍：利与弊

来源类型	优点	缺点
自动化流水线埋点（CI/CD、版本控制）	客观、带时间戳、难以造假、持续投入低	需要前期的工程投入来构建与维护
工单跟踪器与项目管理数据	广泛可得，团队熟悉	依赖人类的勤勉；跨团队往往不一致
调查问卷与自我报告	主观体验（满意度、幸福感）的唯一来源	回忆偏差、社会期许偏差、应答疲劳
可观测性与遥测平台	丰富、实时、系统层面的信号	只覆盖被明确埋点的部分；在规模上可能昂贵

核心张力是客观性与覆盖面之间的张力。自动化埋点是最可信的来源，却完全无法观察主观体验，而调查问卷恰恰能触及自动化触及不到之处，却带有真实的偏差风险。解决之道是：只要事件能被直接观察，就使用自动化埋点，把自我报告专门且只留给那些真正需要询问一个人才能得知的事情，绝不能把它当作系统本可以提供的数据的偷懒替代品。

与团队讨论的问题

对我们最重要的五个指标而言，我们能否为每一个都说出确切的源系统与采集方法，还是我们只是假定了一个定义，却不知道数据究竟从何而来？ 这是一个出人意料地常见的缺口：一个指标是从某个框架或供应商的默认仪表盘中采纳而来的，而当前团队中没有人真正知道究竟是哪个系统、以何种方式生成了底层数据。把每一个都追溯回其源头，作为一次团队练习。
我们的哪些指标，在系统本可以直接观察的事情上依赖自我报告，要用真正的埋点取代这种自我报告需要做什么？ 自我报告的部署次数、自我报告的工作时长，以及自我估算的周期时间，都是把错误的数据来源用于自动化本可以更可靠地捕捉之事的常见例子。找出这些情形，优先替换风险最高的那些。
如果我们的某条数据流水线悄悄坏掉了，我们要怎样才能知道？ 大多数组织只有在有人察觉某个数字看起来不合理时，才会发现一条损坏的指标流水线，而这可能需要数月之久。讨论一下你们目前是否有任何流水线配备了自动化健康检查，如果没有，哪些流水线最需要优先配备。
在哪些地方，系统之间的一次转译在无人刻意决定的情况下改变了某个指标的含义？ 一个字段在源系统中意味着一件事，在经过一次集成或迁移之后，可能已经意味着一件微妙不同的事，而由此产生的数字可能看起来合理，实则错误。走一遍你最具重要性的指标的完整数据路径，寻找转译点。
在我们的指标章程中，我们记录的是采集方法，还是仅仅记录了定义？ 两个团队可能共享一个指标的名称和定义，却用不同的采集方法计算它，产生实际上并不可比的数字。用这个具体的缺口，抽查一批你的章程。
当一个数字出现意外变动时，我们如何区分真实的趋势与数据质量的假象？ 一个指标的突然变动，往往是真实变化或流水线损坏这两者之一的第一个迹象，而要区分两者，需要对数据来源有足够深入的了解，才能迅速展开调查。讨论一下你们团队应对上一次无法解释的指标变动时的真实处理过程。

行业视角

初创公司。 在一套小型技术栈下，你的大多数指标可以直接来自你的CI/CD提供商、版本控制托管平台，以及一个轻量级的调查工具，无需构建定制流水线。真正的风险是因为团队追求速度而跳过哪怕最基本的健康检查；一个五分钟的自动化检查，确认某个数据来源仍在发送事件，是防止在无形中陷入盲目状态的廉价保险。

小型企业。 依靠你现有工具的内置报告功能，而不要构建你没有能力维护的定制数据流水线。要明确说明哪些数字来自自动化系统，哪些是有人手动输入到电子表格中的估算，因为即便两者最终出现在同一页面上，其可靠性也大不相同。

企业。 数据质量问题会在集成、迁移和业务单元边界之间累积。为你最具重要性的指标投资建设集中、监控良好的数据流水线，把自动化数据质量检查建成标准实践，并且每当在业务单元之间比较指标时，都要审计采集方法，而不仅仅是定义。

政府。 数据溯源可能带有法律和审计上的分量：一项已发布的绩效数字，可能不仅需要经得起对其数值本身的外部审计，还需要经得起对其整条采集链条的审计。明确记录数据谱系，即便方法论发生变化，也要保留历史采集方法记录，并做好准备，随时展示某个数字究竟是如何被生产出来的，而不仅仅是它当前读数是多少。

案例

企业。 一家金融服务公司的工程领导层，在追踪”变更的交付周期”两年之后才发现，十八个月前的一次数据流水线迁移，已经悄悄把时间戳的来源从首次提交切换成了拉取请求创建，使得每个团队的表观交付周期平均缩短了数小时，而没有任何人察觉或批准这一变更。修复方案建立了一项数据质量检查，逐周比较每个指标的分布，并为统计上异常的变动标记出来供人工审查，在随后一年内又抓住了另外两个悄然存在的流水线问题。

政府。 一家交通机构面向公众的服务可靠性仪表盘，依赖自动化传感器遥测与地区办公室手动录入的事故报告混合而成。一次审计发现，人手较为不足的地区正在系统性地少报轻微事故，并非出于不诚实，只是因为手动录入要与更紧迫的工作争夺时间，这意味着已发布的可靠性数字，恰恰在那些最经不起维护不足被忽视的地区，比现实情况更好看。该机构的修复方案是在可行之处，用自动化的、由传感器触发的记录取代手动事故录入，并在已发布数字旁附上一份文档化的手动报告覆盖率估算。

商业理由：动机、投资回报与总拥有成本

扎实埋点的回报是信心：一个信任自己数据的领导团队，能够果断地据此行动，而一个曾被悄悄损坏的流水线灼伤过的团队，会开始质疑每一个数字，这会拖慢每一个依赖指标的决策。这种信心的丧失代价高昂，也难以修复，重建起来往往比最初的埋点投入所需的时间长得多。

优质埋点的总拥有成本，包括构建可靠流水线的前期工程工作，以及数据质量监控的持续成本，这两者都很容易被投入不足，因为它们都不会自己产出一块显眼的仪表盘瓷砖。这种投入不足是一种虚假的节省：在数月的决策都是基于错误数据做出之后才发现一条悄然损坏的流水线，其代价远高于一开始就构建本可以抓住它的健康检查的成本。

反模式与陷阱

不知道来源系统就信任一个数字： 一个从框架或供应商默认设置中采纳的指标，从来没有人追溯过数据究竟从何而来。
对系统本可以直接观察之事使用自我报告： 把不必要的噪声和偏差引入本可以是客观的数据之中。
指标流水线没有自动化数据质量检查： 一条悄然损坏的流水线，可能在数月之内持续渲染错误数字而无人察觉。
只记录定义，不记录采集方法： 两个使用相同指标名称的团队，仍可能在计算出不可比的数字。
一个把”0”或陈旧数据渲染得像最新数据、却没有任何来源故障提示的仪表盘： 比一条明确的”数据不可用”提示更糟糕。
资源不足的地区或团队因手动录入负担而系统性地少报： 一个恰恰与最需要关注的领域相关联的数据质量缺口。

成熟度模型

第一级，启动： 没有人能可靠地将某个指标追溯回其源系统；流水线没有健康检查，故障无人察觉。
第二级，发展： 部分指标有文档化的来源，但采集方法不一致，数据质量检查充其量只是临时的。
第三级，标准化： 每一个受治理的指标都记录了其源系统与采集方法；只要事件能被直接观察，就优先选用自动化流水线，而不是自我报告。
第四级，管理： 自动化数据质量检查监控着每一条具重要性的流水线，为异常标记以供审查，数据谱系被记录并可审计。
第五级，协奏： 组织把数据质量当作一门具有自身监控与事件响应的一流工程学科来对待，并能按需展示任何已发布指标的完整来龙去脉。

讨论思路

此时此刻，在这次会议上，我们能否现场把我们前三大指标追溯回其确切的源系统？
我们当前的哪些指标，在系统本可以直接测量的事情上依赖自我报告？
我们今天有任何指标流水线配备了自动化健康检查吗？
我们上一次发现一条悄然损坏的数据流水线是什么时候，它已经错了多久？
手动数据录入在哪些地方，制造了报告结果与实际现实之间的落差？

要点回顾

只要系统能够直接观察某个事件，就优先选择自动化埋点，而不是自我报告；把自我报告留给真正主观的体验。
每个指标都需要一份文档化的源系统与采集方法，而不只是一份定义。
数据质量会悄然衰变；把自动化检查内建到流水线本身之中，而不是靠意外发现损坏。
在事件发生处埋点，而不是在某次转译之后的下游，以最小化”实际发生之事”与”仪表盘所显示之事”之间的漂移。
一条悄然损坏的流水线所造成的代价（数月基于错误数据做出的决策）远超本可以抓住它的健康检查的成本。

参考文献与延伸阅读

Observability Engineering，Charity Majors、Liz Fong-Jones、George Miranda著（埋点与遥测设计原则）。
Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（DORA指标背后的埋点方法）。
Data Quality: The Accuracy Dimension，Jack E. Olson著（可应用于指标流水线的数据质量概念）。
How to Measure Anything，Douglas W. Hubbard著（针对看似难以直接观察之量的衡量方法）。