2026 服务器租用自建 MISP 威胁情报库：MySQL 表膨胀/feed 带宽/关联开销避雷手册

情报库的资源账，几乎都记在后台任务上

把 MISP 装到一台租来的独立服务器上，前两周通常是安静的。界面打得开，订阅源配上，事件一条条进来，管理员扫一眼资源占用，觉得机器买大了。真正的压力往往出现在第三周到第三个月之间：属性表行数上一个数量级，缓存重建从几分钟变成几十分钟，清晨的网络曲线开始贴着上限走。这个时间差是自建情报库选型最容易落空的地方——验收时看到的负载，和平稳运行三个月后的负载，其实是两台不同的机器。

MISP 的技术栈决定了资源消耗的重心不在 Web 层。它以 MySQL 或 MariaDB 作为主存储，用 Redis 承担任务队列与缓存，feed 拉取、属性入库、关联计算、缓存重建这些重活全部交给后台 worker 异步执行。Web 界面只是查询与录入的入口，它本身占用的 CPU 与内存相对有限。换句话说，如果按"一个内部系统、十几个人偶尔查一查"的口径去估算配置，那么实际跑起来的负载模型更接近一个批处理系统：绝大部分资源消耗发生在无人值守的时间段，被后台任务悄悄吃掉。

后台任务可以拆成四类，吃资源的方式各不相同。feed 拉取是网络与解析密集型，主要消耗带宽和 CPU；属性入库是写入密集型，消耗磁盘的随机写能力与 binlog 的顺序写能力；关联计算是 CPU 与随机读密集型，需要把候选属性反复比对；缓存重建则是三者叠加，往往一次遍历全表。这四类任务的时间分布高度不均，而且会互相排队。想清楚这一点，后面所有的资源规划才有落脚点——你要回答的不是"这台机器能不能跑起来"，而是"这些任务挤在一起时，谁先撑不住"。

worker 与队列的关系也值得先说清楚。worker 是常驻的消费者进程，它们不断从 Redis 队列里取任务执行，因此任务的排队顺序与并发度完全由队列决定。这个结构带来一个直观的好处：短时间的负载尖峰不会压垮系统，任务只是多排一会儿。但它也带来一个隐蔽的风险——队列会把问题掩盖起来，界面上看不出异常，实际上处理延迟已经累积了几个小时。判断一个实例是否健康，不能只看界面响应，要看队列是否被及时消费干净。

一个直接的推论是：自建情报库的资源曲线是锯齿状的，不是平的。拉取窗口内出站请求与写盘压力同时冲高，关联任务跑起来时 CPU 打满，其余时间机器接近闲置。如果按平均负载选配置，必然在峰值时段出问题；如果按峰值选配置，成本又很难接受。务实的做法是先测出峰值与均值的倍差，再决定是加资源还是错峰调度。这两条路的花费差得很远，而错误的选择通常在半年后才会暴露。

attributes 表的行数增长模型：一个事件到底带出多少行

容量估算的第一步不是看磁盘有多大，而是算清楚每天新增多少行。MISP 的数据模型里，事件（event）是容器，属性（attribute）是容器里的具体指标，此外还有对象（object）、标签、目击（sighting）、关联关系、提案（shadow attribute）等一系列表。行数量级最大的通常是属性表，其次是标签关联表与关联关系表；事件表本身字段多、行宽大，但行数远小于属性表。很多人在预估容量时只数事件条数，结果磁盘和索引的膨胀速度比预期快出好几倍。

一个可用的粗算模型是：日增属性行数约等于各个订阅源每次推送的事件数乘以平均属性数，再乘以每日推送次数，去重合并之后再乘以保留系数。这里每个因子都要按自身实测校准。平均属性数的波动非常大——一个只带几个域名的事件和一个带完整哈希、注册表键、网络行为的事件，落库行数可以差出一个数量级。订阅源的性质也决定了推送节奏：有的源一天推几次增量，有的源每次都给全量快照。

去重与合并策略是决定最终落库行数的关键变量，也是最容易被忽略的一项。同样订阅二十个源，如果不同源之间存在大量重复指标，那么有效的去重能把入库量压下去很大一部分；反过来，如果去重逻辑失效、或者刻意保留每个源的原始记录以追溯来源，行数会成倍上升。保留策略则是另一个乘数：只留三个月的活跃情报与长期留存历史情报，容量规划完全是两回事。

还有一个必须计入的隐性部分：索引与 binlog 占用的空间，通常不低于数据本身。属性表上为了支撑不同查询会建多个二级索引，索引体积随行数线性增长，而批量入库时索引维护本身就是写放大的主要来源。此外，删除数据并不等于立刻释放空间，InnoDB 的表空间不会自动收缩，清理历史数据之后往往需要额外的整理动作才能把空间还给文件系统。规划容量时，务必把"表数据加索引加 binlog 加备份"作为一个整体来算。

索引什么时候开始失效：五百万行与五千万行的分水岭

同样的机器配置，在五百万行属性和五千万行属性时的表现不是差十倍，可能是差几十倍。原因是跨过了一个临界点：索引整体不再能驻留在缓冲池里。数据量小的时候，即便是全表扫描，数据页也都在内存中，感觉不到慢；一旦索引无法常驻，二级索引的回表操作就从内存访问退化为随机磁盘读，响应时间呈台阶式上涨，而不是平缓变慢。这种"台阶"是数据库类应用最典型的扩容信号。

属性表上的查询模式很杂：按类型查、按值精确查、按时间范围查、按组织查、按标签查。每种查询模式都想要自己的索引，而索引越多，批量入库时的维护成本越高，写放大越严重。这就形成一个直接的取舍：为白天查询优化的索引，会拖慢凌晨的入库；为入库精简的索引，会让白天的查询退化成全表扫描。情报库的读写时段相对固定，这反而是件好事——可以把参数与索引设计按时间段做区分，而不是追求一个全天候的最优解。

判断索引是否还有效，不能靠感觉，要看执行计划与慢查询日志。把最常跑的几条查询拿出来做 EXPLAIN，看是否走了预期索引、扫描行数与返回行数的比值、有没有出现文件排序或临时表。慢查询日志按周统计，重点看扫描行数最大的那几条，而不是执行次数最多的那几条。经验上，情报库的性能问题往往集中在少数几条"看起来很普通"的查询上，它们的共同特征是命中了低选择性的索引，导致扫描行数远大于实际需要。

另一个常被误判的点是"加内存能不能解决索引失效"。答案是分阶段的：在缓冲池还没覆盖热数据集之前，加内存的效果非常显著，几乎是线性改善；一旦缓冲池已经覆盖大部分热数据，再加内存的边际收益迅速下降，此时瓶颈转移到随机 IO 能力与索引结构本身。这也是为什么很多团队加了内存之后只能好一两周，之后问题照旧——他们跨过了第一个台阶，但数据还在涨，第二个台阶已经在前面等着。

常驻内存与瞬时内存是两笔账，线上 OOM 多来自后者

内存规划要分成两个口径来算。第一个是常驻口径：Web 与 PHP 进程池、数据库缓冲池、Redis、后台 worker 常驻部分，这些加起来构成日常占用的基线，波动不大，容易观测。第二个是瞬时口径：导出全部属性、全量关联重算、历史数据清理与迁移、备份压缩、缓存一次性重建。这些任务在执行期间的内存占用随数据规模线性上涨，而不是恒定值，峰值常常是基线的数倍。

线上真正触发 OOM 的，绝大多数是瞬时任务，而不是日常运行。典型场景是运维人员为了做一次分析，在界面上导出全部匹配结果，或者手动触发一次全量关联重算。这类操作会把整个结果集读进内存再序列化，数据量大时瞬间吃掉数 GB。更麻烦的是它通常发生在业务时段，一旦触发，数据库与 Redis 会被一起拖下水，影响面远大于任务本身。因此内存规划必须以瞬时峰值为上限，而不是以日常基线为准。

控制瞬时内存的手段比加内存本身更值得投入。给批量任务设置明确的内存上限与分批大小，让它们在受限范围内跑，宁可慢一点也不要一次吃满；把导出与重算类操作安排到固定的独立时间窗，与业务查询错开；对超大规模的导出改成后台生成文件、完成后通知下载，而不是在请求中同步返回。这几项改造做完，同样的机器能承受的数据规模通常能提升一大截。

还有一条容易被忽视的建议：不要把 swap 完全关掉。swap 让数据库在内存压力下直接被杀掉，对情报库这种"宁可慢不可挂"的系统并不合适。更合理的做法是保留少量 swap 作为缓冲，同时把数据库的内存参数设定在物理内存的合理比例之内，留出余量给操作系统页缓存与瞬时任务。swap 的作用不是提升性能，而是在内存估算出现偏差时，给运维争取到几分钟的处置窗口。

Redis 与 MySQL 抢的是同一块内存，队列深度决定谁先撑不住

Redis 在 MISP 里承担两个角色：后台任务的队列，以及部分数据的缓存。作为队列，它决定了 worker 的调度节奏；作为缓存，它决定了界面的响应速度。这两个角色对内存的要求方向相反——缓存希望内存越大越好，队列则希望它稳定但并不需要特别大。问题在于，Redis 与数据库缓冲池共享同一台机器的物理内存，一方给多了，另一方就必须让出来。

队列积压是这里最需要盯的指标。当入库速度跟不上拉取速度，或者 worker 数量不足、单个任务耗时过长时，队列长度会持续增长。只要队列在涨，就意味着数据处理存在延迟，界面上看到的情报已经不是最新的。更现实的危险是：积压期间队列本身占用内存上升，同时缓存数据被逐出，命中率下降，反过来又加重数据库负担，形成恶性循环。所以队列长度不是一个孤立指标，它和缓存命中率要放在一起看。

worker 数量不是越多越好。worker 与数据库是竞争关系：worker 多了，并发写入与并发查询一起上来，数据库的锁等待与 IO 队列变长，单个任务的耗时反而上升，整体吞吐未必改善。合理的做法是从少量 worker 起步，逐步增加并观察队列消费速率与数据库负载的关系，找到吞吐不再上升的拐点，然后退回到拐点之前。这个拐点位置取决于机器配置与数据形态，只能实测确定。

缓存策略上要注意一个常见误区：把缓存当成解决数据库慢的手段。缓存只能掩盖热查询的压力，一旦数据量增长到缓存无法覆盖，或者查询模式本身是低频且多样的，缓存命中率会快速下滑，压力会原样传导回数据库。真正有效的做法是先定位慢查询、修索引与查询写法，再把缓存用在确实重复访问的那部分数据上。顺序反了，短期看起来缓解了，长期会积累出更大的问题。

feed 拉取的带宽账：订阅源数量、拉取频率与去重失败

网络侧的账可以写成一个简单的乘法：订阅源数量乘以单次拉取体积，再乘以拉取频率。真正容易算错的是第二个因子。绝大多数源支持增量拉取，首次全量、后续增量，两者体积可以相差极大；但也有相当一部分源每次返回的都是完整快照，或者增量支持不稳定，隔一段时间就退化成全量。做带宽规划时，必须按"最坏情况下有多少个源会退化为全量拉取"来估算，而不是按理想增量估算。

去重失败的重复流量是另一个黑洞。HTTP 层面的 ETag 与 Last-Modified 是最常见的去重手段，但不同源的实现质量参差不齐：有的源正确返回协商头，有的源每次都返回新标识，有的源缓存层配置错误导致协商头失效。一旦协商失效，每一次定时拉取都会下载完整文件，带宽消耗直线上涨，而监控上看不出来——因为请求是成功的，日志里没有报错。识别方法是持续记录每个源每次拉取的响应体积与响应码，看到某一体积长期不随增量变化，基本可以判定该源没有走增量。

订阅源的"数量"本身也需要重新定义。两个源虽然名义上各自独立，但如果其中一个是对另一个的转发或镜像，那么订阅它们等于把同一份数据下载两遍，带宽与入库成本翻倍而情报增量接近于零。定期比对不同源之间推送内容的重合度，是控制无效流量最直接的手段。重合度高的源可以保留一个作为主源，其余作为备份源，在需要交叉验证时再启用，而不是让它们每天都参与定时拉取。

失败重试的放大效应同样要考虑。一个源拉取失败，定时任务通常会重试；如果重试策略是固定间隔连续重试，那么在一个拉取周期内会对同一个源发起多次请求。当多个源同时出现问题时，重试流量与正常流量叠加，很容易在短时间内把带宽打满。合理的做法是给每个源设置带退避的重试上限，并对同一源在短时间内的重复请求做合并。

还有一个方向问题需要说清楚：feed 拉取主要是入向流量，但如果这台机器同时对外分发情报（给下游系统推送、给其他组织同步），出向流量会同样可观。租用服务器时，入向与出向的计费与限制口径往往不同，规划时要把两个方向分别统计。很多团队只盯着订阅拉取的入向流量，结果上线同步功能之后，出向带宽先到上限。

为什么清晨集中拉取会把带宽打满

默认调度是造成清晨拥塞的直接原因。定时任务的安装文档通常给出整点或每日一次的示例，管理员配置多个源时很容易沿用同一时间点，于是几十个源在同一分钟同时发起请求。叠加之后的问题是复合的：带宽被占满的同时，解析与入库也在同步进行，CPU、磁盘写入、数据库连接池同时到峰值。这时候看到的卡顿往往不是网络慢，而是几项资源同时触顶之后的连锁反应。

错峰是最便宜的优化手段，几乎不需要额外投入。做法是把订阅源按体积与更新频率分组，分散到不同的时间窗口；给拉取任务设置并发上限，让同时进行的拉取任务数量可控；对体积特别大的源单独限速，避免它独占带宽。错峰之后，同样的机器能承载的订阅源数量通常有明显提升，而峰值资源占用反而下降，因为任务之间不再互相争抢。

拉取与入库的解耦也很关键。如果拉取与解析入库在同一个任务里同步完成，那么网络慢会直接拖住入库，入库慢又会反过来阻塞后续拉取。更好的结构是拉取只负责把原始数据落到本地，解析与入库作为独立任务排入队列，由 worker 按自己的节奏消费。这样网络抖动不会阻塞整个流水线，也便于在入库积压时单独扩容 worker，而不必动网络配置。

观测上要有按小时粒度的流量与任务数据。至少记录每小时的入向与出向流量、每小时入库的属性行数、队列长度随时间的变化。有了这三条曲线，带宽打满的原因一眼就能分辨：流量涨但入库不涨，问题在拉取侧；入库涨但队列不涨，说明消费正常；队列涨而流量不涨，说明瓶颈在入库或关联环节。没有这些曲线，排障只能靠猜。

磁盘选型要同时满足 InnoDB 随机写与 binlog 顺序写

数据库类负载对磁盘的要求是复合的，而这两种要求指向不同的性能指标。InnoDB 的数据页刷新是随机写：脏页分布在表空间的各个位置，写入位置不连续，考验的是小块随机写能力与队列深度下的响应稳定性。binlog 与部分日志则是顺序写：追加写入、位置连续，考验的是持续吞吐。一块盘在顺序写测试里表现很好，不代表它在随机写场景下同样出色，选型时不能只看厂商标称的连续读写带宽。

NVMe 与 SATA 固态盘的差异，在情报库场景里主要体现在几个具体环节：批量入库时的脏页刷新、索引重建与大表整理、备份与恢复的耗时，以及关联计算过程中大量的随机读。日常轻负载下两者的体验差距并不明显，因为大部分访问命中缓存；一旦进入批量任务窗口，差距会集中体现为任务耗时的长短。判断标准也很直接：记录一次全量关联重算或一次完整备份恢复的耗时，这个数字比任何厂商标称值都更有参考价值。

写入稳定性比峰值性能更重要。消费级固态盘在持续写入超出缓存区之后会出现明显的掉速，表现为任务前几分钟很快、之后突然变慢。企业环境更应关注长时间持续写入下的性能一致性。另外，云环境下的网络存储会引入额外的延迟抖动，同样的配置在业务低峰与高峰可能表现不同，评估时要在真实业务时段取样，而不是在空闲时段测一次就下结论。

容量规划要留足冗余，而且冗余不是拍脑袋的百分比。要分别估算表数据、索引、binlog、临时文件与备份各自占用的空间，再加上数据增长带来的增量。binlog 的保留策略直接影响这部分占用：保留时间长，便于恢复到任意时间点，但占用空间大；保留时间短，空间省了，恢复窗口也窄了。情报库通常建议保留足够的 binlog 覆盖至少一次完整备份周期，具体时长根据备份频率与恢复要求确定。

备份与快照：情报库最怕的是恢复后数据对不上

快照不等于一致性备份，这是最需要澄清的一点。虚拟机或存储层快照是在某个瞬间冻结磁盘状态，但数据库内存中尚未落盘的数据、正在执行的事务，并不会因为快照而自动变得一致。恢复一份在非一致性点拍摄的快照，数据库启动时会执行崩溃恢复，多数情况下能够自愈，但在写入密集的时段拍摄的快照，恢复耗时与风险都会上升。对情报库这种持续写入的系统，备份方案必须明确一致性点从何而来。

实践上通常采用分层：定期做一次数据库层面的逻辑或物理全量备份，并记录备份对应的日志位置；在全量之间用 binlog 捕获增量变化。恢复时先还原全量，再回放到目标时间点。这个流程的好处是恢复点可控，代价是恢复耗时包含回放时间——数据量越大，回放越长。因此"备份完成"不等于"可恢复"，真正有意义的指标是从发起恢复到服务可用的总时长，这个数字只能通过实际演练获得。

情报库恢复之后还有一项额外工作：缓存与部分派生数据需要重建。恢复出来的数据库可能不包含缓存内容，恢复后第一次访问与第一次关联计算会明显变慢。这部分时间要计入恢复窗口，否则演练结果会偏乐观。同时要验证恢复后数据的完整性——事件与属性的对应关系、关联关系是否完整、各表的行数是否与备份前对得上。只验证"服务能起来"是不够的。

备份文件的存放位置要独立于数据库所在磁盘。放在同一块盘上的备份，在磁盘故障时与数据一起丢失，等于没有备份。至少保留一份异地或异机副本，并确认这份副本的传输不会与业务流量争抢带宽——大体积备份的传输本身就会占用可观的网络资源，应安排在业务低峰并做限速。此外，备份文件包含大量情报指标，其访问权限应与生产库同等对待，避免在备份环节形成新的暴露面。

演练频率决定了备份是否真的可靠。建议按固定周期做一次完整恢复演练，把备份文件恢复到一台独立机器上进行验证，而不是只在生产机上检查文件是否存在。演练要记录恢复总耗时、数据一致性校验结果、恢复后重建缓存的耗时。这三项数据既是对备份方案的检验，也是向管理层说明恢复能力的依据。没有演练过的备份，只能算是一个愿望。

数据库该什么时候拆出去，历史数据该什么时候归档

先把顺序说清楚：绝大多数情报库的性能问题，应该先在单机内解决——调参数、补索引、错峰任务、限制瞬时内存、换更快的磁盘。这些措施的成本低、风险小，而且不需要改变部署结构。只有在这些手段都用尽之后，才应该考虑把数据库拆到独立节点，或者引入只读副本。过早拆分会带来新的复杂度：网络延迟、连接池管理、跨机备份一致性、故障排查链路变长，这些成本在小规模阶段并不划算。

需要拆分的信号是具体的，不是感觉上的。备份窗口已经挤不进业务低峰期；数据库维护操作必须停止 Web 服务才能进行；读写混合导致锁等待明显，且错峰之后仍然无法缓解；单机内存已经无法同时容纳缓冲池与瞬时任务峰值。出现其中任意一条，说明单机结构已经到达边界，此时拆分的收益才会超过它带来的复杂度。只读副本则主要解决另一个问题：把分析型查询与导出类操作从主库上摘走。

归档的时机与拆分不同，它更多取决于查询习惯而不是资源占用。情报数据有很强的时间衰减特性：超过一定时间的指标，被查询的概率大幅下降，但直接删除又损失了追溯能力。合理的做法是按时间分层——近期数据留在主库承担日常查询与关联，历史数据转移到归档库或压缩存储，查询时按需加载。分界点应该根据实际查询日志确定，看绝大多数查询落在哪个时间区间内。

按组织归档是另一种切法，适合多团队共用一个实例的场景。不同组织关注的情报范围不同，把访问频率低的组织数据剥离出去，可以显著减小主库的热数据集规模。但要注意归档的代价：关联计算通常需要覆盖全量数据才能给出完整结果，一旦部分数据被归档，关联结果的完整性就会受影响。因此归档之前必须明确一个前提——是否有查询或任务需要跨归档数据，如果需要，归档方案就要包含查询层的合并能力。

自用、多人共享、对外分发：三类场景该盯的指标完全不同

同样是自建情报库，不同使用场景下的瓶颈位置差别很大，用一套指标去衡量必然失真。小团队自用的场景里，使用者少、查询零散，真正的压力来自后台任务与数据增长，重点是任务能否在窗口内跑完、备份是否可靠、数据会不会无声膨胀。多人共享的组织内部实例，压力从后台转向并发：多人同时查询、同时导出、同时录入，争抢的是数据库连接与瞬时内存。对外提供情报查询或分发服务的场景，压力则集中在出向带宽、查询响应与滥用防护上。

把三类的关键差异整理成下表，便于对照自身情况定位。表中所有档位边界均为按数据量与并发量划分的估算区间，不同版本、不同数据形态下的实际落点差异很大，请以自身实测校准，不要直接照搬。

表格里的档位是连续的，不是互斥的。一个实例可能同时处在第三档和第五档——内部多人使用，同时对外提供有限的分发服务。这种情况下不要取两者的并集去堆配置，而是先找出当前的实际瓶颈，一次只解决一个问题，解决之后重新观测。资源规划最忌讳的是一次性把所有维度都按上限配置，那会让成本结构失去弹性，而且掩盖了真正的瓶颈。

哪些数字只能实测，以及一套可以复用的测量方法

先明确列出不能从文章里拿走的数字。每条属性平均占用多少字节：取决于属性类型的分布、是否带标签、索引建了几个、以及是否有对象结构包裹，不同实例之间差异极大。单个核心单位时间能完成多少关联任务：取决于属性分布、关联规则配置与缓存状态。每天入库多少行：取决于订阅源的推送节奏与去重效果。这些数字在任何一份公开材料里给出的具体值，都不如自己机器上跑出来的一手数据可信。

测量方法本身不复杂，难在坚持记录。数据库侧，定期从系统表里统计各表的数据长度与索引长度，除以行数换算成单行平均占用，按周记录形成趋势线，这条线的斜率就是增长速度。查询侧，开启慢查询日志并按扫描行数排序，找出最重的那几条查询，逐一用执行计划验证。任务侧，记录每个后台任务的开始时间、结束时间与期间的资源占用，形成任务耗时趋势。这三类数据加起来，基本可以覆盖绝大部分扩容决策所需的信息。

入库与带宽侧的测量可以直接从应用层日志取。为每个订阅源记录每次拉取的时间、响应体积、解析后的属性行数、入库耗时。有了这四项，就能算出每个源的实际更新频率、有效增量比例、以及单位入库量的资源成本。异常识别也随之变得简单：某个源的响应体积突然放大数倍，通常是源端配置变化；入库耗时持续上升而体积不变，通常是数据库侧出现瓶颈。这两者的处置方式完全不同。

压测一定要用真实数据的快照，不要用随机生成的数据。随机数据的分布与真实情报完全不同：真实数据里存在大量重复值、热点值与长尾值，关联计算的开销、索引的选择性、缓存的命中率都建立在这种倾斜分布之上。用均匀随机数据测出来的结果通常过于乐观，照着它做的容量规划上线之后必然偏差。做法是定期把生产库脱敏后导出一份快照，作为标准压测数据集，每次调整配置后用同一份数据复测，这样不同配置之间的比较才具备可比性。

最有效的测量方式是在正式切换之前跑一段影子期。用真实的数据订阅配置，在目标机器上运行一到两周，期间不承载生产查询，只做数据的拉取、入库、关联与缓存重建。这段时间里采集到的曲线，可以直接用来判断配置是否合适，也能暴露出仅在批量任务窗口出现的问题。影子期的成本远低于上线之后反复调整的成本，对于无法接受中途更换机型的应用场景，这一步尤其值得。

还有一个判断要提前做：确定自己的增长曲线是线性还是加速的。订阅源数量固定、更新频率稳定的情况下，数据量接近线性增长；如果业务在扩张、订阅源持续增加、或者保留策略放宽，增长会带有加速成分。线性增长可以按当前速度外推半年，加速增长则必须留出更大的余量，并优先选择便于横向扩展的结构。用前三个月的数据拟合出的曲线，比任何经验公式都可靠。

把这些判断落到具体机型之前，还要先确认三件事

第一件是确认数据的保留策略与合规要求。保留多久、能否删除、是否需要留存完整的溯源信息，这些决定了容量模型的乘数。很多团队在选型时跳过这一步，上线之后才发现保留要求远超初始假设，容量规划全部作废。这一项应该在采购之前由业务方与运维方共同确认，并写成明确的书面口径，而不是口头约定。

第二件是确认订阅源的清单与更新节奏。订阅多少个源、每个源的推送方式与频率、是否支持增量协商、是否有对外分发的下游系统。这份清单直接决定带宽与入库压力的估算。建议在正式部署之前先做一轮订阅源的梳理，剔除长期无更新的源，合并高度重复的源，这一轮梳理带来的收益通常比加配置更直接。

第三件是确认可接受的恢复与中断边界。恢复需要多长时间、能容忍丢失多长时间的数据、后台任务延迟多久算不可接受。这三个问题没有标准答案，只能由业务方给出。有了明确答案，备份策略、冗余结构与资源余量才有依据；没有答案，任何配置都谈不上合适，只能在出事之后重新讨论。

一万网络的交付边界与验收口径

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

在自建威胁情报库这类项目上，我们的交付边界是明确的基础设施层：物理机或裸金属资源、网络带宽与接入、IP 地址、机柜与电力环境、以及硬件层面的故障响应。上层软件的安装部署、数据库参数调优、订阅源配置、备份策略制定与日常的运维操作，属于客户自身或其所委托技术团队的职责范围。这条边界在合同阶段就会写清楚，避免上线之后出现责任归属的模糊地带。

验收口径同样以基础设施层为准。交付时逐项确认机型配置与合同约定一致、网络连通性与带宽口径符合约定、管理口与远程控制可用、磁盘健康状态正常、监控与告警接入完成。这些项目都能在交付现场逐条验证，并留下书面记录。至于情报平台本身能承载多少数据量、任务能否在预期窗口内跑完，这类指标取决于客户的数据形态与配置方式，建议以本文提到的影子期实测结果作为内部验收依据，而不是以硬件规格表作为承诺。