解读

面试官真正想考察的是：

1. 你是否能把“非真实用户行为”从生产日志里干净地剥离，防止压测模型被放大或扭曲；
2. 你是否有一套可落地的“识别→清洗→验证→固化”闭环流程，而不是只喊“去掉异常流量”口号；
3. 你能否兼顾国内特有的“微信裂变、小程序秒杀、政企大促、黑产爬虫”场景，给出合规、可审计、可回滚的方案。

知识点

1. 国内主流识别维度

   • IP：阿里云/腾讯云/华为云CDN回源段、IDC段、运营商NAT池、已知黑产IP（威胁情报库、公安网安接口）。
   • 设备指纹：国内厂商（数美、同盾、顶象）生成的device_id、微信/支付宝小程序的openid、unionid。
   • 行为节拍：同一UA、同一IP 1 秒内 >30 次、Referer 缺失、HEAD/OPTIONS 占比高、顺序翻页但无鼠标轨迹。
   • 业务特征：秒杀接口带token、带sign、带activity_id；活动页埋点带utm_campaign=618、双11；爬虫常不带广告参数。
   • 返回码分布：200 占比 99.5% 以上且无 4xx，极可能是程序刷接口。

2. 数据合规红线

   • 《个人信息保护法》要求“最小可用”，device_id、openid 需脱敏（MD5+盐），日志落地前完成脱敏，避免明文存储。
   • 公安备案系统要求留存 6 个月原始日志，清洗脚本必须支持“可回滚”，即能在法庭上重放原始文件。

3. 清洗技术栈

   • 离线：Hive/Spark SQL + 自定义 UDF（调用威胁情报 API），输出“标记表”与原始表做 left anti join。
   • 近实时：Flink CEP 模式序列“5 分钟内同一 IP 下单接口调用 >100 且成功率=100%”→侧输出流写入 Kafka 黑名单。
   • 采样验证：把清洗掉的流量按 1% 抽样另存，用 Gatling 重放，确认 TPS 曲线是否与生产尖刺吻合，防止误杀。

4. 模型校准方法

   • 分位数修正：对“正常流量”取 95 分位并发数，再按业务增长率（运营给出下季度 GMV 增速）做线性外推，避免直接拿峰值做 1:1 压测。
   • 混合模型：日常模型（去掉爬虫/活动）+ 突发事件模型（仅保留秒杀/活动）双版本，灰度发布前跑“日常”，大促前跑“突发”。

5. 持续防污染机制

   • 日志落盘前加“流量类型”字段（0=正常，1=爬虫，2=秒杀，3=活动），由网关统一打标，后续清洗成本最低。
   • 每周跑“异常度”巡检报表，TOP10 异常 IP 自动同步到 WAF 黑名单，降低下次污染比例。

答案

第一步：在网关层埋点，把 UA、IP、device_id、活动 ID、返回码、接口耗时写入同一行日志，并脱敏。
第二步：建立“黑/白/灰”名单库。黑：威胁情报、公安接口、历史验证爬虫；白：办公出口、监控拨测；灰：待定，需业务确认。
第三步：每天凌晨用 Spark 跑批，按“IP+接口+成功率+节拍”四维打分，得分>80 的标记为爬虫；秒杀/活动流量则通过 activity_id 白名单匹配，命中即标记。
第四步：把标记结果写入 Hive 分区表，压测团队用 where traffic_type=0 取数，生成 Gatling/JMeter 脚本；同时把爬虫流量另存为“异常场景”，只在稳定性测试中少量回放，验证限流/熔断能力。
第五步：上线前做“双盲验证”——A 组用清洗后模型压测，B 组用未清洗模型压测，对比 95 线 RT 差异 <5% 即通过，否则回调查因。
第六步：把整套流程脚本化（Shell + SQL + Flink Jar）接入 GitLab CI，任何人工改规则需 Merge Request，审计留痕，满足国内合规要求。

拓展思考

1. 如果公司把业务全迁到 Kubernetes + Service Mesh，可以把 Envoy Access Log 直接发到 SkyWalking-OAP，用 OAL 脚本实时计算“异常度”，省去 Flink 集群，降低运维成本。
2. 对于金融类秒杀，监管要求“三码合一”（订单号、支付单号、物流单号），可在网关层强制校验，缺失任意字段即判为非法流量，清洗准确率能提升到 99% 以上。
3. 未来想引入 AI 异常检测，可先用 Isolation Forest 做无监督训练，但务必把特征做成本地化（不出现个人信息），否则训练集出境会触碰《数据出境安全评估办法》。