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

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流程。但这里只显示了以上提到的软件，其实还有很多其他软件，比如一些自动测试工具。上游是项目管理和设计——Jira和Confluence。

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

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

谢谢大家！