独立产品 · 装在贵方自己的机器上
潮汐 Tide
接入贵方的流量，持续找出正在发生的攻击：哪个资源池在打、什么时候起量、
打的是哪个业务切片，并按时间线还原出一份贵方可自行核验的举证。
全程在贵方内网完成，流量不回传我方。
另一个产品是 Pulse 私有化（把 IP 风险评分搬进自己机器）·
看两者对比
业务数据不出环境
查询与流量观测都在贵方内网完成，不回传我方。交付二进制里不含任何外部域名，
贵方安全团队可用随附脚本自行验证。
按时间线还原攻击资源
不止给一个分数：给出这批流量来自哪些攻击资源池、什么时候起量、
规模与共用度如何，以及一份对方可自行核验的举证报告。
看一份真实检出的取证报告 →
是否阻断由贵方决定
产品只出建议，且刻意不提供硬拦截动作。执行与否、用哪种手段、
何时解除，均在贵方自己的系统内决定。
它解决的问题
查一个已知可疑的 IP，这件事本身不难——难的是不知道该查哪些。
黑产换 IP 的速度远快于人工发现的速度，等到有人报上来「这个渠道数据不对」，
那一波往往已经打完了。
Tide 换一个方向：不等贵方来问，而是持续看贵方的流量本身，
从中把「异常正在哪里发生」找出来——哪个攻击资源池刚冒头、哪个业务切片的风险率偏离了自身常态——再把它还原成一条可核验的时间线。贵方要做的是决定处置，
不是先去发现。
传统做法为什么看不见
现有的风控与异常检测，几乎都是按业务维度聚合看的：这个渠道的风险率有没有异常、那个广告位的转化有没有掉。问题在于攻击方的资源不按贵方的业务维度分布——同一个资源池的流量会摊到多个渠道里，每一份都小到淹没在噪声里。
换个聚合维度，同一批流量就从「看不见」变成「很明显」。这正是资源侧通道在做的事。
同一批数据上，两条通道各检出多少
这不是估算，是在 21 个客户、1.65 亿条请求、三天的全量回放上跑出来的。资源侧检出 192 个事件，业务侧 9 个；其中 103 个是按业务切片聚合结构性看不见的。
资源侧不需要贵方传任何业务维度——它判的是攻击方的资源，那是我方的维度。
这也是为什么建议先接采集器
零业务维度的部署，产品的主要价值就已经在了。业务维度带来的是处置颗粒度——
没有它，处置只能到整个资源池；有了它才能说「压 A 渠道来自 X 池的流量」，
影响面从整池收窄到渠道内一小块。那是压制敢不敢开的前提，但那是第二步的事。
两条检测通道，一条不依赖贵方改造
业务侧判「风险率相对贵方自身常态的偏离」，需要贵方传业务维度；
资源侧判「哪个攻击资源池在打你」，只需要 IP 与时间戳——那是我方的维度，
零改造即可产出。
| 通道 | 需要贵方提供 | 多久开始工作 | 能回答什么 |
|---|
| 资源侧 | IP + 时间戳 | 约 1 小时 |
哪个攻击资源池在打你、是新出现还是突然放量 |
| 业务侧 | 额外的渠道/广告位等维度 | 约 1 周 |
哪个业务切片的风险率偏离了自身常态 |
为什么建议先接资源侧
资源侧判的是攻击方的资源，不是贵方业务的形状——它不依赖贵方传任何业务标识，因此零改造就能产出结论。我方在自有观测上做过全量回放验证：
按业务切片聚合的口径，对「量不大但持续存在」的资源池是结构性看不见的，
而那恰恰是这条通道能补上的部分。
业务维度带来的不是「能不能检出」，而是处置的颗粒度：
没有它，处置只能到整个资源池；有了它才能说「压 A 渠道来自 X 池的流量」，
影响面从整池收窄到渠道内的一小块。那是压制敢不敢开的前提，但那是第二步。
贵方也不必信这段话：接入后第一周内，两条通道各自检出了什么，
在贵方自己的环境里可以直接对照。
部署流程
从拿到交付包到看见第一批结论，通常一天之内；业务侧的结论要等基线攒够，约一周。
-
装上并起服务
解包到 /opt/tide、填一份 tide.env（许可名、Redis 地址、库路径）、
装 systemd 单元、curl /healthz 探活。四条命令，随包有逐字脚本。
-
接上情报镜像同步
有公网就装定时同步单元；内网就走离线介质导入。
这一步不能省——镜像停更几天后检出率会归零，而服务一切正常。
-
接入流量：先采集器，别急着改代码
采集器 tidecollect 零代码改造、当天可接；SDK 要改代码走发版。
建议先上采集器跑一周再评估要不要接 SDK——实测在 21 个客户、1.65 亿条请求上，
零业务维度的部署仍检出 192 个资源侧事件，其中 103 个是按业务切片聚合结构性看不见的。业务维度带来的是处置颗粒度，那是第二步的事。
-
等基线
资源侧约 1 小时开始工作；业务侧要跨足够天数才能估出「常态」，约一周。
交付当天业务侧记为「暂缺条件」而不是「未通过」，清单会把还差几天算给贵方。
-
验收
一条 tide-adm acceptance 跑完全部可验项，输出逐项清单与计数。
验收单签的是逐项验证结果，不是功能清单——凡是只有我方能证明的，都不算验收项。
交付形态
一个自包含的 tar 包，客户侧只需要 Linux 与 Redis。无需公网、无需访问 ip99.com。
三个二进制
tide 服务、tide-adm 运维工具、tidecollect 日志采集器。
纯 Go 静态编译，不含外部域名与联外依赖，构建期由不变量测试把关。
三份 SDK
Go / Java 8+ / Node 12+，均为单文件零依赖，可直接拷进代码库。
统一的移植契约保证「绝不伤害宿主应用」。
情报本地镜像
随产品交付并持续更新：厂商侧按许可签发带水印的增量包，
客户侧定时拉取导入。健康检查会区分「通道断了」与「上游没发包」。
可自验的验收标准
一条命令跑完全部可验项，逐条给出通过 / 未通过。
我方无法让贵方自证的部分（如误伤率上界、情报覆盖率）单列为声明项，
不混进通过项里。
参考规格
下列数字为实测值，不是估算。具体规格按贵方流量与维度声明测算，产品自带测算命令。
| 项 | 实测 | 说明 |
|---|
| 情报镜像内存 | 3.76 GB | 随情报规模走，不随贵方流量走 |
| 查询吞吐 | 约 850 QPS / 核 | 4 核实测 3,300 QPS，P99 27 ms |
| 检测库磁盘 | 4.4 MB – 24.5 GB | 由业务维度基数决定，差距可达数千倍 |
| 服务进程内存 | < 300 MB | 聚合按窗口落盘，与流量规模基本无关 |
能力边界，我们写进验收单
交付时会随产品给出一份验收标准，其中把两件我方无法让贵方自证的事，
以书面声明的形式讲清楚——而不是只讲优点。
误伤率上界
公布分数各档的误伤率上界、推导方式与所依赖的假设。这是无标注上界，
不等同于在贵方业务上的实测值——后者需要贵方回传判黑标注才能得出。
情报覆盖与新鲜度
公布我方对贵方流量的覆盖比例、证据时效窗与数据源的复观测节奏。
0 分的语义是「无可核验证据」，不是「安全」——未检出不等于已排除。