Link3 Technologies 在 DNS 流量异常检测中引入机器学习，发现算法模型仅是起点，跨领域团队协作与工程落地才是成败关键。
数据规模与管道构建：
Link3 运营五台 IP anycast 缓存 DNS 服务器，日均处理 8.2 亿查询，产生 420GB 原始日志，年积累近 150TB；两年间数据量已扩大四倍。原文未给出具体数据清洗耗时，但强调原始数据“粗糙”，需网络、安全、系统工程师与数据科学家、ML 工程师、软件工程师联合完成特征工程、标注与模型训练，管道搭建本身即是系统工程。
为什么多数 ML 项目止步原型：
核心瓶颈不在算法，而在算力与领域经验的双重缺口。全网每日产生 9500 万张照片视频、5 亿条推文、2940 亿封邮件、650 亿条 WhatsApp 消息，数据洪峰倒逼分布式训练与推理基建；同时，招聘“懂 DNS 基建、识别攻击特征的 ML 工程师”还是“懂模型调优的网络专家”成为两难选择，原文未给出具体招聘周期与成本，但指出缺乏跨域技术负责人是项目夭折主因。
域知识与模型迭代的取舍：
DNS 作为互联网核心基础设施，误报直接导致解析中断，容忍度极低。工程实践中必须在检出率与误报率间权衡：过度依赖无监督聚类易将合法突发流量判为异常，引入有监督分类又需持续标注攻击样本。原文未给出具体模型指标，但明确指出领域专家需全程参与特征选择、阈值调优与上线灰度，而非交付模型后“甩锅”运维。
对网络工程师而言，ML 不是替代规则引擎的银弹，而是需要与现有告警体系并行、由跨职能小队长期迭代的能力层；投入前先评估团队是否具备“懂协议、懂数据、懂模型”的复合人才储备。
原文: APNIC Blog（2020-10-20）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog