一、读前必看
1、写这篇文章的心理动机
工作几年的时间里一直在从事技术相关的工作，自己闲暇之余和工作经历经常会有脉脉上所说的工作如同拧螺丝一样的工作。从个人角度的很长时间的确给我造成了很大的困扰，毕竟在国内鼓吹35岁技术人员就被淘汰的大氛围下，我也经常感受到危机感。我经过工作的几年时间对这个问题形成了一些思考。希望借此文分享给大家。
2、文章讨论的适用范围
技术人员成长从大体方法论而言分两类:一种是向上走,贴近业务或者架构、一种是往下走深入行业技术极限，开发一个更好的零部件或者工具。本文更多是论述比较高风险安全产品从产生到落地的过程。
3、适合阅读对象
安全产品经理
安全研发工程师
对产品感兴趣的安全工程师
二、组织开展项目研发前的准备工作
确定项目产出程度，即投入产出是否简单明了，我一般把项目分为复杂项目和简单项目，以下为个人经验作为界定，可能有误
复杂项目的特征:
1.安全产品需要公司多维度人员参与开发，如风控系统可能需要SDK，逻辑引擎，消息中间件平台，前后端多方面支持，可以拆分成多个微服务。
2.接入面积较广，可能成为不同业务线的接入。尤其大厂可能有不同的业务场景，都需要接入此系统，如比如直播搜索都需要接入此系统。
3.在生产流程上存在高危风险点，如分布式HIDS,WAF等在生产会侵入生产服务器进程或者流量转发流程，需要多维度配合。
4.项目的核心功能会超过20个接口以上的前后端耦合。
相对简单项目的特征：
1.管理流程类项目:项目仅侵入管理流程节点，并不会耦合业务与生产风险。
2.生产无侵入类项目:如日志分析类，蜜罐类相关的项目。
个人经验：简单项目可以采用全栈式开发的模式，即1-2个具有安全背景的研发工程师完成相关的工作即可。一旦出现复杂项目的特征，需要慎重考虑是自研还是购买第三方产品，下文的人员配比会详细的解释原因。
三、复杂安全项目的全流程闭环
越来越感觉到人的精力十分有限，精细化分工是社会提高生产效率演进的产物，具备科学性，但不是个人视野狭隘或抱怨自己拧螺丝的借口
3.1 复杂项目的全流程闭环
主要针对大型甲方的内部安全产品，乙方同学可以补充，主要区别在后方，不详细赘述
1.需求收集与运营流程闭环思考:
我们以大家熟悉的WAF来进行举例，在此阶段我们要考虑，我们研发的WAF有多少个业务部门要接入，他们有没有什么特殊的需求和顾虑要访谈收集。运营流程上我们的WAF有多少种视角(使用角色)，如一线RD想要 看什么，规则运营者关注什么，安全部门的Leader想要看什么，公司的CTO想要看什么，他们各自需要什么样的功能。
2.原型图制定与敏捷开发规划:
还以我们的WAF为例，WAF最重要的是Firewall意思即防火墙，所以Web Application Firewall这个名词的字面意思是首要需要进行开发的，即规则配置，规则运转，规则下发，拦截模块。结合上面需求调研的结果是首要优先出具原型图和prd文档。所以排期会比较明确。
3.架构模型的闭环:
基于一个WAF，我们做完原型图与规划后。需要才真正要站在研发的架构视角看问题。基于运营闭环与原型图的模板，我们技术怎么选型，拆成多少个大模块。消息队列用什么，怎么设计架构能让产品经理比较轻易的改需求(注意合理的改需求)。
4.多模块模块耦合的通信结构制定:
基于一个WAF可能，web配置平台后端逻辑通过HTTP接口沟通。命中日志与waf数据仓库通过kafka沟通。配置中心与waf核心模块可能通过etcd的kv与zk的树形结构进行同步。那么彼此的接口定义，json字段请务必先约定好。请用文档说话，不要嘴上说!!!
5.模块内部的设计模式分析与微服务拆分:
比如一个数据库读写的模块，以OO的思想。我们可以拆分为业务逻辑层与数据库原子层。那么数据库原子层与业务逻辑层是拆分成微服务还是写成一个模块，需要调研与分析。不怕大家笑话，我原来写代码SQL和业务逻辑写在一起的，结果改个需求，呵呵大家都懂得，真的有一种SQLboy的无力感。后来我才知道原来错的不是公司螺丝钉分工模式，错的是我不会写代码。
6.运营流程的闭环并loop 1-5:
平台做出来是要有人用的，那么势必会被吐槽。那么需要有人接受吐槽的point，并整理需求，反复loop1-5，当架构设计的越合理，当需求到来时改动的面积会越小。
3.2 自研人员到岗顺序：
1.产品与PMO第一到位：
负责产品需求的调研，业务线访谈，需求整理收集。一般安全产品的孵化有两个动机：
企业出了一些安全case想解决:
这种相对简单，毕竟公司内部会支持。分辨好项目简单与复杂程度，上述3.1中的流程进行实施即可。如果项目符合简单项目的条件，可以适当的压缩岗位人员角色，即一人多岗。但必要的流程还是需要。复杂项目请严格按照3.1的流程进行。
安全技术人员未雨绸缪看到风险觉得企业需要研发这个安全产品:
这种首先要做的是产品经理务必最先到位，去各个业务线进行需求调研。在一个人的安全部时经常我作为技术人员觉得很必要的事情，业务并不觉得，千方百计觉得自己造出了一个超级棒的”轮子”，结果业务不买账。自己成就感很受挫，当然受挫的不只有成就感，大家懂得。
2.架构师或资深研发工程师的到位:
他们主要的是针对于产品的需求进行技术选型和性能评估。
这里会存在产品与技术最经典的冲突问题，我也经历过，后来考虑清楚后与产品经理的合作无比愉快，主要问题如下:
产品主要从业务逻辑，流程闭环，功能原型图角度去思考问题。
技术更多是从可拓展性，业务稳定性，架构解耦，功能实现来思考问题。
这注定是两种视角如果不让步和不能切换视角注定是不可调和矛盾。
解决方法一：
产品经理切换视角下沉到技术视角，从技术设计拓展性而言与技术沟通，如话术：目前我们先做HTTP接入，未来可能考虑3种消息队列的接入方式，kafka，nsq，csv格式，所以请在设计这个模块的候做好接入冗余设计。并辅以流程图，原型图进行讲解。
解决方法二：
架构师或者资深研发工程师上升到产品经理视角。反问产品经理，进行业务合理性质疑，如：只做HTTP就够了么，公司有很多的消息中间件吧，需要兼容么?
3.研发工程师的到位:
这块比较简单，但也复杂。请用百分之40的时间写文档，对清楚上下游模块的格式与约定。百分之20的时间思考模块的设计模式怎样进行解耦，需求可能有怎样，百分之30的时间写代码，百分之10的时间思考边界处理是否清晰，单元测试是否完整。
在分布式系统中，边界问题处理不好会出非常大的问题，这就是为啥研发要专人专岗最合理的原因，比如分布式事务，分布式锁的场景，以及合理的监控报警，上下游的熔断机制与过载保护等等等等，身为一个一线的研发工程师，我们最要保证的是自己写出来的代码是设计模式优质切可靠的，并且出现问题后风险是可控的。
四、写在最后
这是我从安全转型研发后两年工作经验中踩到的一些坑，以及逐渐认知到自己的不足的一些过程，文笔仓促，如有不当之处请各位见谅。也欢迎感兴趣的朋友们相互交流，达到彼此的共同成长。
因为工作较忙，为保证产品落地的信息严禁性，并未在文中写过多的技术干货，欢迎私下交流。
