转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：
普元DevOps平台覆盖从需求到运维，力求帮助团队提升工作效率、保障系统质量。在安全可靠层面，平台需要考虑自身如何跨环境且流程合规，还需保障所生产的软件的安全可靠。
本文从流程、代码、介质、环境等角度出发，重点聚焦在安全可靠建设过程中的一些思路与技术支撑，最终形成平台级的建设方法与体系。
目录：
1. DevOps平台的安全可靠涉及哪些方面？
2. DevOps平台安全可靠的设计与实现思路
3. 普元DevOps平台的当前能力与后续计划
1. DevOps平台的
安全可靠涉及哪些方面？
众所周知，现在国家对安全可靠、自主可控这些方面的要求很高，也让我们团队重新审视DevOps产品在这方面需要如何改善和演进。
我们从两方面来看平台的安全的可靠：
平台自身，考虑到DevOps平台的一定特殊性（跨环境、跨部门），在自身的合规、数据隔离等方面显得尤为重要
软件生产，平台支撑了软件交付的整个过程，在生产过程的各阶段，需要对最终软件的安全可靠形成合力，尽早发现相关风险
一、平台自身的安全可靠
平台自身来看，包含如上图四个方面：
无单点：这里包含两个意思，平台集成的三方中间件较多，需要保障其为集群模式；再一个即使某些中间件完全故障了，也不能影响整个DevOps平台的运行
数据与环境隔离：不同项目、不同团队的数据要保证隔离，一个项目的多套环境，多套介质同样要保证隔离
UI与API的权限控制：对界面的菜单、按钮进行权限控制，对后台api的访问权限进行权限控制
可审计：对于什么人在什么时候在平台上做了什么，在动作前后资源产生了这样的变更
二、软件生产的安全可靠
软件生产过程我们则是从需求、设计开发、构建测试、发布、运维这几个阶段来梳理安全可靠的一些关键点的。
2. DevOps平台
安全可靠的设计与实现思路
我们就从平台自身和软件生产两大方面，分别举例来说说安全可靠方面的一些实现思路。
平台自身 — 平台无单点
正如之前对无单点的描述，平台需要解决两类无单点：
比如我们使用了jenkins，jenkins的集群是一主多从的模式，这个存在一定的单点问题（master），之间的通信模式有两种（ssh和jnlp），在多次测试后，最终选择的是jnlp（ssh可靠性存在问题），master单点问题则通过多套jenkins集群来部分解决；
再比如使用jira来进行项目管理，但jira这种商业产品一般不会部署集群，所以平台另一方面要考虑的则是即使jira宕机，仍旧可以保证平台的可靠运行（所以平台还会提供工作项本地存储的模式）。
平台最终的默认部署架构则如上图，每个节点首先要解决自身的可靠方案，考虑到数据和网络的安全，像堡垒机、介质库代理模式也都在整个平台的默认部署架构中。
平台自身 — 数据与环境的隔离
再来看数据与环境的隔离：
比如介质库，首先各项目的介质库要隔离，一个项目的开发库、测试库、投产库同样要隔离，测试通过的介质，则通过可控的同步手段发到投产库。
再比如部署引擎，什么引擎可针对什么环境进行部署操作，也是严格控制的，防止环境操作越权。
再有就是部署的操作，什么人审批还是可自动执行，部署完成后由谁确认（亦或是通过自动化测试确认），这些关键事项，需要结合不同团队的实际情况进行不同的个性化配置。
软件生产 — 需求任务管理的安全可靠
需求任务的管理核心是风险识别，对进度要严格把控，通常包括四个视角：
当前项目版本中的积压（backlog）情况，一个项目周期中，正常来讲时间过了50%，积压项和完成项也应差不多是1:1的状态
个人代办的风险，时刻关注团队中每个人的当前积压任务
当日工作的风险，这在每天的例会上最关注的视角
特别需求的风险，在敏捷模式下比较常态，将特殊需求调整优先级或直接置顶，并在一定时间窗口由某个人特别关注与跟踪
所以下面的一些看板模式，都是为上述的一些风险识别场景而提供的。
关注项目积压：
关注个人积压：
今日关注与特别关注：
软件生产 — 开发测试的安全可靠
这个阶段的两个核心工件是代码和介质，是需要重点保障安全可靠的。
代码质量包括开发禁止项，代码静态扫描、提交信息合规等，之所以把开发禁止项与静态扫描分开说，主要是目前技术实现上手段区别（目前我们的开发禁止项还不太能通过自动的静态扫描来发现）。
比如开发禁止项的一些具体细项，我们目前还是通过规范、设计和review来做的：
禁止将大量业务数据存在会话区
禁止明文传输敏感数据
禁止使用XA数据源
对表数据10K+的查询必须分页
禁止使用非maven模式依赖三方jar
……
静态扫描，在平台上则是通过集成三方工具来实现，不过相关的代码扫描工具有很多，在具体抉择时，是从下面几个维度来考虑的。
目前在我们平台上集成的是sonar、fortify、checkmarx等，通过在CI流水线中定义，并将执行报告直接展示在安全质量的界面上。
在代码提交时，为保证相关提交有迹可循（解决什么问题），也为后续能够反向统计需求的一些具体开发过程，对代码提交也进行了严格控制，对不符合规范的代码提交，是无法代码入库的（hook控制）。
在介质方面，要做到安全合规，对介质中的一些介质（尤其三方介质），要快速发现其商业风险，比如license：
这里尤其对于一些老系统，里面的jar无法直观的看出来源、版本等，平台是需要帮助项目快速找到源信息，并建立起相关信息库。
在介质管理方面，像黑鸭、杰蛙这些公司已经在这个领域积累了很好的安全库，所以我们也在考虑与这些产品进行合作对接。
软件生产 — 发布的安全可靠
在软件发布时，通过技术保障来屏蔽发布失败的风险。考虑到不同的应用服务器或底层环境的差异，每个中间件上的实现手段则会存在一定的区别，这里以websphere上的应用发布为例：
需要考虑如何备份，卸载后安装还是直接更新，是否需要重启，如何探测部署的成功或失败，失败后是否需要回退，以及如何回退，这些都需要在平台提供的websphere部署任务上可配，才能保证发布的安全可靠。
除了上述部署流程执行外，在部署之前还要有很多的探测或预执行能力，摆阔检查网络可达、脚本执行权限、进程的存活、端口的可用、配置的正确与否，这些都是平台需要内置能力。
3.普元DevOps平台的
当前能力与后续计划
最后总结下我们目前在平台安全可靠上所集成的工具以及基于这些做了些什么特性。
在每个阶段通过集成三方的开源或商业工具，来提供上层能力，但也避免被三方绑定，所以会对集成模型与接口进行抽象，并随着不断迭代，自己也能提供下层部分产品能力。
普元DevOps平台的后续计划
后续我们还会积极与厂商合作，同时积累自己在安全、合规这些方面的基线库，并将更多的开放生态中的东西集成进来，不断提升此领域能力。
精选提问：
问1：从流程、代码、介质、环境等角度出发，请问安全可靠设计更应该关注在哪个环节，普元是否有DevOps平台的试用版可以申请？
答：我觉得如果从这四个来看，肯定是流程，毕竟流程是贯穿阶段的，其他的几个只是工件，主要作用于其中某个或某几个阶段。但从技术实现来看，则各个工件的管控是相对复杂的。试用版是有的，不过目前不是提供的公有云这种，而是通过申请安装介质来私有化部署试用的（通过客服400-820-5821）
问2：在风险识别场景方面，关注度和积压情况如何度量的？是否根据管理经验来进行人为干预和指标打分来确定风险的？
答：分两类来看，一个是在企业或团队持续运营一段时间后定下来的，不同团队的阈值指标是有区别的，比如千行缺陷率、积压比率这些，只有团队持续一段时间或多个项目后，才大概知道这个团队的一些能力情况；另一个就是像关注度这类，这些还很难通过系统上的数据来度量，只能通过一些完成质量这种来反向评估，目前我们没什么好办法。
问3：API风险管理如何？
答：这个目前倒没在我们devops平台上来做，做在了我们的API网关平台，上面的安全风险涉及这几个方面：
1. API订阅授权，通过产生的订阅凭证来访问API
2. API熔断和限流
3. 路由黑白名单，比如针对来源IP，移动设备的控制
4. API用量分析，发现长期不使用的、高频度使用的、响应时间慢于配置阈值的、错误率高于配置值的等
5. 还有一些比较细的，比如https、管道数据加密压缩、特殊请求的认证这些
问4：刚才围绕安全和可靠来讲述，请问安全和可靠指标都有哪些，比如安全指标，一般包括应用安全、服务安全、数据安全、网络安全，DevOps平台安全是否包含了以上全部？可靠性又怎么体现六性的？
答：你说的这个是一个比较完整的系统的分类维度，国标的产品六性这个很大，这次分享远远没覆盖这些，而是从DevOps平台本身以及软件生产的阶段，通过举例来组织的。
如果细化来穷举每个特性的具体指标，可能一时半会我还真没法说出来，而是从我们现有的几大项度量指标中拿出的与安可考到有关的来讲怎么做的，具体我们现在的指标项来源于我们内部总结的这些，如下图（未截取全），后面我们看看产品发布时，是否能将你说的这些按那几个维度罗列出来：
推荐阅读
关于作者：顾伟，现任普元信息主任架构师，长期致力于IT技术研究、产品设计与开发、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术；对DevOps、自动化运维、微服务架构有着浓厚的兴趣。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！
在看点这里
