入职近一年，我产生了不可戒除的“瘾”

初生牛犊不怕“战”

口述：欧阳亦可

 撰文：  南研终端分部&南研二十年采编组

首“战”告捷：Make hands dirty （动手干起来）

　　2018年10月，我结束了两年半的留学生涯回到南京，加入CBG云服务云安全工程部。自此，在这片绿草成荫的美丽园区，打开了我人生的新世界。

留学生涯对我最大的影响有两点，一是make hands dirty，一是批判性思维，这两点在我的职业生涯里有着不可磨灭的影响。

入职一个月后，我被推荐参加云服务创新营，这是云服务新人们的第一个PK场，我摩拳擦掌充满期待。创新营的课程设计不同于以往的培训，它要求学员敢想，但想法要靠谱，要以产品被客户选择为终极目标。它要求学员能做，有好的想法还不够，要最终开发出demo才算数，没错，这正是“make hands dirty”的意义，不可以光有空想。

在完成了基础的design thinking（设计思维）理论学习之后，挑战正式开始，第一关就是拥有一个可以作为开发课题的idea。这对我这个“超级脑洞王”来说不是太easy了嘛！目标明确，我们立即行动，我和队友们开始了疯狂的脑力激写。短短的一小时时间，我们孵化出几十条创意，我们料定在这其中至少能挑出10个有用的用于做demo。然而，当几轮用户打分结束之后，最终“存活”下来的只剩下一个idea，这给我上了华为第一课：开发者觉得用户需要的不见得是用户真正需要的。出师不利，看来创新营的挑战没那么容易。

好在存活下来的这个idea也是我最想完成的那个。我是一个音乐迷，一直以来我都想基于华为音乐做一款可以拉近用户和自己偶像距离的小特性，机会终于来了！只有三天时间，我们要在三天内完成产品的设计、开发、验证、虚拟上线部署等全套流程，这真是一个不小的考验。

我们的基本方案假设是：每一个拥有idol的乐迷，都希望能够尽可能多的与idol近距离接触，那么见面会、歌友会、演唱会等线下活动信息就是他们急切需要的，如果能把这些信息推送给大家，那么乐迷跟自己idol的距离将会无限拉近。在这个方案中，最难也是最精彩的部分就是算法部分，算法是否科学对最终识别的结果起着决定性的作用。算法方面算是我的专业，算法方面舍我其谁？我被队友们任命为“首席算法工程师”，负责整个方案中最核心的算法设计。

我设想从华为音乐入手，根据用户历史听歌记录和使用APP的城市定位，精准地为用户匹配到喜欢的idol，再用协同过滤和逻辑回归算法在云端决策给用户推荐哪些idol的信息，计算匹配度，最终实现将idol的信息（如演唱会、见面会等线下活动）精准且实时地投放给用户，并实现购票链接的呈现。我在纸上迅速画出了方案架构图，并获得了所有队友的一致支持，那么接下来，就是要把纸上的东西“变现”。

开发已完成了大半，时间才过去一天半，本以为要“躺赢”了，结果到端侧和云侧联调的时候问题来了。由于网络限制，我们无法获取云端的数据，如果这一点无法突破，那前面的努力全都白费了。在这么一个棘手的问题面前，整个小组一度陷入低迷。

有同学提到，要不然我们用虚拟数据，只做一个客户端版本好了。可是我不想，也有其他队友不赞成，一番PK下来小组最终决定攻关。我们基于Android Studio验证了多种方案，都没能打通，而此时王喆同学的一句话给我们开启了解决问题的大门。“Android Studio自带模拟器在绿区环境是连不了网的，但其他模拟器是可以用NAT模式联网的，我们是不是可以考虑换一个模拟器？”是啊，为什么非要用Android Studio？我们还可以选择Genymotion、Nox、海马玩啊！最终我们用海马玩打通了云侧和端侧，那个瞬间，就好比一场艰苦异常的球赛在哨响前的一记绝杀，大家都兴奋地忍不住嚎叫起来。

其他几组的想法也超有创意，比如手势加解密应用，比如华为手账，但只有我们组利用了机器学习算法技术，并且最终实现了云端协同，真正的实现了从想法到demo的完整落地。也凭借着这一点，我们最终获得了优胜小组，这是我进入华为的第一个“胜利”，感谢我这一帮敢想又肯干的小伙伴！

兴趣是最好的“盾牌”

我的兴趣是机器学习与数据分析，我一直想要将所学的知识运用到实际的业务中，用数据来驱动业务，老朱的一封邮件给我了把想法“变现”的机会。

去年7月我收到老朱的邮件，他在信中说我们现在需要机器学习的人才来应用到风控和入侵检测两个领域。嗯，可以作为一个填补空白的人，我觉得很酷，更重要的是把我的兴趣变成工作，就这样我成为了WiseShield团队的一员。WiseShield团队的责任是通过纵深防御体系、入侵检测和态势感知技术，来防护消费者云服务的安全。消费者云服务是为所有终端消费者提供云服务，例如华为应用市场和云空间的业务。因此，我们团队担负着对抗黑客入侵，保护用户隐私数据和业务数据不被泄露，避免云服务网络安全问题的责任。

入职2周后，在完成了基础培训后，我就开始正式的wafHMM项目开发了，感谢主管和导师，在一开始就给我选择了适合我的项目，我一边学习安全知识，一边做业务，很快就熟悉了安全攻防领域。

11月的南京已经开始冷了，但我的内心非常火热，我期待着一场挑战来证明自己。那天我和磊哥，老陈还有师父一起交流，磊哥说：“每天都有成千上万的入侵数据，其中大部分是由于安全探针的检测规则过于宽泛造成的误报，其实是一个正常用户请求，根本不会造成威胁，但是处理这部分数据也消耗了我们非常多的人力物力，真是浪费。如果我们能过滤掉误报，让安全运维人员的精力聚焦于有威胁的数据就可以大大提升我们的工作效率”。

磊哥转头望着我：“欧阳，这个题你来解怎么样？”一听机会来了，我想都没想，脱口而出：“没问题啊，我12月份一定交出方案！”我开心地望向师父蒋潇，却发现他的表情有点复杂。磊哥心中是有数的，他笑着说：“不错，有胆识，不过我还是让陈志刚和蒋潇和你一起干吧！”后来我静下心来分析需求的时候才明白师父的表情和磊哥的安排，这个工作的确不是凭我一己之力就能迅速拿下的。陈志刚是一个搞安全的老专家，他从“规则”着手，来尝试修正安全探针的部分检测规则，制定告警消减规则，而我则主要从“机器学习”的角度着手，通过机器学习算法区分和判定请求是否真正有威胁。

在真正开始解决问题之前，我先去做了功课。我用了两天时间搜集了关于WAF（网络应用层防火墙）的相关案例，并学习了大量以“Cyber Security”和“Machine Learning”为关键词的论文，看是否有巨人的肩膀能够给我站一站。

准备工作做好后，我开始了真正的攻坚。为了通过机器学习更加精准地识别攻击，我从源头出发，开始逐条分析探针检测到的数据。在浏览海量数据之后我发现，WAF探针上报的告警数据的数据量级很大，误报占比也很高。我想如果通过机器学习的算法能够“学习”出正常请求的特征，对正常请求的数据进行建模，是不是就可以通过一个“白”模型。如果有这样一个“白”模型，那么对于一个正常请求进入模型，请求会符合模型所建模的特征，输出结果不会超出判定阈值；对于一个异常（攻击）请求，请求会偏离模型所建模的特征，输出结果就会超出判定阈值，异常请求就会被冒泡出来。

此刻心里还是没谱的，赶紧找师父讨论。最终我们总结出来：一是一个机器学习模型无法覆盖所有类型的攻击，也不太可能覆盖所有的WAF数据。所以可以通过建立多个模型，来检测各种类型的攻击，最终达到覆盖所有WAF数据的目的。二是我发现大部分有威胁的攻击都发生在WAF报文的参数字段，可以首先针对参数字段做检测，来识别攻击。这样应该可以识别大部分有威胁的攻击。有了以上两条大方向作为指引，最终我在众多算法模型中找到了一个最符合当下场景的“隐马尔科夫模型”算法，并且把从算法到解决方案的思路画了出来。

方案确定，我开始coding和测试验证，我有一个习惯，我会在真正编码前，把大致方案先设计好，这个方案我都会拿去跟导师讨论，他是个代码高手，可以帮我把关，也能提出一些更好的架构。开发过程一切顺利，最终在12月最后一天，我将最终方案在单机POC验证后进行了上线部署。一轮跑下来最终误报率控制在了1%，漏报率控制在3%。这个结果相比之前简直是质的飞跃，我和师父还有老陈长舒一口气，这场考验我们拿下了，而我之前脱口而出的“没问题”也没有被“打脸”。

现在，我们项目组基于老陈的“规则”和我的“算法”，已经构建了一个告警自动化分析过滤系统，从前每天需要人工查阅X万条告警数据，现在每天只需要看几十条就好了，这大大提高我们的安全运维效率，有效的保障了消费者云服务的现网安全。

收获一座“富矿”

因为这个项目我还有个额外的收获，我自己维护了一个多项式分布的隐马尔科夫模型源码库（Hidden Markov Model with Multinomial Distribution），它的优点在于可以支持分布式训练，可靠性更高。目前这个源码库已经在另一个项目中得到复用。

师父经常问我，你看论文不烦吗？说实话还真的不烦，因为兴趣所在，每看一篇论文就像经历一场旅行，收获的不仅仅是知识，还有对这个领域越发精通的满足感。感谢主管给我不断的试错空间，感谢导师亦师亦友毫无保留的指导，感谢WiseShield这一座数据“富矿”，这些让我的空间变得无限大。

虽然入职快一年，但是我对现在的工作早已产生了不可戒除的“瘾”，初生牛犊不怕“战”，眼下我正投入另一个入侵检测场景的战斗，探索“变现”的乐趣让我痴迷其中，无所畏惧！

本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com