[[274885]]

一、讀前必看

1、寫這篇文章的心理動(dòng)機(jī)

工作幾年的時(shí)間里一直在從事技術(shù)相關(guān)的工作，自己閑暇之余和工作經(jīng)歷經(jīng)常會(huì)有脈脈上所說的工作如同擰螺絲一樣的工作。從個(gè)人角度的很長時(shí)間的確給我造成了很大的困擾，畢竟在國內(nèi)鼓吹35歲技術(shù)人員就被淘汰的大氛圍下，我也經(jīng)常感受到危機(jī)感。我經(jīng)過工作的幾年時(shí)間對(duì)這個(gè)問題形成了一些思考。希望借此文分享給大家。

2、文章討論的適用范圍

技術(shù)人員成長從大體方法論而言分兩類:一種是向上走,貼近業(yè)務(wù)或者架構(gòu)、一種是往下走深入行業(yè)技術(shù)極限，開發(fā)一個(gè)更好的零部件或者工具。本文更多是論述比較高風(fēng)險(xiǎn)安全產(chǎn)品從產(chǎn)生到落地的過程。

3、適合閱讀對(duì)象

安全產(chǎn)品經(jīng)理

安全研發(fā)工程師

對(duì)產(chǎn)品感興趣的安全工程師

二、組織開展項(xiàng)目研發(fā)前的準(zhǔn)備工作

確定項(xiàng)目產(chǎn)出程度，即投入產(chǎn)出是否簡單明了，我一般把項(xiàng)目分為復(fù)雜項(xiàng)目和簡單項(xiàng)目，以下為個(gè)人經(jīng)驗(yàn)作為界定，可能有誤

復(fù)雜項(xiàng)目的特征:

1.安全產(chǎn)品需要公司多維度人員參與開發(fā)，如風(fēng)控系統(tǒng)可能需要SDK，邏輯引擎，消息中間件平臺(tái)，前后端多方面支持，可以拆分成多個(gè)微服務(wù)。

2.接入面積較廣，可能成為不同業(yè)務(wù)線的接入。尤其大廠可能有不同的業(yè)務(wù)場景，都需要接入此系統(tǒng)，如比如直播搜索都需要接入此系統(tǒng)。

3.在生產(chǎn)流程上存在高危風(fēng)險(xiǎn)點(diǎn)，如分布式HIDS,WAF等在生產(chǎn)會(huì)侵入生產(chǎn)服務(wù)器進(jìn)程或者流量轉(zhuǎn)發(fā)流程，需要多維度配合。

4.項(xiàng)目的核心功能會(huì)超過20個(gè)接口以上的前后端耦合。

相對(duì)簡單項(xiàng)目的特征：

1.管理流程類項(xiàng)目:項(xiàng)目僅侵入管理流程節(jié)點(diǎn)，并不會(huì)耦合業(yè)務(wù)與生產(chǎn)風(fēng)險(xiǎn)。

2.生產(chǎn)無侵入類項(xiàng)目:如日志分析類，蜜罐類相關(guān)的項(xiàng)目。

個(gè)人經(jīng)驗(yàn)：簡單項(xiàng)目可以采用全棧式開發(fā)的模式，即1-2個(gè)具有安全背景的研發(fā)工程師完成相關(guān)的工作即可。一旦出現(xiàn)復(fù)雜項(xiàng)目的特征，需要慎重考慮是自研還是購買第三方產(chǎn)品，下文的人員配比會(huì)詳細(xì)的解釋原因。

三、復(fù)雜安全項(xiàng)目的全流程閉環(huán)

越來越感覺到人的精力十分有限，精細(xì)化分工是社會(huì)提高生產(chǎn)效率演進(jìn)的產(chǎn)物，具備科學(xué)性，但不是個(gè)人視野狹隘或抱怨自己擰螺絲的借口

3.1 復(fù)雜項(xiàng)目的全流程閉環(huán)

主要針對(duì)大型甲方的內(nèi)部安全產(chǎn)品，乙方同學(xué)可以補(bǔ)充，主要區(qū)別在后方，不詳細(xì)贅述

1.需求收集與運(yùn)營流程閉環(huán)思考:

我們以大家熟悉的WAF來進(jìn)行舉例，在此階段我們要考慮，我們研發(fā)的WAF有多少個(gè)業(yè)務(wù)部門要接入，他們有沒有什么特殊的需求和顧慮要訪談收集。運(yùn)營流程上我們的WAF有多少種視角(使用角色)，如一線RD想要 看什么，規(guī)則運(yùn)營者關(guān)注什么，安全部門的Leader想要看什么，公司的CTO想要看什么，他們各自需要什么樣的功能。

2.原型圖制定與敏捷開發(fā)規(guī)劃:

還以我們的WAF為例，WAF最重要的是Firewall意思即防火墻，所以Web Application Firewall這個(gè)名詞的字面意思是首要需要進(jìn)行開發(fā)的，即規(guī)則配置，規(guī)則運(yùn)轉(zhuǎn)，規(guī)則下發(fā)，攔截模塊。結(jié)合上面需求調(diào)研的結(jié)果是首要優(yōu)先出具原型圖和prd文檔。所以排期會(huì)比較明確。

3.架構(gòu)模型的閉環(huán):

基于一個(gè)WAF，我們做完原型圖與規(guī)劃后。需要才真正要站在研發(fā)的架構(gòu)視角看問題。基于運(yùn)營閉環(huán)與原型圖的模板，我們技術(shù)怎么選型，拆成多少個(gè)大模塊。消息隊(duì)列用什么，怎么設(shè)計(jì)架構(gòu)能讓產(chǎn)品經(jīng)理比較輕易的改需求(注意合理的改需求)。

4.多模塊模塊耦合的通信結(jié)構(gòu)制定:

基于一個(gè)WAF可能，web配置平臺(tái)后端邏輯通過HTTP接口溝通。命中日志與waf數(shù)據(jù)倉庫通過kafka溝通。配置中心與waf核心模塊可能通過etcd的kv與zk的樹形結(jié)構(gòu)進(jìn)行同步。那么彼此的接口定義，json字段請(qǐng)務(wù)必先約定好。請(qǐng)用文檔說話，不要嘴上說!!!

5.模塊內(nèi)部的設(shè)計(jì)模式分析與微服務(wù)拆分:

比如一個(gè)數(shù)據(jù)庫讀寫的模塊，以O(shè)O的思想。我們可以拆分為業(yè)務(wù)邏輯層與數(shù)據(jù)庫原子層。那么數(shù)據(jù)庫原子層與業(yè)務(wù)邏輯層是拆分成微服務(wù)還是寫成一個(gè)模塊，需要調(diào)研與分析。不怕大家笑話，我原來寫代碼SQL和業(yè)務(wù)邏輯寫在一起的，結(jié)果改個(gè)需求，呵呵大家都懂得，真的有一種SQLboy的無力感。后來我才知道原來錯(cuò)的不是公司螺絲釘分工模式，錯(cuò)的是我不會(huì)寫代碼。

6.運(yùn)營流程的閉環(huán)并loop 1-5:

平臺(tái)做出來是要有人用的，那么勢必會(huì)被吐槽。那么需要有人接受吐槽的point，并整理需求，反復(fù)loop1-5，當(dāng)架構(gòu)設(shè)計(jì)的越合理，當(dāng)需求到來時(shí)改動(dòng)的面積會(huì)越小。

3.2 自研人員到崗順序：

1.產(chǎn)品與PMO第一到位：

負(fù)責(zé)產(chǎn)品需求的調(diào)研，業(yè)務(wù)線訪談，需求整理收集。一般安全產(chǎn)品的孵化有兩個(gè)動(dòng)機(jī)：

企業(yè)出了一些安全case想解決:

這種相對(duì)簡單，畢竟公司內(nèi)部會(huì)支持。分辨好項(xiàng)目簡單與復(fù)雜程度，上述3.1中的流程進(jìn)行實(shí)施即可。如果項(xiàng)目符合簡單項(xiàng)目的條件，可以適當(dāng)?shù)膲嚎s崗位人員角色，即一人多崗。但必要的流程還是需要。復(fù)雜項(xiàng)目請(qǐng)嚴(yán)格按照3.1的流程進(jìn)行。

安全技術(shù)人員未雨綢繆看到風(fēng)險(xiǎn)覺得企業(yè)需要研發(fā)這個(gè)安全產(chǎn)品:

這種首先要做的是產(chǎn)品經(jīng)理務(wù)必最先到位，去各個(gè)業(yè)務(wù)線進(jìn)行需求調(diào)研。在一個(gè)人的安全部時(shí)經(jīng)常我作為技術(shù)人員覺得很必要的事情，業(yè)務(wù)并不覺得，千方百計(jì)覺得自己造出了一個(gè)超級(jí)棒的”輪子”，結(jié)果業(yè)務(wù)不買賬。自己成就感很受挫，當(dāng)然受挫的不只有成就感，大家懂得。

2.架構(gòu)師或資深研發(fā)工程師的到位:

他們主要的是針對(duì)于產(chǎn)品的需求進(jìn)行技術(shù)選型和性能評(píng)估。

這里會(huì)存在產(chǎn)品與技術(shù)最經(jīng)典的沖突問題，我也經(jīng)歷過，后來考慮清楚后與產(chǎn)品經(jīng)理的合作無比愉快，主要問題如下:

產(chǎn)品主要從業(yè)務(wù)邏輯，流程閉環(huán)，功能原型圖角度去思考問題。

技術(shù)更多是從可拓展性，業(yè)務(wù)穩(wěn)定性，架構(gòu)解耦，功能實(shí)現(xiàn)來思考問題。

這注定是兩種視角如果不讓步和不能切換視角注定是不可調(diào)和矛盾。

解決方法一：

產(chǎn)品經(jīng)理切換視角下沉到技術(shù)視角，從技術(shù)設(shè)計(jì)拓展性而言與技術(shù)溝通，如話術(shù)：目前我們先做HTTP接入，未來可能考慮3種消息隊(duì)列的接入方式，kafka，nsq，csv格式，所以請(qǐng)?jiān)谠O(shè)計(jì)這個(gè)模塊的候做好接入冗余設(shè)計(jì)。并輔以流程圖，原型圖進(jìn)行講解。

解決方法二：

架構(gòu)師或者資深研發(fā)工程師上升到產(chǎn)品經(jīng)理視角。反問產(chǎn)品經(jīng)理，進(jìn)行業(yè)務(wù)合理性質(zhì)疑，如：只做HTTP就夠了么，公司有很多的消息中間件吧，需要兼容么?

3.研發(fā)工程師的到位:

這塊比較簡單，但也復(fù)雜。請(qǐng)用百分之40的時(shí)間寫文檔，對(duì)清楚上下游模塊的格式與約定。百分之20的時(shí)間思考模塊的設(shè)計(jì)模式怎樣進(jìn)行解耦，需求可能有怎樣，百分之30的時(shí)間寫代碼，百分之10的時(shí)間思考邊界處理是否清晰，單元測試是否完整。

在分布式系統(tǒng)中，邊界問題處理不好會(huì)出非常大的問題，這就是為啥研發(fā)要專人專崗最合理的原因，比如分布式事務(wù)，分布式鎖的場景，以及合理的監(jiān)控報(bào)警，上下游的熔斷機(jī)制與過載保護(hù)等等等等，身為一個(gè)一線的研發(fā)工程師，我們最要保證的是自己寫出來的代碼是設(shè)計(jì)模式優(yōu)質(zhì)切可靠的，并且出現(xiàn)問題后風(fēng)險(xiǎn)是可控的。

四、寫在最后

這是我從安全轉(zhuǎn)型研發(fā)后兩年工作經(jīng)驗(yàn)中踩到的一些坑，以及逐漸認(rèn)知到自己的不足的一些過程，文筆倉促，如有不當(dāng)之處請(qǐng)各位見諒。也歡迎感興趣的朋友們相互交流，達(dá)到彼此的共同成長。

因?yàn)楣ぷ鬏^忙，為保證產(chǎn)品落地的信息嚴(yán)禁性，并未在文中寫過多的技術(shù)干貨，歡迎私下交流。