2008 年，我是看着《我的华为十年》这篇文章进入这家公司的，当时我的总监就是这篇文章的作者家骏。转眼云烟，第一份工作做到了现在。
菜鸟入职
我入职的时候，公司规模远没有现在这么大，北京地区的研发零星分散在中关村的几个写字楼，包括理想国际、普天大厦和银科大厦。
我是在普天大厦入职的，记得当时是 12 月份，第一次冬天来北京的我，领会到了啥叫冰火两重天。
在武汉是没有暖气的，屋外四度，屋里也是四度。北京是有暖气的，屋外零下十度，屋里起步价二十度。
公司里不少大姐大哥在公司里面穿的和夏天一样，出门套个大棉袄正合适。
我没经验，带着一身毛衣毛裤来的，结果在外面还是冻死，在公司里热死。
我大二的时候开始给华为三康做一些项目，在公司里面是不能上外网，而且都是又重又大的台式机。
入职的时候，行政小哥发给我个笔记本，我当时一激动就问了一句，这个回家加班可以用不？
行政小哥一脸懵逼，为啥不可以呀。
刚到北京的第一个月我是住在南二环的亲戚家，公司在拥挤的宇宙中心中关村，每天基本我就跟取经一样，天蒙蒙灰就出门，天漆漆黑回家。
第一个任务：防火墙双机上线
每一个自己觉得自己很牛逼的公司，都会有一个精心设计的新员工培训，有的像传销，有的像传教，有的讲情怀，有的忆苦思甜。我对新员工培训唯一的印象就是别在公司抽烟和养宠物，其他随便。可见当初一定有个在公司抽烟又养宠物的人把大佬惹毛了。虽然我不抽烟，但是我想养个小乌龟小金鱼，也只能放弃。
我的第一个任务是做防火墙双机上线，首先感谢组织信任，其次觉得专业好像有点不对口，我是个 rd 呀，虽然我懂点网络，不过也是写过交换机的软件而已。于是我硬着头皮看白皮书，看配置命令，幸好一起升级的还有经理黄姐和一个老员工永校，感觉自己打下手应该问题也不大。第一个任务总不能搞砸嘛，我还蛮认真的画了网络拓扑和配置回滚方案。其实仔细想想，双机以前不就是一个防火墙吗，现在就是再放一台上去呗。
为了不影响业务，我们选择在元旦凌晨上线。上线的过程确实非常顺利，简单描述，就是把新防火墙放上机架，插上电，配置灌进去，接线，搭完收工。十分钟不到搞定了，我都准备撤了。
老员工说，这才哪到哪呀，我们要验证可以自动切换。新防火墙和老防火墙之间有两根心跳线，汇聚层有大概 6 台汇聚层交换机，分别会连到两台防火墙上，要验证诸如心跳线段，上联线段的情况。另外国内众所周知的原因，分为南北网，联通电信互通很差劲，防火墙上联四根运营商的链路，还要测试这几根线路断的情况下的自动切换。于是乎，不停插拔网线，ping 新浪 ping 搜狐。测试完凌晨 4 点了，总算搞得差不多了。我记得我走出普天大厦的时候，居然看到了 2009 年的第一个日出了。
第一个项目：准入系统 BNAC
我的第一个项目是开发准入系统。所谓的准入系统，简单讲，就是上网认证，主机安全检查加上网络权限控制。满足一定安全基线要求的终端才允许接入公司办公网，并且根据不同的部门和职位，赋予不同的网络访问权限。
公司当时已经买了号称全球顶尖的准入系统，不过在易用性和可定制性上差强人意。另外一个原因，我们总监最初在华为就做了第一套准入系统，他对准入的理解非常深刻，从他的角度来看，目前这个国外的准入系统，有线无线不能自动切换，不能和微软的域管理集成，权限管理过于死板，最坑爹是对网络设备有要求，捆绑销售他们的防火墙。
这些在传统企业不是太大问题，但是在互联网公司就是硬伤了。于是我入职前基本就拍下来要自己研发准入系统。他老人家是理解深刻，我理解不深刻呀，从网上搜了个遍，还是一知半解。还好有个老安全工程师志刚领路，介绍了一些厂商进行交流，总算整明白咋回事了。于是开工干活，整个系统分为客户端，策略管理平台，测试管理服务器和防火墙。防火墙由系统部的一个大拿负责写网络控制模块，现在这哥们是我们公司 CDN、流量清洗这些基础设施的负责人。
客户端的主机检查模块由我们另外一个安全工程师负责，他现在也是 BAT 某公司的高 P 了。其他都是我弄的，第一次写网页还有点小兴奋，尤其是自己画 logo，尽显人文修养。我在学校用 delphi 写了系的教师考评系统，在那个年代 dephi + sqlserver 是绝配，access 也面对小 case 也是 ok 的，因此我们考核系统也是 cs 架构的。惯性思维，我的客户端也是用 delphi 写的。为了支持使用 linux 办公的同学，还开发了 linux 客户端。
网页完全是新接触，用了当时比较新的 groovy。这个时期我接触了大量新知识，这些开发语言还是其次，主要是认识了不少网络设备，接入层的从啥 hub 到二层交换机，三层交换机，还有啥无线 AP 和 AC。和部署实施比起来，开发这个阶段是多么美好的回忆，事实上我差不多 3 个月开发完了第一版，为了验证有效性，我们打算在部分办公区部署。于是我们开始杀熟，先在我们部门使用，我待人和气的好脾气也是这个阶段养成的。
我们把我们部门的办公区的接入交换机和汇聚层交换机之间传入了防火墙。所谓的防火墙其实就是台服务器，最早用的是 dell 的 2850。现在看起来 2850 的配置确实差的可怜，四核八G内存，六块七十三 G 的大硬盘，还齁沉齁沉的。我一个人搬它还很费劲，经常要和一个叫大肉的老员工一起搬。
由于当时交换机的机柜就在办公区，我们的防火墙也只能放办公区。别看 2850 配置不行，风扇确极其彪悍，一开机地动山摇，半层楼能听见。经常可以听到旁边部门骂，谁这么缺德把服务器放办公区，还让不让人上班生孩子啥的。
我们公司没有花名这一说，但是我处于怕人知道我真名骂我，我很早就用花名了。差不多那个时候开始叫麦兜了，至少名字这么可爱，大家骂的时候也有所估计，后来岁数大了开始叫兜哥了，这也是我网名的由来。
总被骂，确实也觉得对不起大家，所以一直到现在也待人客气。还好除了吵，基本没出现过断网的问题，偶尔出现过奇葩软件和客户端不兼容的情况，也很快解决了。在那个蠕虫病毒泛滥的年代，我们通过准入系统强制电脑安装杀毒、安装补丁、开启防火墙等等，简直就是功德无量，很多年都没有发生过大面积的病毒感染，一直服役到现在，差不多有 9 年了。我到现在还记得家俊在部门会上说某某厂做准入几百人，我们就搭进去个麦兜。
枪版网工生活
2009 年，全部门的重点就是建设新大厦，所谓的新大厦，就是现在我们叫的老大厦，就是西二旗旁边那个某大厦。当时网络工程师就三个人，大肉，秀英和永校，人手不够就把我也搭上了。我是革命一块砖，哪里需要新员工哪里搬。
这次真成网络工程师了。小时候觉得工程师很牛逼，工作后发现其实叫网工更合适，就和电工一样。好在安全工程师说起来还有点黑客帝国的感觉，即使简称安工，也感觉和同仁堂的救命神药安宫硫磺一样牛逼哄哄的。不过我们这几位网工可牛逼了，一个是 3com 和华为研发出身的，另外一个是 2008 奥运会的网络建设负责人之一，相比我就是渣渣了，而且还是业余渣渣。
给我的第一个任务是生成全部网络设备的配置，大概是 500 多台有线交换机，200 多台无线 ap 和交换机的配置。当时在奥运会的时候，他们是规划好 IP 地址后，通过一个 java 的程序手工配置参数后生成一个设备的配置，然后通过 securecrt + js 脚本 + 串口把配置文件灌入设备。有多少台设备就要手工配置多少次，不过这个已经比手工写配置文件牛逼很多了。
当时对我的预期是把思科设备的文件改成华为设备的。我对网络设备的配置完全是工作后学的，半桶水都不到，也是这个时期我学会了思科和华为设备的使用和配置方法。我看懂了原来的程序后，发现其实把网络规划体现到电子表格后，通过程序读取数据，可以一次性生成全部配置。而且这都是纯文本的活，用 perl 更合适。于是我重头开始写，差不多一周多业余时间完成了 demo，当时我还写准入在。
中间也出过不少问题，比如关键字写错了，思科的一些命令没改，有些参数写死了，最后又改了几次才能用，虽然被骂的也挺惨，不过最后对我评价是超出预期，大大节省了网工的工作量，唰唰唰 10 分钟可以生成全部配置。尤其是有次网工发现自己电子表格写错了，要是以前他需要一台一台配置去生成，但是我这边重新 run 一下就好了。
那段时间我还在陪大肉升级交换机 OS 和灌配置的过程中自学了 CCNA 和 CCNP，现在也很怀念和大肉在信威大厦里面灌配置的日子。那段时间玩命加班，几乎 3 个月没有咋过双休，最后竣工的时候居然有了 19 天调休。一直到现在，如果面有网路经验的安全工程师时，我总能扯好久，一直可以问傻别人，也是这段时间积累的。
内部安全建设黄金时代
这个时期是我们公司内部安全建设的黄金时代，很大一个原因是我们有了级别非常高的 CIO John Gu。John 长期在国外工作，一直做到几个巨型企业的 CIO。相对国内私企，国外企业对安全重视很多。和 John 不用太多介绍安全的重要性，而是想好怎样做好安全就可以了。为了有更好的视野，我们还挖来了埃森哲的架构师欧阳。大概有 2-3 年的时间，我们都有非常充足的预算的进行安全建设，我也开始带 team。这段时间我的工作才开始接近我理解的安全工程师和甲方安全。
这段时间我比较系统的建设了内部安全体系，从企业杀毒、终端补丁管理、DLP、邮件安全网关、IPS、漏洞扫描器、上网行为审计、APT 检测到终端安全加固、软 token、堡垒机、应用虚拟化、硬盘加密、文件加密等。那个时期，负责互联网公司的国外安全厂商的销售，应该大部分认识我。这段时间，是我安全知识面扩展非常快的一个时期。一直到现在，我跟许多解决方案架构师沟通很顺畅，也是得益于这个时期积累的知识。我后面可以承担 PGM 的工作，有相当一部分原因是我对安全产品需求的感觉，这种感觉的培养其实也来自于我这段经历。
云安全部成立
在很长一段时间，我们没有安全部，安全的职责分散在技术体系下不同部门的几个组里面。早期问题并不大，大家各司其职，但是当公司发展到一定程度后，对外的产品线日趋繁杂，内部的协同配合压力日趋变大。于是在某年某月的某一天，我们几个分散的小组合并成立一个新部门，曰云安全部。人员合并后按照每个人的技能重组团队，我负责基础架构安全的 team，曰 isec，职责范围包括内部网和生产网。我的核心 team 成员也是从那个时候一直和我到现在，现在想想也真不容易。
与内网相比，生产网有趣很多，安全工程师的压力也大很多。物理服务器的数量达到数万甚至数十万，虚拟机以及容器数量起步价也是百万级了，出口带宽几百 G 的机房遍布全球，涉及的产品线更是复杂到令人发指，只要想的到的业务几乎都有，想不到的没准也有。相对内部网，生产网攻击面大很多，毕竟这些业务是 7 乘 24 对数亿网名提供服务的。我们面对的最大挑战就是如何在业务不中断，不损失访问流量的情况下保障业务的安全。因此我们的重点一个是安全加固，一个是入侵检测，其中入侵检测是我很喜欢的一个领域。在国内，入侵检测经常被理解为 IDS/IPS 这样的安全设备。在以 web 浏览访问以及手机 app 访问为主要业务形式的互联网公司，入侵检测覆盖分范围非常广泛。
我首先遇到的一个问题其实不是技术上的，如何衡量我们所做的努力对公司安全状况的贡献。换句话来说，就是如何描述我们做的事的产出。在大多数公司，甲方安全都是地道的成本中心，纯成本消耗。如何证明安全团队的价值是非常重要的，即使是在一个超大型互联网公司。我观察到有些同学其实干的也很苦逼，情绪低落，总是抱怨。确实他负责很多小项目，每个事情看似很重要，但是确实也看不到啥产出，感觉做不做其实也一样。于是明显的恶性循环也产生了，一个事情没做成业绩，就继续做另外一个，结果下一个也没做出成绩，继续做下一个，手上一堆烂尾楼，还要抱怨辛苦没人看到。
在那个时候，某知名漏洞平台还在，上面报的漏洞公司层面还是非常重视的。于是我想到一个重要的衡量指标，就是安全事故的主动发现比例。比如拿到服务器的 webshell，SQL 注入点和敏感文件下载，这些都是影响大且容易量化的。如果能够通过我们开发的入侵检测系统，提高我们主动发现入侵事件的比例，这个贡献是非常容易体现的。我们在相当长的一段时间就是从各个维度想办法提高这些指标，其中印象深刻的就是 webdir 和 dbmon。
webdir&dbmon
webdir 和 dbmon 是我们内部取的名字，简单讲 webdir 分析 web 服务器上的文件，及时发现后门文件，dbmon 分析数据库日志，及时发现 SQL 注入点以及拖库行为。通过这两个项目，我的 team 从一个安全技术团队开始向一个安全产品团队衍变，除了负责应急响应和渗透测试的的安全工程师，开始出现有安全背景的研发工程师以及负责 storm 和 hive 的大数据工程师，人数也开始两位数了。
webdir 在一期的时候，主要是依赖收集的样本提炼的文本规则，简单有效，在部署的初期发现了不少 case，部署的范围主要集中在重点产品线，量级在一万台左右。我们在二期的时候，重点工作是一方面提高检测能力，一方面是减少发现的延时，另外一个方面是全公司部署，这三方面都是为了提高 webshell 的主动发现比例。
在检测能力方面，主要是提高准确率和召回率，关于这两个指标的含义，有兴趣的同学可以看下我机器学习的书，里面用小龙虾和鱼来做了形象的比喻。基于文本特征的 webshell 检测，很难在这两个指标之间做平衡，尤其是我们这种超大规模的公司，即使是每天新增的文件也可能上亿，实验室环境看着还蛮不错的检测效果，误报也会被放大。因此大多数安全工程师的选择就是写极其精准的规则，所谓精准，就是根据搜集的样本写的过于严格苛刻的规则，用于大大降低误报。这导致的结果是，误报确实少了，但是漏报也非常严重。
我们仔细研究了下问题所在，主要是由于 php 语言的高度灵活性，一个很简单的功能可以用多种方式实现，还有不少装逼的语法。单纯在语言文本特征层面做非常吃力。通过调研，我们发现不管文本特征层面如何做绕过我们的检测，最后 webshell 还是要以 php 和 java 的语法来实现，如果我们可以实现 php 和 java 的语法，就可以在更底层提取特征，与黑产进行对抗。
这个思路也一直影响了我们后面的流量分析产品以及基于机器学习的 webshell 识别，不过这个是后话了。这个思路也成为我们二期的主要提升点，当时根据我们搜集的数千样本，挑选了专业的安全产品进行测试对比，我们的两个指标综合领先。我们另外的一个挑战是工程上的，我们仅在国内就有大量的机房，每个机房之间的带宽不尽相同，而且使用率也大不相同，即使是固定的两个机房，带宽使用也有明显的时间特征。
另外互联网公司大多把服务器的性能压榨的非常腻害，运维部门对我们的性能指标限制的非常死，甚至超过一定的 CPU 或者内存就会自动把我们进程挂起甚至 kill。为了尽可能降低服务器的性能消耗，我们使用云模式，负责的语法解析与规则匹配放到云端，服务器上仅需要完成非常简单的处理和上传逻辑。但是几十万个服务器如果因为上线新版本同时出现新文件需要检测，也可能会出现带宽的异常消耗，于是我们也使用了去中心化的部署方式。
一群只玩过单机版 syslog-ng 分析日志的土鳖，一下子可以有上百台服务器，还用上了大型消息队列和自研的沙箱集群，想想确实很有成就感。二期上线后，无论从部署范围还是检测能力上，都上了一个新台阶，并且由于检测技术上的创新以及客观的评测结果，这个项目获得了公司层面的创新奖。在这个项目上另外一个收获是开发服务器端的程序的经验，在一个如此大规模的集群上部署客户端，还要做到性能消耗小，考虑各种异常情况的处理，考虑各种兼容性问题，这些都是干过才能积累的。
dbmon 在一期的时候，依托于公司运维部的 DBA 团队的现有系统，离线分析公司部门产品线托管的 mysql 查询日志。检测的效果确实不理想，一堆暴力破解的报警，仔细一查都是密码过期了。检测的重点没有放到 SQL 这些上，而是更像针对数据库的异常访问检测了，这个其实从实践角度，安全人员很难去定位问题，小同学弄两次就烦了，所以效果一直很差，最后运维系统的同学根本不想看报警了。
二期的时候我们聚焦到 SQL 检测上，相对于 waf 和流量层面，SQL 日志层面做 SQL 注入点检测非常合适，因为在 http 协议层面可以有大量绕过 sql 注入检测的技巧，但是最终还是会落地到可以执行的 SQL 语句，在 SQL 日志层面会大大简化这方面的检测，相对于负责的 WAF 规则，SQL 日志层面上的检测是在黑客难以控制的更底层进行对抗。在这个阶段即使是文本特征的检测，在准确率和召回率上表现已经不错了。
上线效果非常好，同学们对这个也有了信心。集思广益，在三期的时候我们在 SQL 层面尝试了也使用语法而不仅仅是文本规则检测，不过这个是后话了。也是通过这个项目，我们团队熟悉了在 hadoop 和 storm 环境下的开发，值得一提的是，通过使用 storm 我们把检测延时大大缩小了，另外由于把 storm 性能压榨太腻害，我们在一次事故中发现了 storm 的一个深层 bug，storm 中关于这个 bug 的修复代码就是我们提交的。作为一个土鳖，我们很自豪可以把 storm 玩到这个地步。
另外一个收获是，为了在应急响应时查询日志方便，我们把常用的日志部署在 ELK 集群上。起先没有经验，每天大约数十 T 的日志部署在常见的机械硬盘上，运行起来非常慢，一个查询内存居然还爆了。后来在大数据部的大拿指导下，我们混合使用了固态硬盘和机械硬盘，启用单机多示例，优化内存和 java 配置等，搭建起了 50 台物理服务器的 ES 集群，每台机器上双实例，当时 github 也才维护了不到二十台 es 服务器。同样在实战中我们熟悉了 kafka、hadoop 的优化，这个让我的 team 也有了大数据处理使用经验，这也为后面我们完全转向安全产品团队打下了基础。这种通过更底层进行降维对抗的思想，也影响了我的安全观，后面我们开源的 openrasp 也是这一思路的另外一种体现。
土鳖 PGM
机缘巧合，又遇到一次方向调整，部门的重点是对外提供商业安全产品，为此我们还收购了一家公司，这个是对我影响比较大的一次调整。相对于办公网和生产网的安全，商业安全产品的收益更加容易量化，而且可以服务更多的用户，得到更多的一线反馈。以前在游泳池游的，现在可以在大海里游了。
这时我们已经有 WAF 和抗 D 产品了，以及渗透测试服务。现在需要做的是丰富产品线满足不同层次的需要。起先我想到的是把 webdir 和 dbmon 产品化，因为确实效果不错。但是和几个用户聊完后，不是很感冒。先说 webdir 吧，在我们公司内部部署啥都好说，毕竟我们够强势去做这个事情，运维的同学不管心里服不服，表面上还是认可我们的。但是在不少互联网公司，安全工程师没有那么强势，恰巧在服务器上安装安全软件，容易导致一些纠缠不清的问题。所谓纠缠不清只可意会不可言传。
另外，程序需要直接扫描 web 代码文件，这个又是个敏感问题。dbmon 的问题也是类似，尤其是对于不少公司，数据库是不开启日志的，更别说是还要把日志从服务器搜集上来了。换句话来说，如果是影响业务的检测类产品，没准可以有市场。于是我们抱着尝试的心态，也没和老板吹啥牛，默默先做产品化，小步快走。我们把之前我们在公司内部做全流量镜像分析的系统做了产品化，相比于公司内部起步价 20G、50G 甚至几百 G 的带宽，用户侧上 1G 的都很少，于是我们做了很多简化处理，更多考虑的是便于部署和稳定性。
整个移植的过程其实比较简单，毕竟有点杀鸡用牛刀的感觉。销售侧也帮我们找到了几个天使用户，由于产品比较新，售前不懂，我就和销售去和用户介绍。还记得第一个用户部署测试的时候，第一天就发现了潜伏了好久的一个后门，当时正有人在使用这个后门。用户那安全设备其实部署的也不少，但是还是有这个后门，当时对方的安全负责人一激动就说他们全部机房都要部署这个。于是第一单就这么成了，互联网公司果然就是爽快。后面一段时间，我和销售一起见过不少客户，通常我们测试的用户都会有微信群，大家反馈问题都在微信群里，我那段时间经常在微信群里和用户沟通交流，产品侧的问题我们很快就迭代修改，经常上午反馈的问题我们下午就可以上线。
很多人好奇我回微信咋那么快，其实我对手机的重度使用也是那个时候开始的。我的好脾气也在这个时候展现了优势，很多产品细节使用的问题，每个好脾气就会忽略了。现在回顾那段时光，其实我们产品最后可以有不少用户，得力于从售前、测试、研发和售后的沟通顺畅，基本是把我搭进去了。我也使用过商业产品，通病是这四个环节非常脱节，越大的公司问题越大，因为公司越大，分工越细。售前不懂技术细节，满口跑火车的也不少见，售后只会抱怨说不清产品问题所在也正常。研发天天赶进度，自嗨的增加功能，不屑与没技术含量的功能修改也是常事。在我们产品的初期这些问题很少出现。一直到现在我都对这段经历很感慨，如果一个产品经理能说出自己产品哪里牛逼，其实不算牛逼，如果还能说出自己产品哪里不如竞争对手的，这个才算有点牛逼了。各种原因吧，其中肯定也包含我这段经历的加分，我后面负责了整个 web 安全产品的产品和技术，我们内部叫做 PGM，整体打通去看这些产品。有人说我安全圈认识人咋这么多，很多一部分是这个时间积累的，其实我在外面开会扯的很少。
兜哥带你学安全
不得不提的是我的公众号，这与我之前做安全产品的经历有一定的关系。我接触到不少从事互联网公司一线安全工作的童鞋。刚接触我的时候还是蛮防着我的，生怕我是来骗钱的。其实也可以理解，有点预算的甲方，估计都被乙方洗脑 N 遍了。另外我长的比较喜感，眼神比较清纯，人来熟，不像大家对黑客或者说安全从业人员的印象。接触几次后逐渐建立了信任，大家也比较聊的开了。虽然安全技术一直在演进，各种新的思想和概念也不断涌现，几乎每年安全会议的侧重点都会不太一样，大数据、AI 再到区块链。安全的攻击形式也层出不穷，针对 web 的、智能硬件的、AI 模型的等等。
但是一个现实是，甲方的需求和乙方介绍的技术和产品的鸿沟却一直不断扩大。一些很基础的安全加固知识可以搞定的，一些通过配置就可以搞定的事情，黑产关注了，但是大家却没怎么关注。mongodb、es 之类匿名访问放到公网裸奔，直到被加密勒索了；没打补丁的 window 服务器防火墙也不打开，还对外提供服务，直到被人全盘加密勒索；智能摄像头的 root 密码也不改，放到公网还拍些敏感内容，结果被人一个初始密码就劫持了。
我把我的一些经验和大家分享了下，发现大家蛮感兴趣。于是我抱着玩的心态，开始写我的公众号。起先我也没有多大把握会有多少人看，毕竟讲的都是些基础干货，比如如果做网络区域划分和隔离策略，如何对无线网络安全加固，生产网的服务器如何做加固等等。开始的时候，我是遇到用户问的问题，就把公众号里面相关的发给大家看。没想到一下子转发的很多，关注用户数涨的不错。最后我把文章进行了分类，分为了企业安全和 AI 安全两个板块。我公众号并不追求思路多新多领先，就是想成个小笔记本，大家有需要时可以找到使用的办法，一不小心成了一个粉丝数相当不错的安全自媒体。
AI 探索
大概在 2014 年底还是 15 年初，组织架构调整，我收了一个研究机器学习的小团队。团队的 leader 是个非常活跃的小孩，而且特别有激情。他一直鼓捣我增加在机器学习方面的投入。
当时 HC 控制非常严格，但是我还是被他传销式的汇报感动或者说屈服，我尽力支持他。当时我们在线上环境的离线数据上做了大量的尝试，在部分场景下也取得了不少进展。也是这个阶段，我对 AI 建立起了信心。我开始重新梳理 AI 比较成功的使用场景，然后尝试移植到安全领域。那段时间我自学了机器学习，也经历过激情澎湃地买了一堆机器学习书籍后发现一个公式也看不懂的尴尬，几次想放弃。最后我发现自己是码农出身，我对代码的理解能力远强于文字和公式，于是我从有示例代码的书籍学习起，逐渐理解了机器学习的常见算法。
如何挖掘场景并使用合适的算法呢？
这个确实靠悟性和经验，很难就靠看书就理解了，需要大量的实践。我投入了大量的个人时间用于学习和实践。熟悉我的人都知道我喜欢看电子书，我的电子书里除了老罗的书和几本历史的书，基本都是机器学习的书。每天上下班有将近一个小时在城铁上看书，算起来一个月就是 20 个小时，约 3 个工作日。回顾这段学习的经历，我的感受是机器学习的学习坡度很陡，所以很多人会半途放弃或者一知半解，但是这恰恰是它的门槛。 sqlmap 的常见命令一天掌握问题不大，你觉得是门槛吗？
写书
为啥会写书呢？
说起来原因很简单，因为我的公众号和文章经常被人抄，有去掉我水印的，有去掉我图片的，还有完全抄只是改作者名称的。抄袭的有自媒体，有小媒体，还有一些厂商，我也无力吐槽和维权。最后我就写书吧，抄我的好歹你要买一本复印。也正是这段被抄袭的经历，我的书和 PPT，尽量连引用的图片也标注，算是一种尊重吧。
写书的选材，我选择了 AI 安全，而不是企业安全。因为实话实说，企业安全也不急于一时，市场上已经有了，但是 AI 安全的却没有。另外，大家其实对于如何使用 AI 做安全更多停留在概念层面。更有甚者，在 PR 稿上就是罗列一堆公式，然后说人能识别威胁，人能看病，所以他能用 AI 搞定。我也只能呵呵。
基于这复杂的原因，我开始写我的 AI 安全书籍。由于 AI 的知识太多，最终定稿成三本，一本讲入门的，叫《web安全之机器学习入门》，一本讲实战的，叫《web安全之深度学习实战》，目前都已经出版了。出版前我很担心卖不出去，结果让我非常意外，从甲方到乙方，从国内到国外，都有我的读者，就在今天美国 fireeye 的一位总监，当然也是我好友还在朋友圈 show 我的书。还要感谢我的几位老板帮我写序，以及众多业内好友的帮助。据说我的书还入选了出版社的计算机类年度十佳。感谢 Freebuf 的提名，我在 FIT 年度安全人物评选排到第三。
生命不息折腾不止
也许我继续做我的安全产品，今天改个 bug，明天加个按钮，日子也慢慢也会过去。具体的产品也有具体负责的经理，我把经理管好就 ok 了，我也可以过的比较 happy，就和以前巨牛无比的万能充一样。当年万能充卖的火热时，哪里会想到现在充电接口统一后，再难见到它的踪影。
时代抛弃你的时候，连招呼都不会打。尤其是你觉得舒适的时候。
我自己研究 AI，我的几次转型，其实都是我主动的走出了舒适区。就像我最近，以 30 岁高龄，从带团队的，转去实验室稿新产品预研一样。在一堆 20 多岁的小伙子高呼搞技术没用，要搞管理岗的时候，我选择了在一个技术型公司继续深耕技术。我有自己的技术理想，我觉得搞这些蛮开心不枯燥。
精彩待续
我的奋斗还在继续，精彩等着我继续谱写。
想知道更多关于兜哥的故事吗？欢迎大家关注兜哥公众号，满满的技术干货分享哦
后续安全客还会发布兜哥的新书推荐活动，欢迎感兴趣的小伙伴来围观哦~
【文章转自bgp服务器 http://www.558idc.com/yz.html提供，感恩】