GOPS演讲 | 如何实现大规模、敏捷、安全、开放式的软件研发与运营

作者:龙智      发布时间:2022-10-14

2022GOPS全球运维大会·深圳站,龙智大规模安全研发技术专家李培带来了主题为“大规模、敏捷、安全、开放式的软件研发与运营之路”的演讲,从版本控制、CI/CD、静态代码扫描、开源代码扫描、ITSM等多个方面分享了他在为大型企业落地DevSecOps解决方案中的实践经验、心得以及建议,同时帮助您更深入地了解龙智DevSecOps解决方案。

李培
龙智大规模安全研发技术专家

以下是演讲全文:
大家好,我叫李培,在龙智负责大客户DevOps解决方案的咨询和实施。此次演讲,我主要分享给大客户定制解决方案时的思考。大致分为几块,首先是流程的核心——

版本控制

“所有的研发行为都是围绕着数字资产而开展的,管理数字资产的VCS(版本控制系统),处于所有研发流程的核心地位。”

研发团队的流程核心是VCS,它已经非常成熟,代码公司只要超过2个员工,就会用到VCS。因此,我们往往不会特别拿到台面上说,因为它十分常见、基础。但其实有时候,不被注意的东西,反而起到支撑的作用。一个公司中成百上千的员工,每天在电脑前忙碌,产出是什么?软件行业、芯片行业和游戏行业都一样,包括设计资料、代码、配置项,还有生成物。这些东西很重要,我们帮助客户做实施时,心理压力很大,有个客户和我开玩笑说,这些东西一定要处理好,别出问题,如果整出问题,我们公司可能会出问题。所有的研发行为都是围绕着数字资产而开展的,管理数字资产的VCS,处于所有研发流程的核心地位。

一个好的VCS,可以在单一平台上安全高速的管理一切数据资产,无论资产的类型、大小和体量。当团队较小,或管理的东西较单一,只有少量数据、类型只是代码或文档时,就不太会关注VCS,因为可以很快备份,性能也没有遇到太多的瓶颈。但考虑大规模解决方案时,这些都是问题。一是数量的变化会引起质变,比如Git、安卓的库,一组库只有40多个G。但当处理数百T级别,甚至PB级别时,就会比较头大。

并且,如果您的团队稍具规模,分布在不同的城市、国家,例如我们的部分客户,拥有数以千计的流水线,将对VCS造成巨大压力。对于比较依赖于开源的公司项目,龙智作为企业级解决方案提供商,为您提供可能性。前端仍然可以使用Git,但在公司级别,我们会对安全策略、分布式部署策略以及灾备策略做一个统一的考量。

作为企业内数据资产的唯一可信来源、容易实现全局可见性、数字资产始终处于完善的权限控制和审计机制保护之下,满足这些需求并不容易,我们给客户推荐的解决方案是使用Perforce Helix Core,因为它具备刚才所说的优点。

易用性方面,除了开发人员熟悉的应用,还有艺术家、游戏行业或芯片设计行业可能会用到的应用,例如:Helix DAM,并可以和其他的主流且成熟的第三方应用进行集成。

接下来说一下流程,大家现在已经不会去质疑CI/CD的必要性了。

CI/CD

“如何解决Jenkins的这些问题?一个统一的平台,在此平台上可以很容易的扩展,但这些扩展要在统一的管理之下。”

软件、硬件团队交付的速度,芯片推向市场的速度,都会直接影响到收益,以及软件交付是否高效,或服务交付得是否有效,决定着这个企业的发展前景。

CI/CD已成为一种趋势,刚才几位嘉宾提到,小规模的改动,快速的迭代,有利于更小、更轻微的发布问题。但是,什么是小规模的改动?这实际是对设计的考验,而不是对CI/CD。如果架构设计得不好,那每次提交代码扫描也无法发现问题。在工程实践中,越来越多的客户把CI/CD作为必选项,在为工具选型时,客户会询问能否支持CI/CD,如果不能支持,这个工具就出局了。

说到CI/CD,必然会想到Jenkins。Jenkins本身很简单,它是社区里最常见的一种工具,作用是把流程串起来。在团队较小的时候使用Jenkins,利用它提供的许多的插件,不会产生大问题。但当团队人数上升后,例如每天要跑高负荷的流水线,Jenkins能否支撑?另外,如果始终维持一个流水线,或者是一个巨型Jenkins,往往会顾此失彼。一旦单点故障出了问题,整个团队的工作都会被迫中断。

另一种扩展方式是,拥有很多小型Jenkins,每个团队使用自己的Jenkins,这将导致企业产生审计和安全问题。使用的插件是否合规?代码的安全性能否得到保障?API的接口是否控制合理?这些都是问题。

这些是常见的使用Jenkins的缺点,开源软件没有技术支撑,Jenkins分散、隔离的部署方式无法进行共享,一个公司中拥有很多的组织,每一个组织都使用Jenkins,经验无法共享。比如A团队中,员工个人能力很强,把自动化实现得很好,写了很多很好的配置、设置,又或者是流水线。B团队稍弱一些,则没有办法轻易从A团队的知识中获益。另外是安全性、稳定性等问题。

如何解决这些问题?您需要一个统一的平台,在此平台上可以很容易的扩展,但这些扩展要在统一的管理之下。除CI外,还有效能分析。当企业使用了CI/CD或是DevOps的研发流程,就意味着使用了很多工具,如何衡量这些工具也是一个问题。在统一的平台上,CI数据较容易收集,除了基础的CI功能外,也需要提供一些分析依据。

当企业使用普通、小型的CI/CD方案遇到困难时,我们推荐CloudBees。CloudBees借鉴了K8S的思想,K8S是由控制平面管理各种各样的Pod,CloudBees是基于普通工具,它是商业版的Jenkins,能够集中管理实例。它是整个集群的控制平面,有了CloudBees,就可以实现所需,比如流水线的模板,插件的版本,都可以配置为代码,然后作为模板下发到实例里,实现完整性。另外,它有一个统一的入口,在权限管理、资源共享上,有可使用的共享工具,让共享资源更便捷。

当有了流程后,自动化程度更高产生的效果更好。比如互联网行业的自动化水平会稍高一些,因为没有硬件实体。但在传统行业,比如医疗行业或是汽车行业,CD很困难。不过没有关系,可以借鉴思路。一些常见的比如单元测试、自动化测试,可以放到流程化里,无论是嵌入式、纯软件,还是提供API的,自动化测试都可以嵌入流水线中,效率才能得到提升。除了测试,还有安全性也可以放入流水线,这也是常见做法。

静态代码扫描

“所有使用SAST的公司都值得尊重,SAST有助于更早发现常规测试中难以发现的问题,持续提高代码质量。”

使用静态扫描工具存在一个问题。传统做法中,团队负责人发话,要解决代码太烂的问题,扫描出的问题数量是天文数字,使开发团队对SAST很抵触,他需要抛开别的工作,只专注解决问题。

一个现实的选择是边写边清理。以前有问题,现在注意,以后做好就行。这样就可以先聚焦在能够处理的范围内,这让阻力小了很多。另外,质量门限进行调整时,一开始宽松,后面较严苛,阻力也会小很多。一旦持续做此项工作,只要坚持,代码库会逐渐变得干净、整洁。

比较典型的部署方式是,首先,对代码质量负责的人,在每次、每天或者是更长的时间周期中,对代码做公司统一标准门限的检查。每次提交时也可以做检查,相当于一次快速的回归,通常可以放到流程里。当报了问题,肯定需要修改,要实时得到反馈,也可以在提交前自己做检查,这就叫即时检查。这就是SonarQube的典型场景。

为什么推荐SonarQube作为静态扫描工具?因为它的部署可伸缩,为大规模团队提供负载均衡的方案。如果开发的是互联网应用,那么上述的场景均有覆盖。SonarQube天然支持29种语言,还支持服务器端分析,包括自动化构建流水线的分析,以及客户端的分析。

此流程中,用户可以在自己熟悉的环境上工作,即时分析,之后可以提交VCS。自动化构建方面,当Jenkins无法搞定这些时,团队规模较大时,可以考虑CloudBees,分析结果会反馈到SonarQube

另外一个实用功能是,提交后被发现有问题,此问题是SonarQube发现的,它反应给版本控制系统的用户,把这个问题下推到客户的环境上,通过插件发送消息。

SonarQube自身有社区版,提供很多插件,与市面上流行的开发工具集成。另外,它的使用简单,有良好的群众基础,很多人免费使用了多年。当他们购买了商业版,就不需要寻求帮忙,因为他们之前在使用社区版。

开源代码扫描

“但是,作为一个认真的大企业,开源代码安全必须被考虑到。”

SonarQube主要扫描自身代码,但还有一部分:那就是开源代码。以前,大部分很多代码由自己编写,用什么库都在掌控之中。现在不是,特别是JAVA项目,很多依赖,当需要一个功能时,不是自己去写,而是去搜索。但不可否认的是,将开源组件引进项目中是一个迫不得已的选择,因为时间紧、任务重,只有使用开源组件才能按时交付,但又没有足够的时间去确保它的安全。这时,小企业因为用户不多,亏得起,坏了就修。但是作为一个认真的大企业,这些问题则不允许出现,开源代码安全必须被考虑到。

首先,选用一些能够识别不同语言、不同框架的工具。现在各种各样的包管理系统多达数十种。作为互联网行业从业者,使用的开发技能非常多。

其次,和SonarQube问题类似,问题一定要分级,不能一下爆太多。被问题淹没时,只能假装没有问题,所以,只推最关键、最急迫的问题很重要。

同时,需要提供修复建议,然后是软件物料清单,还有开源合规性。现在有针对开源软件诉讼的律师,可以打官司,看开源软件使用是否合规。当公司规模较小时,使用开源组件一般不被追究。但万一某个项目成功了,带来很多收益,风险就会陡增,因此,开源组件的合规性必须要考虑。

减少技术债务,程序员需要处理的事务很多,以前的问题,比如公开发布了漏洞,或者是某些东西已经过时,要及时提醒和升级。获得的合并建议是否真实有效且合理?例如建议升级,升级完不一定解决问题,例如引入了新的问题,这也行不通的。

关于开源代码安全方面,我们推荐Mend(也就是WhiteSource),因为它实现了代码库完整的开源安全检查,集中部署,集中策略设置。

现在,左移概念很火,在提交时引入了一个新问题,能够立刻得到反馈,这样很容易找到上下文,修复起来特别快,同时提供修复建议,还有重要的一点是,Mend支持离线部署。

ITSM

“积累实践经验、复盘文章和改进研发都是必要的,因为只有有效沉淀过往的经验,才能实现持续改进。”

前面说的都是研发阶段的运营与支持,但IT运维也有敏捷的需求。我们接触过一些大厂IT的运维同事,一到公司就十分忙碌。 每一个运维都有自己的文档,或总结的经验,因为这是一个依赖于经验的岗位。软件开发已经进入DevOps时代,部署又讲云原生或者是K8S容器化部署,软件的架构越来越复杂,如果运营仍然停留在过去,就会陷入疲于奔命的状态。这时,你需要为自己争取更好的工作条件。

运营遇到的挑战是架构越来越复杂,比如去捞一个日志,传统的定位方法是有问题就拿日志来查,相对比较容易。但现在,大多部署在云上,在哪台机器上跑的业务都无从知晓,更何况从海量的数据中捞日志?时间很紧迫,工具却零零散散,支持的挑战很大,业务需求多变,一直会有各种各样的单子,一天处理几百次服务请求。

对于现在的运营与支持来说,运营与研发应该是紧密结合的。这次会议中,有人提到一个职位叫SRE,这个职位地位较高,他需要做的事情是,研发永远把运营需求的优先级排在功能需求之后。所以,必须有一个人参与这个复杂的架构,在上线前,对部署的形态等有充分了解。因此组织需要支持这个职位有一定的话语权。这样,系统上线后要监测,也能有监测的数据,出了问题能尽快恢复,把功能关掉、降级运行,或者局部把问题封锁在某一范围内,这些都是解决方案,但必须在研发阶段考虑到,否则等到运维时出了问题,就无法做到这些,甚至连监控都不行。

运营与支持的自动化水平,预定义的预警处理流程,自动化的工单优先级分级,比如问题出现,首先有告警,同时,对这些告警有预处理机制。当出现问题导致持续宕机,无法恢复时,需要根据运维人员的值班表逐级寻找解决人员,这些都是自动化的流程。

实践经验的积累、有价值的复盘文章和研发的改进都是合理的,只有把以往的经验有效沉淀,才能实现持续改进。

多渠道自服务的文化分为两点,一是用户,比如即时聊天工具,能上报问题;二是问题左移,这个组织是否是学习型的组织?是否有良好的知识共享文化?这里有零级支持的概念,一个小团队遇到问题,能够在身边快速找到相应资源解决问题,甚至没有正式上升到运维团队,这是很好的思路。

上述这些都需要开放的协作平台,让工作在团队之内可见。如果没有开放的平台,工具零散,实现起来很困难。

ITSM方面,我们推荐Jira Service Management解决方案,它包括很多产品,比如JSM是一个工单系统,可以实现工单处理自动化、多渠道的提交等。除此以外,还有预警处理,可以处理事件,分类预警,并且实现一定程度的自动化和调度等等。还有与Confluence结合使用的知识库。运营或者是支持中遇到的问题,可以和上游设计问答,或者是与项目管理进行关联,可以给上游的Jira开Ticket,列入开发人员的工作计划。

这张图总结了以上的内容,运维就是ITSM,开发就是DevSecOps流程。但这里只显示了以上提到的软件,其实还有很多其他软件,比如一些自动测试工具。上游是项目管理和设计——JiraConfluence

Atlassian ITSM解决方案的好处是可以轻松应对大规模团队,无论公司是10个人还是1万人,都可以使用,因为它是可拓展的。另外,Jira本身拥有强大的生态系统,不会因为买了Jira而绑定Atlassian。如果它不能满足需求,可以寻找插件的帮助,如果插件还是不能满足需求,龙智可以帮你定制开发。

以上就是我今天演讲的主要内容,分享我们做实践的具体思路,欢迎大家咨询龙智,一起交流DevSecOps心得。

谢谢大家!