0x01 拓荒时期
最早期设计调度器的原因基于当前环境有个需求，需要使用调度器通过安全平台API将任务全部拉取下来，并根据平台的扫描参数进行任务的下发、执行、状态的判断、结果拉取。
调度器生命周期
当时没有特别多的想法，只想一路往前跑，不管结果如何，先上，毕竟安全团队属于刚起步阶段，在创业公司，如果没有创造足够的价值，随时都有可能被干掉，这种危机感逼迫着自己前进。
拓荒周期图
由于时间有限，我们需要在极短的时间将工具链条输出，让运维人员和安全人员上手，并且大幅度的提高整个自动化的能力，所以，在设计上比较粗糙，并没有做过多的深入。当时想的是，能够满足一个小阶段的需求，就ok，毕竟内部安全产品是需要不断的迭代和打磨，才能真正的走向业务。
调度器v1.0
千万别小看它，在前面任职的公司也曾用它，现在的公司也在用它虽然版本更新了，fix了部分的bug。在线上跑的时候，遇到各种问题，首先最大的问题就是用户的输入无法掌控，明明特别好的东西，到用户手里可能就变了。针对这些坑让人实在头大，且之前的架构由于着急上线，没有做完整的梳理，导致问题越发严重，初步列了下这个版本出现的问题：
- 守护进程down掉，没有任何的提醒。
- 用户输入异常，调度器在读取数据的时候没有做容错，导致调度器死亡。
- 日志记录不清晰，只记录了关键代码以及关键位置，但是针对一些高频的动作没有做记录。
- 封包依赖太多，导致安装过程困难，运维成本提升。
- 逻辑耦合太多，没有做线点拆分。
- 数据没有统一化管理，多点、多文件，定位故障困难。
0x02 革命时期
针对这些问题，做了一些梳理，跟内部的安全、运维的小伙碰了下，决定将调度器改了，把这些坑先灭了再说。旧的先让业务跑着，不中断。新的在后面尽快开发、测试上线。
我们先把整个架构梳理了一遍，把我现在有的或者准备整合的业务做全面的梳理，看看调度器具体要管的节点有哪些，根据这些节点，设计不同的微服务，并且将服务和schedule进行全面的耦合。
微服务群
这会正好Bingli在顺丰过得不太happy，毅然决定加入拉勾安全团队。（<code>对于有想法有能力的小伙，老板重来不看学历，只看输出，这里给我们@侯老板点个赞。</code>）我们开始谋划着这个调度器的设计，不断碰撞，不断把思路捋顺，这次没有着急动手，原因是想规避之前的错误。
新的调度器技术选型用的是nodejs来做整个调度器，在刚接触这个语言的时候，我就深深的爱上了它，node这个轻量舒服的语言简直就是为调度器量身定做的，同时，在国内有专业的社区支撑以及安装配置简单，毫无压力，版本差异化没有特别大的问题，就这点，我相信这就是运维的福音，果断的就选择它。
- 开发: node.js v6.3.0
- DB: mysql/redis
0x03 摸索到的问题
新的调度器开发的过程特别顺利，花了短短两天多点的时间，我就把整个调度器都改写一遍。
调度器请求功能
异常记录
我们这个阶段解决的问题：
- 调度器需要多纬度的支持，不管新接入的是什么设备，什么工具，都需要以配置化，活体动态加载；
- 针对抓取的数据，做双层检测，确保数据是正确的，同时在重要的功能部位加入埋点，确保数据可控；
- 调度器需要设置失败的监控，错误重试，并且上报异常等动作，确保重要感知；
0x04 线上running
在调度器竣工后，我们直接用在新的环境上，在后续，我们只需要专注扫描节点的开发即可，当然，为了满足短期的需求，web上的功能我们也已经完成，研发可以在上线之前自动开启一个扫描来确认风险是否存在。
添加扫描
web扫描功能
0x04 写在最后
每个迭代打磨都是对技术的锤炼和感悟，所有的菜鸟都是从这个阶段过来的，感谢机会，感谢身边的人。
网友评论