行为基线为什么总在误报

结论先行：用户行为分析上线之后最常见的抱怨是「一天几百条告警，大部分是误报」。多数团队会去调阈值、换模型，但真正的原因通常不在算法，而在建模的前提不成立——新人没有历史行为可对比，小部门没有足够的群体样本，月末结账的批量动作被当成了异常外发。四种常用的建模方法各有各的适用条件，前提缺一个，基线调得越精细，误报反而越多。

本文只谈行为基线建模的前提条件与失效判断，不谈日志该怎么采集、字段怎么统一，也不谈单条告警该怎么研判处置。

四种建模方法，各自在回答不同的问题

先把方法分清，后面才能对号入座。同样叫「行为基线」，四种做法回答的是四个不同的问题。

四种方法经常被混在一起卖，但它们的失败方式完全不同。判断一套方案是否适用，不用看它支持几种算法，只需要问：针对我们这边的岗位结构，这四种里有几种的前提是成立的。

前提一：岗位要稳定，历史才有效

个人历史基线是最直观的一种：把某人三个月来的登录时间、访问系统、文件操作存成一条曲线，之后偏离曲线就告警。

它成立的前提是「这个人的工作内容在观察期内基本没变」。这个前提在两类情况下立刻失效。

一类是新入职。新人的前三个月本来就在熟悉环境，访问的系统越来越杂、下载的资料越来越多，这是正常的学习曲线，但基线看到的是「持续偏离」。可行的处理是给新入职设一个观察期，这期间只启用规则型告警（比如访问了明确列为敏感的目录），不启用基线型告警。

另一类是转岗或接手新系统。一个人的职责范围一变，他的行为曲线整个平移，而这在数据上看起来像一次持续异常。处理方式与上一条相同：职责变更要触发基线重建，重建期间降级为规则。

这两类处理说起来简单，落地时需要一个前提——人力资源的入职、转岗、离职信息要能同步到平台。多数误报的根源就在这里：平台不知道这个人上周换了岗位。

前提二：「罕见」得先有参照系

罕见行为检测的逻辑是「这个动作很少见，所以可疑」。这句话省掉了一个关键部分：跟谁比、在什么范围内比。

罕见与否，取决于一份「正常动作清单」。比如在某类服务器上执行高危命令、向从未出现过的收件人发送带附件的邮件、访问一台从未被访问过的服务器。这份清单决定了什么会被判为罕见。

清单一旦滞后，误报就成规模出现。典型场景是新系统上线：新引入的一套业务平台会产生一批此前没有的访问关系，在清单更新之前，这些正常访问全部会被判为「从未访问过的服务器」。另一种是项目期临时扩权：一个跨部门项目会给十几个人开一批临时权限，这些访问在基线里就是一群异常。

可行的做法是把清单变更与变更管理绑定——新系统上线、权限调整这两类动作发生时，同步触发清单更新，并在更新完成前抑制对应的告警类型。这件事技术上不难，难在流程上要有人负责。

前提三：群体基线要有人群

群体对比的方法听起来更公平：不看个人历史，只看同岗位其他人的平均行为，偏离群体即告警。

它的前提是同岗位的人数足够多、职责足够同质。人数太少时，这个方法的数学基础就不成立——一个三人小组，任何一个人都会成为另外两个人的异常点。职责不同质时，结果更糟：同一个部门里既有做运维的也有做客服的，他们的行为分布本来就不一样，强行放在一个群体里比较，等于每边都在误报。

可操作的处理是设一个下限：低于某个规模（比如同岗位少于若干人）时不启用群体基线，改用规则与个人基线。识别同质人群也需要一层工作——按岗位职责而不是按组织架构分组。这两件事都需要人力资源与业务部门的输入，属于典型的「技术上五分钟、组织上五个月」。

前提四：分清业务周期与技术周期

周期性检测用来抓那类隐蔽的行为：每天固定时间导出一次数据、每周定时打包外发、每月扫描一遍文件共享。这类动作单个看都正常，规律性本身就是可疑点。

麻烦在于，企业里有一大批「周期性但完全正常」的动作：月末结账前的批量导出、季度末的归档备份、年度盘点的全量扫描、月初的报表生成。这些动作在数据上与「定时窃密」几乎一模一样——固定时间、固定量级、固定对象。

所以这个方法的成立前提是：先把「已知的业务节奏」登记成一份节奏表，检测时先排除再判断。节奏表需要业务部门提供，不能靠技术侧猜。这件事在很多项目里被省掉了，结果是每到月末告警量翻几倍，值班员养成了「月底的告警先不看」的习惯——而这个习惯一旦形成，真正的异常也会被一起跳过。

三个失效信号

基线是否还值得继续调，看三个现象就够了。

其一，同一类告警的月度数量持续上升，处置率持续下降。这说明模型在不断产生无人处理的结果，它已经从工具变成了噪音源。

其二，告警集中分布在少数几个岗位或部门。这是前提不成立的直接证据——不是这些部门的人有问题，是他们的岗位特征与模型假设不符。

其三，分析师开始批量关闭同类告警。这是最危险的信号，因为它意味着判断能力正在从系统中流失。批量关闭的行为本身应当被记录下来，它比告警数据更能说明系统的实际有效性。

基线不是越细越好

最后说一个方向性的判断。

建模粒度与数据量、岗位稳定性是绑在一起的。岗位稳定、数据充足的环境，细粒度基线确实能抓到更多真实异常；岗位变动频繁、人员流动大的环境，细粒度基线只会更快地失效。素材里给出的建模能力清单（个人历史、罕见行为、群体对比、周期分析四类）是能力范围，不是实施顺序——真实项目里通常按「先规则、再周期、后基线」推进，因为规则型告警不需要历史数据，上线当天就能用。

深圳市奇摩计算机有限公司在做日志分析类项目的实施规划时，会把基线建模放在规则跑顺之后，并且要求客户方先提供岗位职责与业务节奏两份清单。这两份清单缺任何一份，基线阶段都不建议启动——不是技术上做不了，而是做出来的东西没人敢用。

落地清单

• 按四种建模方法列出各自的前提，逐项核对本企业是否成立，不成立的先不启用。
• 把入职、转岗、离职信息同步到平台，作为基线重建的触发条件。
• 维护一份「正常动作清单」，并与新系统上线、权限调整同步更新。
• 群体基线设人数下限与同质分组规则，按岗位职责而不是组织架构分组。
• 由业务部门提供业务节奏表（月末、季末、年度），检测前先排除已知节奏。
• 每月统计告警处置率与批量关闭次数，作为基线是否需要重建的依据。

若您正在规划日志与用户行为分析类项目，欢迎 预约咨询。