．平台安全可靠的设计与实现思路
我们就从平台自身和软件生产两大方面，分别举例来说说安全可靠方面的一些实现思路。
平台自身—平台无单点
正如之前对无单点的描述，平台需要解决两类无单点：
比如我们使用了，的集群是一主多从的模式，这个存在一定的单点问题（），之间的通信模式有两种（和），在多次测试后，最终选择的是（可靠性存在问题），单点问题则通过多套集群来部分解决；
再比如使用来进行项目管理，但这种商业产品一般不会部署集群，所以平台另一方面要考虑的则是即使宕机，仍旧可以保证平台的可靠运行（所以平台还会提供工作项本地存储的模式）。
平台最终的默认部署架构则如上图，每个节点首先要解决自身的可靠方案，考虑到数据和网络的安全，像堡垒机、介质库代理模式也都在整个平台的默认部署架构中。
平台自身—数据与环境的隔离
再来看数据与环境的隔离：
比如介质库，首先各项目的介质库要隔离，一个项目的开发库、测试库、投产库同样要隔离，测试通过的介质，则通过可控的同步手段发到投产库。
再比如部署引擎，什么引擎可针对什么环境进行部署操作，也是严格控制的，防止环境操作越权。
再有就是部署的操作，什么人审批还是可自动执行，部署完成后由谁确认（亦或是通过自动化测试确认），这些关键事项，需要结合不同团队的实际情况进行不同的个性化配置。
软件生产—需求任务管理的安全可靠
需求任务的管理核心是风险识别，对进度要严格把控，通常包括四个视角：
．当前项目版本中的积压（）情况，一个项目周期中，正常来讲时间过了%，积压项和完成项也应差不多是:的状态
．个人代办的风险，时刻关注团队中每个人的当前积压任务
．当日工作的风险，这在每天的例会上最关注的视角
．特别需求的风险，在敏捷模式下比较常态，将特殊需求调整优先级或直接置顶，并在一定时间窗口由某个人特别关注与跟踪
所以下面的一些看板模式，都是为上述的一些风险识别场景而提供的。
关注项目积压：
关注个人积压：
今日关注与特别关注：
软件生产—开发测试的安全可靠
这个阶段的两个核心工件是代码和介质，是需要重点保障安全可靠的。
代码质量包括开发禁止项，代码静态扫描、提交信息合规等，之所以把开发禁止项与静态扫描分开说，主要是目前技术实现上手段区别（目前我们的开发禁止项还不太能通过自动的静态扫描来发现）。
比如开发禁止项的一些具体细项，我们目前还是通过规范、设计和来做的：
• 禁止将大量业务数据存在会话区
• 禁止明文传输敏感数据
• 禁止使用数据源
• 对表数据+的查询必须分页
• 禁止使用非模式依赖三方
• ……
静态扫描，在平台上则是通过集成三方工具来实现，不过相关的代码扫描工具有很多，在具体抉择时，是从下面几个维度来考虑的。
目前在我们平台上集成的是、、等，通过在流水线中定义，并将执行报告直接展示在安全质量的界面上。
在代码提交时，为保证相关提交有迹可循（解决什么问题），也为后续能够反向统计需求的一些具体开发过程，对代码提交也进行了严格控制，对不符合规范的代码提交，是无法代码入库的（控制）。
在介质方面，要做到安全合规，对介质中的一些介质（尤其三方介质），要快速发现其商业风险，比如：
这里尤其对于一些老系统，里面的无法直观的看出来源、版本等，平台是需要帮助项目快速找到源信息，并建立起相关信息库。
在介质管理方面，像黑鸭、杰蛙这些公司已经在这个领域积累了很好的安全库，所以我们也在考虑与这些产品进行合作对接。
软件生产—发布的安全可靠
在软件发布时，通过技术保障来屏蔽发布失败的风险。考虑到不同的应用服务器或底层环境的差异，每个中间件上的实现手段则会存在一定的区别，这里以上的应用发布为例：
需要考虑如何备份，卸载后安装还是直接更新，是否需要重启，如何探测部署的成功或失败，失败后是否需要回退，以及如何回退，这些都需要在平台提供的部署任务上可配，才能保证发布的安全可靠。
除了上述部署流程执行外，在部署之前还要有很多的探测或预执行能力，摆阔检查网络可达、脚本执行权限、进程的存活、端口的可用、配置的正确与否，这些都是平台需要内置能力。