停摆了半个月，对过去事情做个回顾，这是第一篇，关于产品设计的。
一直有个执念，将简单繁琐的工作自动化，将复杂的工作半自动化。不管是自动化还是半自动化，归根揭底都是依靠程序。有幸的是自己参与了两年的产品工作。期间踩了不少坑，这里算是做个简单总结吧。
安全类的产品和其他产品有个区别，就是多了个安全能力，所以整个项目组里就多了几个懂安全的人去实现产品所要具备的安全能力。换言之就是安全工程师将安全能力抽象成规则或者模型赋予产品，进而实现对某种、某类威胁的检测。
着重说下检测这一块吧，检测能力相当于整个产品的核心，承担检测这个角色的时候要考虑几个问题，当前的检测模块易用性，可扩展性和去误报性。
易用性，简单来说就是学习成本，当项目组来新人的时候，他能在多久时间内就知道该怎么做；在和业务对接的时候是否简单便捷。
可扩展性主要是看产品未来的规划能不能在现有的规则模板上进行扩展字段解决。
去误报性主要是当产生误报的时候你的产品需要多久时间可以解决。
如果一个安全产品能满足以上几点，对自己对他人的工作都能减轻不小的负担。
那么如何设计检测模块呢，我想大概分为
分为三个阶段吧。
1. 要做什么
2. 业内是否有对标的案例
3. 怎么做
第一个阶段，即确定产品方向，我们的目标是什么，要做出一款什么样的产品，要解决什么样的问题。
第二阶段，目前在做的东西，业内是否有成熟的案例，如果有，做出来的东西比他们的优势是什么。如果没有，这时候就需要多读书，参考文献去决定路的走向。
第三阶段，是需要做决定的阶段，基于前两个阶段收集到的资料，确定该怎么实现既定的规划。
关于这个阶段分享一些不成熟的想法，我觉得不管怎么做，最终的能力都必须抽象成模块或者数据接口的形式提供给业务。本着这个思想，接下来就需要从技术角度对要做的产品拆分模块，拆分子功能，进而了解每个模块下的功能涉及到哪些技术，找到功能之间共同点和差异点。确定在技术实现能不能用一套框架。
设计框架的时候要遵循整体统一，局部差异。大概意思就是从共同点出发，求同存异。举个例子，要对每个域名的a、cname记录进行检测，两个检测项都是基于dns协议来做的，那么大的框架就基于dns来做的，然后在大的框架下对局部功能进行实现。
切记不要为了实现某个功能增加整体的耦合度，这样带来的坏处，随着时间的推移慢慢就暴露出来了。
前面说了那么多，总结下来就是全局思考，分析关联，求同存异。最后，关于产品/工具开发的一点愿景吧，低代码，高可用，易扩展。
