Pulse 自托管商业面证据审计：Telemetry 遥测聚合查询的取证重建与可复现性核查
Pulse 自托管商业面证据审计：Telemetry 遥测聚合查询的取证重建与可复现性核查
导读：本文以 Pulse v6 发布控制体系中的一份证据审计记录（self-hosted-commercial-surfaces-evidence-audit-2026-08-08.md）为主线，完整还原其基于
telemetry_pings表的 SQLite 只读取证查询方法、聚合脱敏快照的解读方式，以及"精确数值不可复现"这一结论如何推动后续产品决策。读完本文，你将掌握一套可复用的"遥测数据取证审计"方法论：如何用窗口函数做去重、如何从资源规模阈值推断商业分级、如何区分"当前状态关联"与"转化因果"，以及如何把审计结论转化为发布门禁依据。
这份审计记录解决的是什么问题
2026-08-07，Pulse v6 发布控制体系中存在一份名为 self-hosted-commercial-surfaces-revision-2026-08-07.md 的修订记录，其中标注了一个 Richard-approved 的批准标签，并引用了一批未被记录的 telemetry 读取结果（如 9,421 个安装、671 个企业级环境、月新增付费订阅等）作为"产品方向反转"的决策证据。本审计记录（2026-08-08）的任务就是回答一个最基础也最严格的问题：
这批数字和标签能否从仓库中可追踪的证据链里重新算出来？
审计结论是"exact rationale not reproducible"（精确依据不可复现）：当前追踪文件、全部可达 git 历史、commit message 与 git notes 中都不存在能复现这些精确数值的查询、快照或报告，也不存在能确认项目所有者批准该反转的制品。这份审计因此成为后续治理动作的基石——它在 self-hosted-commercial-surfaces-revision-2026-08-07.md 中被引用为取证重建来源，并最终支撑了 2026-08-08 的"opt-in 姿态回滚"与 2026-08-20 的"business tier 正式上线"两次独立的项目所有者决策。
审计的取证边界与数据处置原则
审计记录在开头就明确了自己的证据边界：
| 项 | 取值 |
|---|---|
| 审计日期 | 2026-08-08 |
| 被审计记录 | self-hosted-commercial-surfaces-revision-2026-08-07.md |
| 测试截止点 | 2026-08-07T12:47:46Z |
| 结果 | exact rationale not reproducible |
| 数据处理 | 仅聚合读取（aggregate-only read），不返回任何安装、客户、订阅或资源标识符 |
数据来源链路被严格记录：
- 源仓库：
pulse-pro@6fa9bc6dc2c2df917c16964a0305d41967162f1f - 源表结构：
license-server/main.go中的telemetry_pings表 - 访问路径：受追踪的固定主机包装脚本
pulse-pro/scripts/license_ssh.sh - 查询模式：SQLite
-readonly（只读） - 测量时间：
2026-08-08T01:47:00Z - 原始查询/快照：
not found
这里最值得注意的一点是：审计本身没有宣称自己拿到了"原始查询"。它定位到的只是"可用证据"，并明确承认原始查询或快照不存在。这体现了证据审计与普通数据分析的本质区别——审计的目标不是"算出某个数字"，而是"确认某个数字能否被证据支撑"。
审计还做了全域搜索确认：在 pulse 和 pulse-pro 中搜索了当前追踪文件、所有可达 git 历史、commit message 和 git notes，均未发现支撑精确数值的证据，且两个仓库中不存在 git notes 命名空间。
取证重建查询：SQL 逐段拆解
审计记录给出了一个"净化重建查询"（sanitized reconstruction query），并特别声明：这是一个取证重建（forensic reconstruction），不代表原始查询，且只返回聚合计数。这一点极其重要——它确保审计过程本身不引入新的隐私暴露。
第一阶段：取每个安装最近一周的 ping
WITH latest AS (
SELECT
p.*,
ROW_NUMBER() OVER (
PARTITION BY p.install_id
ORDER BY p.received_at DESC, p.rowid DESC
) AS rn
FROM telemetry_pings p
WHERE p.received_at >= datetime('2026-08-07 12:47:46', '-7 days')
AND p.received_at < '2026-08-07 12:47:46'
AND COALESCE(p.version_is_development, 0) = 0
), classified AS (
...
)
这段 CTE 做了三件事：
- 时间窗过滤：只取
2026-08-07T12:47:46Z往前 7 天的 ping。这里的datetime('2026-08-07 12:47:46', '-7 days')是 SQLite 的日期时间函数，表示截止时间减去 7 天。 - 非开发版本过滤：
COALESCE(p.version_is_development, 0) = 0排除开发/手工构建的版本。这一列在 Pulse 的遥测载荷中是真实存在的字段——见 internal/telemetry/telemetry.go 中Ping结构体的VersionDevelopment bool json:"version_is_development"字段（注释为 "True for development/manual builds"），以及旁边的VersionPublished（version_is_published_release）字段。也就是说，审计重建中"非开发"与"已发布"两种过滤都能从真实遥测字段映射出来。 - 按安装去重：
ROW_NUMBER() OVER (PARTITION BY p.install_id ORDER BY p.received_at DESC, p.rowid DESC)对每个install_id按接收时间（并列时按行号）倒序编号，取rn = 1的行，即每个安装最近一次 ping。这是把"每周活跃安装"定义成"过去 7 天内至少有一个非开发 ping 的不同 install_id 集合"的关键。
第二阶段：按资源规模阈值分级
classified AS (
SELECT
CASE
WHEN COALESCE(pve_nodes, 0) >= 5
OR COALESCE(docker_hosts, 0) >= 10
OR COALESCE(vmware_hosts, 0) >= 3
THEN 1 ELSE 0
END AS business,
CASE WHEN COALESCE(paid_license, 0) != 0 THEN 1 ELSE 0 END AS paid
FROM latest
WHERE rn = 1
)
分级逻辑非常直白：pve_nodes >= 5（至少 5 个 Proxmox VE 节点）、docker_hosts >= 10（至少 10 个 Docker 主机）、vmware_hosts >= 3（至少 3 个 vSphere/VMware 主机），三者任一命中即被归类为 business（企业级环境）。paid_license != 0 标记为已付费安装。
这三类资源计数在 Pulse 的真实遥测载荷中同样存在，见 internal/telemetry/telemetry.go：PVENodes、DockerHosts、VMwareHosts 等字段均有 JSON 标签（pve_nodes、docker_hosts、vmware_hosts），且注释明确写着 "Scale (counts only — no names, IPs, or identifiers)"——遥测载荷只含计数，不含任何名称、IP 或标识符。这正是审计能安全做聚合分级的数据基础。
第三阶段：聚合输出
SELECT
COUNT(*) AS installs,
SUM(business) AS business_estates,
SUM(CASE WHEN business = 1 AND paid = 1 THEN 1 ELSE 0 END) AS business_paid,
ROUND(
100.0 * SUM(CASE WHEN business = 1 AND paid = 1 THEN 1 ELSE 0 END)
/ NULLIF(SUM(business), 0),
4
) AS business_paid_pct,
SUM(CASE WHEN business = 0 AND paid = 1 THEN 1 ELSE 0 END) AS smaller_paid,
ROUND(
100.0 * SUM(CASE WHEN business = 0 AND paid = 1 THEN 1 ELSE 0 END)
/ NULLIF(SUM(CASE WHEN business = 0 THEN 1 ELSE 0 END), 0),
4
) AS smaller_paid_pct
FROM classified;
输出指标包括：安装总数、企业级环境数、企业级中已付费数量、企业级付费占比（保留 4 位小数）、小型环境付费数量与占比。NULLIF(SUM(...), 0) 用于避免除零——当分母为 0 时返回 NULL 而非报错。
前 GA 对比查询
审计还给出了前 GA（pre-GA）对比所用的独立查询，它只算"每周活跃安装"的去重计数，并以参数化截止点运行：
SELECT COUNT(DISTINCT install_id)
FROM telemetry_pings
WHERE received_at >= datetime(:cutoff, '-7 days')
AND received_at < :cutoff;
COUNT(DISTINCT install_id) 直接表达"过去 7 天活跃的不同安装数"，:cutoff 是参数占位符。这个查询的存在是为了验证 GA 前基线的稳定性。
净化快照：如何解读这张表
审计输出的净化快照如下：
| 截止点与过滤 | 每周活跃安装 | 企业级环境 | 企业级付费 | 企业级付费占比 | 小型付费 | 小型付费占比 |
|---|---|---|---|---|---|---|
| Landing commit，非开发 | 9,426 | 672 | 53 | 7.8869% | 86 | 0.9824% |
| Landing commit，已发布非开发 | 9,424 | 672 | 53 | 7.8869% | 85 | 0.9712% |
| 2026-08-07 日末 UTC，非开发 | 9,527 | 672 | 53 | 7.8869% | 83 | 0.9373% |
解读这张表要抓住几个要点：
- 企业级环境的三个口径完全一致（672、53、7.8869%），说明"资源规模阈值分级"对过滤条件（非开发 vs 已发布非开发）不敏感——企业级环境几乎全部是发布版本安装。
- 每周活跃安装数随过滤口径小幅波动（9,426 vs 9,424 vs 9,527），说明"开发构建"与"未发布版本"在整体活跃盘里只占极小比例，但确实存在。
- 小型付费占比逐行下降（0.9824% → 0.9712% → 0.9373%），提示小型环境的付费渗透在 7 天窗口内存在少量流动（例如部分小型安装的 ping 落在窗口外）。
而前 GA 对比则暴露了一个严重问题——基线对截止点极度敏感：
| 截止点 | 每周活跃安装 |
|---|---|
2026-07-04T00:00:00Z |
362 |
2026-07-05T00:00:00Z |
958 |
同样是"前 GA"，截止点只差一天，结果却从 362 跳到 958（约 2.6 倍）。这说明 GA 日期边界附近存在大量一次性 ping（典型如升级后立即上报），任何未精确记录截止点的"前 GA 基线"都无法作为可靠的决策分母。审计记录的 Findings 第 3 条正是据此指出："pre-GA baseline lacks an exact cutoff and changes substantially across the GA date boundary。"
schema-v8 的时序问题
审计还核查了 business_estate 这一存储列的时间线：审计时点 schema-v8 行只有两条，首条接收于 2026-08-08T00:10:01Z；私有 landing commit 明确新增了存储的 business_estate 列但没有回填（without backfill）。这意味着原始记录中基于 business_estate 的分类口径在列被写入生产之前不可能存在，原始 2026-08-07 的数字只能从更早的资源计数（pve_nodes / docker_hosts / vmware_hosts）推导。这一时间线证据直接否定了"business_estate 是原始数字来源"的可能性。
五项核心发现：从数字到结论的严格推理
审计的五项发现构成了全文的结论骨架，逐条对应证据链的缺口：
- 精确总体不可复现：9,421 个安装、671 个企业级环境无法从文档记录的阈值和可观察的非开发/已发布过滤中复现。要达到该数字，还需要一条未被记录的额外排除规则。这一发现直接否定了原记录数字的"证据地位"。
- 7.9% 与 0.98% 是状态关联而非转化：这两个百分比最接近的解释是"每个安装最近一周 ping 中的付费许可占比"，数据既不能证明这两个群体在窗口内发生了转化，也不能证明环境规模导致了转化。这是全文方法论上最核心的辨析——current-state association ≠ conversion rate。
- 前 GA 基线缺乏精确截止点：见上文表格，跨 GA 日期边界变化剧烈。
- 月度新增付费订阅的说法无源可查：仓库中找不到对应的查询或持久化报告；2026-08-07 的 canonical finance 快照只报告活跃订阅与收入，不报告获取速率。
- 无项目所有者批准制品：没有仓库或 git 制品能确认项目所有者批准了产品反转。
结论段则给出了审计的最终定位：重建数据可以作为新的显式所有者决策的有用背景，但不足以保留此前的批准标签或因果转化声明。
审计的治理后果：从"证据不足"到两次独立决策
这份审计并非孤立文档，它在 Pulse v6 发布控制体系中与三份记录形成完整的治理链条：
第一环——被审计的修订记录（self-hosted-commercial-surfaces-revision-2026-08-07.md）。它据审计结果移除了 Richard-approved 标签，明确写出"仓库和 git 历史中不存在该标签或精确数字的所有者确认制品、查询、快照、报告 URL 或来源标识"，并把治理状态标记为 blocked pending project-owner decision。它还诚实声明：这次更正不回滚产品代码，只是如实记录已落地的行为，并阻塞发布就绪状态直到所有者显式表态。其"当前产品边界"一节则详细描述了落地形态：普通免费自托管会话默认可见反应式商业面（付费功能导航项 + 面板级内联门禁 + 可发现的 Plans & Billing 页）、唯一主动面是只对"监测环境跨过 5 个 PVE 节点 / 10 个 Docker 主机 / 3 个 VMware 主机阈值"的免费安装认证会话显示的一次性 business-estate 卡片（单次交互永久可关闭）；demo 与 white-label 运行时则保持绝对商业抑制。该记录还列出了"所有者决策三选项"：整体保留 / 整体回滚 / 指定更窄的新姿态，并给出了整个商业集群的 public pulse 与 private pulse-pro 提交清单，以及回滚时必须保留的后续重叠提交（如非管理员设置轮询、授权拒绝日志、仅管理员 System 页可见性等 8 个提交），确保回滚是"冲突感知的"而非粗暴 revert。
第二环——被废止的历史决策（self-hosted-paid-services-opt-in-surface-2026-04-25.md）。这份 2026-04-25 的记录代表"最后一个已验证的产品方向"：普通自托管 v6 用户默认不得看到付费服务提示、Pro 试用 CTA、计划升级或付费专属导航，商业面仅在用户主动走显式交接/直达路由、运行于托管模式、或已具备付费授权/激活/恢复状态时出现。审计所暴露的 2026-08-07 修订正是对这一已验证方向的偏离。
第三环——最终的所有者决策（business-tier-launch-2026-08-20.md）。项目所有者（Richard Courtman）于 2026-08-20 批准以 $399/年、仅年付、无限席位、365 天保留 的配置正式上线自托管 business 层级，并明确声明：不重新引入 2026-08-07 商业面集群的任何部分——opt-in 呈现姿态保持、business-estate 卡片保持移除、business_estate 遥测保持退役（由 pulse-pro 中的 TestTelemetryPing_IgnoresRetiredBusinessEstateField 测试钉死），Business 只出现在公开定价模型载荷与公开结账流中。该记录还披露了在 2026-08-18 排除幻影安装队列后对量化依据的重新基线：7 天活跃 682 个企业级环境（7.77% 付费）对 1.25% 的小型环境付费率，6.2 倍转化倍数——这是审计之后、证据充分的新基线，与审计所指出的"转化证据不足"形成呼应：审计拒绝不充分的证据，但并未拒绝基于更好证据做新决策。
这三环合起来就是本审计在治理层面的完整价值：一份无法通过证据审查的决策依据，既不应当被当作已批准，也不应当被简单抹除，而是应被降级为"背景上下文"，由所有者基于更充分的证据另行决策。
遥测隐私与数据最小化：审计得以成立的底层契约
本审计能够安全进行，依赖于 Pulse 遥测体系长期执行的隐私契约，这些约束在 docs/release-control/v6/internal/subsystems/security-privacy.md 的 security-privacy 子系统契约中被明文治理：
- 载荷字段级披露：canonical 与前端提供的隐私文档必须字节级同步，遥测表必须标明当前 schema 版本并逐个命名每个出站 JSON 字段（"Their telemetry table must identify the current schema version and name every outbound JSON field individually"）。
- 计数而非身份：遥测载荷中的
Ping结构体（internal/telemetry/telemetry.go）只携带旋转式InstallID、版本、平台、事件类型与各类资源计数，注释明确要求 "no names, IPs, or identifiers"。 - 默认开启、可随时关闭：internal/config/config.go 中
TelemetryEnabled的注释为 "Outbound usage telemetry enabled by default (pseudonymous install ID, version, resource counts, feature flags — opt out any time)"，默认值true，可通过环境变量PULSE_TELEMETRY=false或设置面板关闭；config.go 中对PULSE_TELEMETRY的解析逻辑在 internal/config/config.go，非法值会被警告并忽略。 - mock 与测试硬抑制：security-privacy 契约要求
internal/mock.IsMockEnabled()为真时不得发送任何启动/心跳 ping（mock 快照描述的是合成测试机群而非真实安装），Go 测试二进制同样不得向生产接收端上报。这与审计中COALESCE(p.version_is_development, 0) = 0的过滤逻辑一脉相承——开发、mock、测试产生的数据本就不该进入真实统计口径。
本审计记录自身的"aggregate-only read, no install, customer, subscription, or resource identifiers returned"声明，正是这套契约在审计场景下的延伸执行：审计者要能重建统计，但永远不把统计还原成个体。
可复现的审计流程清单
从这份审计记录可以提炼出一套通用的"遥测驱动决策依据审查"流程，Pulse 后续的证据类工作（包括 scripts/telemetry_adoption_report.py 及其配套测试 scripts/tests/test_telemetry_adoption_report.py 所服务的发布采用率报告）可以视为同一方法论的不同应用：
- 固定数据源与访问路径：记录源仓库 commit、源表、包装脚本、查询模式（readonly）、测量时间。证据链的每一环都要可追溯。
- 声明重建而非原始：如果原始查询不存在，就明确标注"取证重建"（forensic reconstruction），并说明它与原始查询的区别。
- 去重与时间窗显式化：用
ROW_NUMBER() OVER (PARTITION BY install_id ORDER BY received_at DESC)表达"最近一周内活跃安装"的确切定义；用COUNT(DISTINCT install_id)表达去重活跃数。 - 聚合只读、脱敏输出：只返回计数与占比，绝不返回 install_id、客户、订阅或资源标识符。
- 多口径交叉验证：对"非开发"与"已发布非开发"两种过滤分别计算，观察稳定性；若数字对口径敏感，本身就是需要报告的发现。
- 区分状态与因果：付费占比是"当前状态的关联"，不是"转化率"。没有纵向窗口数据，就不能宣称转化。
- 核对 schema 时间线：确认存储列（如
business_estate）首次写入生产的时间是否晚于被审计记录的成文时间，判断该列能否是原始数字来源。 - 给出可操作的治理建议：审计结论要落到"保留/回滚/新姿态"这类明确选项上，而不是停留在"数字对不上"。
总结
self-hosted-commercial-surfaces-evidence-audit-2026-08-08.md 是一份高质量的取证审计样本：它以严格的 provenance 记录、只读聚合查询、多口径快照和时间线核查，把"某个商业决策依据能否被证据支撑"这个问题拆解成了可逐条验证的结论。它证明了一件容易被忽视的事：在一个治理严格的软件项目里，审计的价值不在于算出数字，而在于划定"哪些数字可以进入决策"。 9,426 与 9,421 的差别、7.9% 是占比还是转化率、前 GA 基线的 362 与 958——这些细节的澄清，最终让 Pulse 得以在 2026-08-08 干净回滚到 opt-in 姿态，又在 2026-08-20 基于重新基线化的 682 个企业级环境与 6.2 倍转化倍数，做出了 $399/年 business 层级上线的正式决策。对于任何依赖遥测数据做产品决策的团队，这份记录都是一份值得对照的方法论范本。