结论先行：日志平台建设中，采集范围通常是一路加着走的——先把设备接进来，再补业务库，再补第三方系统。加法做得越顺，后面越难做减法，因为每减一项都要解释为什么当初接了。真正省钱也省事的做法是在接入前先把四类内容议清楚：个人信息类字段怎么处理、与业务无关的运行噪音要不要进、非授权区域的业务数据能不能碰、只剩归档价值的历史数据要不要搬。这四类先定，后面每一次扩容都不用重新吵一遍。

本文只谈采集范围该怎么做减法、哪些内容接入前先排除，不谈覆盖率够不够、采集层该怎么分层核对，也不谈平台该放自己机房还是云上。这三件事各有各的判断依据，混在一起谈会把范围问题变成技术问题。

为什么减法要在加法之前做

日志平台的成本随接入量增长，这件事在设计阶段是算不清的。原因不复杂：接入时每个系统看起来都不大，接入量是日积月累上去的；等到发现存储撑不住、检索变慢，能做的只有两类动作——加机器，或者删数据。加机器要预算，删数据要说服业务方。两条路都慢。

更要紧的是另一层：很多内容一旦接进来，就产生了一个新的责任。日志里有手机号、有身份证号、有客户账号，这些字段从原系统被复制到了一个新平台，于是这个新平台上就有了新的访问者、新的导出路径、新的泄露面。

制度上通常要求做数据清洗：过滤无效日志、去重、字段标准化、时间戳统一、敏感信息脱敏。这五件事里，脱敏是其中必须在接入前就定好规则的一项，因为它决定字段进不进来、以什么形态进来。事后补救的做法是把已经落地的数据再洗一遍，成本和风险都比接入前高一个量级。

四类该先排除的内容

下面四类不是说永远不接，是说接入前必须先有一个明确结论，而不是默认全接。

类别典型内容先排除的理由可行的替代
个人信息类原始字段手机号、身份证号、客户账号的明文接进来就多一个泄露面，且多数排障场景不需要明文接入时脱敏，保留可关联的哈希或掩码位，必要时按流程申请查原文
与业务无关的运行噪音重复的心跳、无意义的调试输出、已停用服务的日志占容量、拖检索速度，且在排障时全是干扰项在采集侧按规则过滤，不要等落地后再清
非授权区域的业务数据未经业务方书面同意的业务库、财务库、人事库日志接入动作本身可能构成超范围使用，审计时无法解释来源先签数据使用范围，再按字段白名单接入
只剩归档价值的历史数据早已下线系统留下的存量日志检索价值接近零，却要占热存储与索引资源冷存储单独归档，或按留存要求到期销毁，不进检索区

四类里，第三类最容易被技术视角忽略。接入在技术上只是一条采集规则，但在管理上是一次数据用途的变更。业务方同意把日志给你排障用，不等于同意你把它接进一个全公司安全团队都能检索的平台。这两件事之间的差别，审计会问。

脱敏的三种做法，选哪种要看谁在用

敏感字段的处理不止「脱敏」与「不脱敏」两种。常见三类做法，适用场景不同。

全掩码：手机号只留后四位，身份证只留首尾。适合大范围检索、看趋势、看频次的场景。代价是无法按完整号码精确查人。

哈希映射：原文经哈希后入库，同一个号码每次哈希结果一致，因此可以「按号码查同一主体的所有行为」，但看不到号码本身。排障场景里最实用的一类，因为它保留了关联能力。

分级可见：数据按原样入库，但普通管理员只能看到脱敏结果，原始敏感数据仅对特定角色开放。这一类的灵活性最高，同时对权限体系的要求也最高——它把风险从「数据不存在」换成了「数据存在但受控」。

选哪一类不取决于技术偏好，取决于三件事：谁需要看原文、看了要做什么、这件事多久发生一次。如果一年只有两三次需要看原文，前两类就够；如果每周都要按号码追一次，分级可见更合适。分级可见的前提是权限体系本身站得住：多租户、角色分级、功能与资源的双重权限、以及每一次查看都留下操作审计。

排除项要写成一份清单，不是一句口头共识

范围这件事的麻烦之处在于，它会在每次扩容时被重新打开。今天跟安全团队谈好不接人事库，半年后业务部门自己提了个需求，接不接就变成一次新的讨论。

可行的做法是留一份清单，至少包含四列：

  • 排除对象：具体到系统与字段，不写「某业务系统」这种含糊说法。
  • 排除原因：是合规约束、是价值不足、还是授权未到，三种原因的复评路径完全不同。
  • 谁批的、什么时候批的：留下决策记录，后来的人不用重新判断。
  • 复评时间：写一个日期。因授权未到而排除的，条件变了就该重开；因价值不足而排除的，业务变化后也可能重新有价值。

这四列加起来只要一页纸，但它解决的是这件事最容易失控的地方：范围不是一次决定，是一串决定，而多数单位只记录了结果，没记录理由。

接入顺序上的一个务实建议

如果项目刚开始，接入顺序比接入范围更值得设计。可用的排法是先接排障刚需、字段最干净的那一层——通常是网络设备、主机系统、中间件；再接业务应用与数据库，因为这一层的字段最复杂、个人信息最集中；第三方与云上的数据放最后，因为它的授权链路最长。

这个顺序的好处是：前两层跑顺之后，你已经积累了一版脱敏规则与一份排除清单，后面接入时不用从零讨论。反过来先接业务库，会在规则还没成形的时候就把最敏感的数据搬进来。

边界与前提

三点说明。其一，本文讨论的是采集范围的划定方法，不涉及具体法规条文的适用范围判断；涉及个人信息与行业监管的部分，应以本单位的法务与合规口径为准。其二，脱敏方案会牺牲一部分排障精度，这个取舍需要在业务方与安全方之间达成共识，不能由技术单方面决定。其三，文中关于权限分级与脱敏查看的能力描述为通用设计口径，具体实现以所选平台实际提供的功能为准。

深圳市奇摩计算机有限公司在做日志平台这类项目时，习惯把采集范围清单放在方案文档的前面而不是附录里，因为这些决定一旦落下，后面每一次扩容都要以它为依据。预约咨询，可以按你现有的系统清单，先把这四类排除项过一遍。