[[274885]]

一、讀前必看

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的時間思考邊界處理是否清晰，單元測試是否完整。

在分布式系統中，邊界問題處理不好會出非常大的問題，這就是為啥研發要專人專崗最合理的原因，比如分布式事務，分布式鎖的場景，以及合理的監控報警，上下游的熔斷機制與過載保護等等等等，身為一個一線的研發工程師，我們最要保證的是自己寫出來的代碼是設計模式優質切可靠的，并且出現問題后風險是可控的。

四、寫在最后

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

因為工作較忙，為保證產品落地的信息嚴禁性，并未在文中寫過多的技術干貨，歡迎私下交流。