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部署任务上可配，才能保证发布的安全可靠。

除了上述部署流程执行外，在部署之前还要有很多的探测或预执行能力，摆阔检查网络可达、脚本执行权限、进程的存活、端口的可用、配置的正确与否，这些都是平台需要内置能力。