2．DevOps平臺安全可靠的設計與實現思路

我們就從平臺自身和軟件生產兩大方面，分別舉例來說說安全可靠方面的一些實現思路。

平臺自身—平臺無單點

正如之前對無單點的描述，平臺需要解決兩類無單點：

比如我們使用了jenkins，jenkins的集群是一主多從的模式，這個存在一定的單點問題（master），之間的通信模式有兩種（ssh和jnlp），在多次測試后，最終選擇的是jnlp（ssh可靠性存在問題），master單點問題則通過多套jenkins集群來部分解決；

再比如使用jira來進行項目管理，但jira這種商業產品一般不會部署集群，所以平臺另一方面要考慮的則是即使jira宕機，仍舊可以保證平臺的可靠運行（所以平臺還會提供工作項本地存儲的模式）。

平臺最終的默認部署架構則如上圖，每個節點首先要解決自身的可靠方案，考慮到數據和網絡的安全，像堡壘機、介質庫代理模式也都在整個平臺的默認部署架構中。

平臺自身—數據與環境的隔離

再來看數據與環境的隔離：

比如介質庫，首先各項目的介質庫要隔離，一個項目的開發庫、測試庫、投產庫同樣要隔離，測試通過的介質，則通過可控的同步手段發到投產庫。

再比如部署引擎，什么引擎可針對什么環境進行部署操作，也是嚴格控制的，防止環境操作越權。

再有就是部署的操作，什么人審批還是可自動執行，部署完成后由誰確認（亦或是通過自動化測試確認），這些關鍵事項，需要結合不同團隊的實際情況進行不同的個性化配置。

軟件生產—需求任務管理的安全可靠

需求任務的管理核心是風險識別，對進度要嚴格把控，通常包括四個視角：

1．當前項目版本中的積壓（backlog）情況，一個項目周期中，正常來講時間過了50%，積壓項和完成項也應差不多是1:1的狀態

2．個人代辦的風險，時刻關注團隊中每個人的當前積壓任務

3．當日工作的風險，這在每天的例會上最關注的視角

4．特別需求的風險，在敏捷模式下比較常態，將特殊需求調整優先級或直接置頂，并在一定時間窗口由某個人特別關注與跟蹤

所以下面的一些看板模式，都是為上述的一些風險識別場景而提供的。

關注項目積壓：

關注個人積壓：

今日關注與特別關注：

軟件生產—開發測試的安全可靠

這個階段的兩個核心工件是代碼和介質，是需要重點保障安全可靠的。

代碼質量包括開發禁止項，代碼靜態掃描、提交信息合規等，之所以把開發禁止項與靜態掃描分開說，主要是目前技術實現上手段區別（目前我們的開發禁止項還不太能通過自動的靜態掃描來發現）。

比如開發禁止項的一些具體細項，我們目前還是通過規范、設計和review來做的：

? 禁止將大量業務數據存在會話區

? 禁止明文傳輸敏感數據

? 禁止使用XA數據源

? 對表數據10K+的查詢必須分頁

? 禁止使用非maven模式依賴三方jar

? ……

靜態掃描，在平臺上則是通過集成三方工具來實現，不過相關的代碼掃描工具有很多，在具體抉擇時，是從下面幾個維度來考慮的。

目前在我們平臺上集成的是sonar、fortify、checkmarx等，通過在CI流水線中定義，并將執行報告直接展示在安全質量的界面上。

在代碼提交時，為保證相關提交有跡可循（解決什么問題），也為后續能夠反向統計需求的一些具體開發過程，對代碼提交也進行了嚴格控制，對不符合規范的代碼提交，是無法代碼入庫的（hook控制）。

在介質方面，要做到安全合規，對介質中的一些介質（尤其三方介質），要快速發現其商業風險，比如license：

這里尤其對于一些老系統，里面的jar無法直觀的看出來源、版本等，平臺是需要幫助項目快速找到源信息，并建立起相關信息庫。

在介質管理方面，像黑鴨、杰蛙這些公司已經在這個領域積累了很好的安全庫，所以我們也在考慮與這些產品進行合作對接。

軟件生產—發布的安全可靠

在軟件發布時，通過技術保障來屏蔽發布失敗的風險。考慮到不同的應用服務器或底層環境的差異，每個中間件上的實現手段則會存在一定的區別，這里以websphere上的應用發布為例：

需要考慮如何備份，卸載后安裝還是直接更新，是否需要重啟，如何探測部署的成功或失敗，失敗后是否需要回退，以及如何回退，這些都需要在平臺提供的websphere部署任務上可配，才能保證發布的安全可靠。

除了上述部署流程執行外，在部署之前還要有很多的探測或預執行能力，擺闊檢查網絡可達、腳本執行權限、進程的存活、端口的可用、配置的正確與否，這些都是平臺需要內置能力。