Lurus Witness · 见证 早期试点

见证回答一个问题：你环境里的这套系统现在是什么状态，以及我们对这个判断有多确定。

每一条读数都带着它的来历：

platform-core      v1.4.2   ● 正常
                   版本来自服务自报 · 健康来自自省实证 · 12 秒前

客户自建 supabase   ?        ● 正常
                   版本未知（组件不自报）· 健康为黑盒推断（仅可达性）

nginx vhost        —        ◐ 陈旧
                   采集器 3 小时未上报 —— 这不是「正常」，是「不知道」

同样是「正常」，三种来历的分量不同。我们不承诺全绿，只承诺每个绿点都标明它的证据强度。

它由什么组成

• 只读采集器：单个静态二进制，装在被观测的主机上，按间隔把快照推给汇聚服务。
• 汇聚服务：收快照、判定陈旧、提供只读查询和一块 Web 大屏。
• 外部视角探测：从另一台机器按固定间隔访问，缺的样本记为「未采样」。
• 每月真恢复演练：把异地备份恢复到隔离环境，逐表核对行数。
• 月度证据报告：每个数字旁边写着它是怎么测的。

前两项见 概念 与 部署，后三项见 演练与报告。

它不是什么

• 不是运维控制台。 v1 没有任何写操作。契约里为「操作」预留的接口永远返回 501，大屏与手机端都不出现操作按钮。
• 不只认自家产品。 组件类型是开放字符串：可以是我们的服务，也可以是一套开源数据库、一个 nginx 站点、一张快过期的证书。不认识的类型照常显示。
• 不采集业务数据。 订单、用户、金额一概不采；它也不是性能监控。
• 不是「实时」。 按上报间隔观测，间隔和判定窗口都写在屏幕上。

为什么「只读」要写进代码而不是写进合同

采集器装在客户的机房里。它对外只能发 GET / HEAD，唯一例外是向汇聚服务提交自己的快照；HTTP / TLS / TCP 类探针只能连汇聚服务和配置里列出的目标（k8s 探针经 kubectl 连集群的 API server）；快照只能包含契约里定义的字段，服务端拒收任何多余的键。这三条都有测试守着，其中一条测试让被探测方返回一段假的个人信息，断言编码后的快照里一个字节都不出现。

早期试点：现在做到哪里

我们照实写：

• 汇聚服务和采集器目前常驻在我们自己的预发布环境上，另外接入了两个异构的上报方。
• Web 大屏可用；手机端的接入链路还没有完成验证。
• 预编译安装包与容器镜像尚未发布，暂无时间表。
• 白标（按客户品牌出主题）尚未实现。
• 采集器可以交叉编译到国产 CPU 架构，但能编译不等于验证过。交付前需在目标环境实测。
• 很多组件不自报版本。它们会显示 ?——这是准确，不是缺陷。

有兴趣试点，或者想先看一眼采集器会发出什么数据，联系我们。