从各大企业的实践来看，标准化和工具赋能是科技公司成功的关键所在。DevOps 标准及基于标准的 DevOps 持续交付流水线平台，使得企业的软件研发效能飞速提升、更快更灵活应对市场变化，助力IT成为企业的核心竞争力之一。
由云计算开源产业联盟指导、高效运维社区和 DevOps 时代社区联合举办的 GNSEC 2020 全球新一代软件工程线 日举行，本次峰会线人。峰会专注于全方位的软件工程和技术，致力于定义新一代的软件工程，旨在聚集软件工程行业的专家、学者、从业者，讲述重要的最新研究成果，并分享最前端的实践经验，同时促进产、学、研领域的专家互相交流与合作。
大会隆重发布了 DevOps 标准持续交付部分第七批评估结果。本次发布的参评企业除了安信证券之外，还包括中国农业银行（5个项目）、交行卡中心、浦发总行、招商银行（3个项目）、中国人民保险和泰康保险等。
安信证券（安信证券股份有限公司）本次参评项目为手机证券交易服务中台。该项目顺利通过由中国信息通信研究院（以下简称信通院）开展的《研发运营一体化（ DevOps ）能力成熟度模型》持续交付部分3级评估。DevOps 标准共分5级，持续交付部分如果能达到 3 级已经是国内领先水准，这代表着安信证券在参评项目的持续交付能力达到国内领先水平。
中国信息通信研究院云计算与大数据研究所所长何宝宏博士公布安信证券评估结果：
此次，我们采访了安信证券信息技术总监、信息技术中心总经理许彦冰女士，一起深聊安信证券手机证券交易服务中台项目参与评估的细节和幕后团队的故事，分享安信证券 DevOps 实践的经验。
Q：目前安信证券手机证券交易服务中台项目通过了 DevOps 标准持续交付 3 级评估，对于企业而言具有什么样的意义？
许：安信启动 DevOps 项目是在 2019 年6、7月，选取手机证券交易服务中台项目作为安信证券第一个DevOps 标准持续交付 3 级评估项目，主要考虑该项目是自主研发，架构相对复杂，其下有多套子系统，是公司交易类重要信息系统并且需要频繁迭代，具有一定的代表性。
我们实施 DevOps 项目，不仅仅是为了评估通过一个项目，而是为了建立整个组织级的 DevOps 实践能力，这项工作是建立组织级研发体系的重要举措。在评估之前，我们的研发工具链已经起步建设，比如所有的项目使用 JIRA 来管理需求和变更，使用 Confluence 进行项目评审、架构评审和知识分享等，部分团队用 Jenkins 进行持续集成等，但工具未能实现有效连通，各研发团队的使用也各不相同。
通过此次评估，我们把组织级的研发流程、CICD 过程、度量指标等进行了统一的规范制定和工具建设，为组织内其他系统的推广应用奠定了基础。
此外，安信今年也在同步开展 CMMI 研发管理体系建设，我们希望对照 CMMI3 的要求，把我们所有研发团队的人员角色、开发模式、迭代周期等进一步规范化，本次DevOps 项目构建了完整的、端到端的研发流水线，对于落实 CMMI 是至关重要的，高效率的研发工具是能否顺利推行 CMMI 的关键因素。
许：证券行业这几年纷纷加大了 IT 建设投入，安信也不例外，我们原来是以外购系统为主的，随着金融科技的深度应用，目前我们团队的建设模式逐步转变为以自主研发、合作研发为主，软件开发的团队规模逐渐壮大。之前我们更多的是 ISO20000 、ITIL、项目管理。因为不做开发，很多系统都是别人做好的，只是把它根据业务需求集成进来，测试验收，做好项目管理就可以了。但是现在我们自己是要做软件产品的，那就不可能不需要建立研发管理体系，这就好比你建设生产车间除了需要工人，还一定需要引进生产线和质检，是一样的道理。
总的来讲，除了少数头部券商之外，大部分证券公司基本上都是近五六年才形成一定的研发规模，这与银行有很大的不同，大部分银行本身就是研发型的科技团队，早在20、30 年前，IT 研发的规模就已经非常庞大了，很多系统都是自己来做，但券商不同，比如我们公司，之前也有个别系统是自主研发的，但并没有连成片，但现在自主研发和合作研发的系统已经超过了 50%，研发团队也达到 500+，各个二级研发团队都有自研的项目，量变引起质变，相应的研发领域的管理问题就会格外凸显，比如大家各自的工具参差不齐，开发模式各不相同，管理没有抓手，不能透明化且无法度量，事前质控手段缺失等，但证券行业又是对可用性要求非常高的行业，软件质量不达标，测试无法顺利通过，项目延期，又会直接影响到业务开展，因此，我们认为建立科学的研发管理体系和高效的软件工程实践是一个无法回避的问题，必须要解决。
近几年，团队通过不断的持续学习和思想碰撞，逐步对敏捷、CMMI 、DevOps、CICD 等的概念、关系、作用等有了一致的认识，经过与外部专家多次沟通，公司内部团队多次讨论，形成研发管理体系建设思路。DevOps 标准评估作为研发管理转型迈出的第一步，建立从需求到开发、测试、发布研发全生命周期工具流水线和管理标准，为后续 CMMI 标准、敏捷实践的落地奠定基础。
许：我们团队在工具链选型方面做了大量的调研、讨论和 POC 预研，最终选择使用Coflunece、JIRA、Jenkins、GitLab 等开源工具，通过自有人力进行工具集成的建设方式。虽然可能在短期来看，这种方式比使用一套商业开箱即用的产品要费时费力不少，但我们综合下来还是下了这个决心。主要有几点考虑：
一是各个开源工具专攻一领域，都经历了长时间的发展，方案成熟，功能全面且可靠，在软件行业使用广泛，有良好的生态，用的人、懂的人多；
二是我们对这套工具链的定位是将其作为基础设施来建设的，是技术中台的重要组成部分，是研发“工厂”的“生产线”，我们需要具备对其的技术掌控能力，不能是一个黑盒子，不能受制于一家厂商；
三是我们研发团队目前处于快速发展期，研发管理也在快速迭代中，工具链需要能够及时进行调整，具备较强的灵活性，商用软件如果不接收个性化定制或者响应不及时，那反过来会对我们的管理改进形成掣肘；
四是采用开源工具集成的方式相当于把工具链解构了，可以根据各个工具的发展和自身管理需要，轻松的对其中的单个工具进行替换、增加，这有利于持续保持工具链的先进性。
现在来看，我们当初这样的选择还是非常正确的，虽然整个过程也挺痛苦的，我们请了老师进来教我们，但相当于没有了乙方可以依靠，只能靠自己学懂弄通，把工具玩转起来，但是，在这个被虐过程中，队伍也就自然而然锻炼出来了。另外研发类基础平台对灵活度真的是有很高要求的，如果工具的调整跟不上节奏就会很受限制，目前这块领域的厂商主要是一些小型创业公司或者一些大厂的技术输出，存在厂商调整产品方向甚至放弃不做的可能性，如果真的发生这样的情况，那作为用户就太被动了。
许：当前通过基于 DevOps 搭建 CICD 自动化流水线与度量运营平台，安信初步实现了研发过程的全流程管理，并且通过了一个项目的 3 级 DevOps 能力评估，但这只是一个开始，DevOps 这块主要有三方面的工作需要继续开展：
一是今年我们还会有两个项目要通过 DevOps 标准评估，同时在一两年之内实现所有自研系统、合作研发系统的全覆盖；
二是同步对研发流程和 DevOps 平台进行持续优化，完善基于各 CICD 工具链的 Portal 平台，对持续交付的界面和交互接口进行一体化封装，提供体验更好的持续集成持续交付的服务；
三是持续优化度量平台，丰富度量的数据和指标，实现指标和数据的自动化分析，实时生成优化建议以及任务推送，实现从主动发现到自动分析到主动改进的闭环，形成组织内持续优化和改进的氛围。
Q：您认为 DevOps 标准与 CMMI 标准（或其他标准）有什么不一样？
许：我们认为两者是相互补充的关系，不是互相代替的关系，两个标准需要结合共同使用，CMMI、敏捷、DevOps 加在一起，才是一个现代化的研发管理体系，共同促进软件过程改进。CMMI 好比考试大纲，里面有很多定义流程组织的文档，DevOps 通过软件产品交付过程的IT工具链，打通了持续交付的流水线，具体落地。目前我们把 DevOps 平台搭建完成之后，再去贯标 CMMI 的时候就会发现，CMMI 规定的一些内容的管理制度要求，实际上可以固化到 DevOps 平台上来，切实落地，在 CMMI 落地时，工具赋能研发过程的作用十分关键。
DevOps 标准很务实，实操性很强，标准会指出具体的技术细节和管理细节，比如分支策略要求、配置，应具备什么程度的能力，深入到操作细节，对于研发人员来讲，落地 DevOps，帮助他们打造趁手的工具，而且这些工具都是他们非常认同和熟悉的，所以都挺乐于接受的。最后两天现场评估会议，会议安排的非常扎实，评估老师非常专业和细致，重点看实际工作的演示和工具上的历史数据，而不是仅仅只是做访谈和看文档，这也是这个标准重视实操、务实的体现吧。
许：首先的困难在决心上。团队启动项目之前小伙伴们会有一些顾虑和畏难思想，这时候作为 Leader 一定要坚定决心。
我们在开始做之前，先初步做了差距分析，感觉差的也不是特别多，但实际上在建的过程中，因为要搭建组织级体系，实际上相当于从零开始，重新搭建工具、定义流程，再把具体项目迁移到上面来，这其实不是很容易的事情。这就好比之前大家都用自己小灶做饭，现在小灶不能用了，需要建一个大厨房，统一供应。那这个大厨房是需要全新设计、全新搭建的，要考虑的事情要复杂好多倍。
在推动项目的流程中，包括研发、测试、安全、运维等五六个团队的人员在共同推进。项目前期，团队磨合是相对困难的地方，毕竟是在一个新的生态上运转，新的环境需要新的配置，之后要推广到所有研发类项目都能用上，工具需要具备足够高的灵活性，以适应不同类型的项目，这其中有大量复杂性的工作。同时要推翻之前的工作习惯，“移民”到新的平台遵守一套新的“公约”做开发，过程很痛苦，但是要成为一个有追求、有品质的研发型的团队，这条路必须要走，没有退路。遇到什么问题就解决什么问题，不懂就学、不熟练就慢慢来，错了就改，资源不够就加资源，反正就一句话：只能往前走。难事也就一点一点达成了，团队也一点一点成长了，现在团队默契很多，事情也越做越快了、越顺了。
总之，领导者的决心与支持非常重要，遇到困难没有退路可言，团队自然也有了这样的决心。
许：我们想建立一套符合我司实际需要的研发管理体系，最先想的是做敏捷转型，但是动手做的时候，发现敏捷没有工具是不行的，为了确保前后端能够打通，首先要把工具链建立起来。而 CMMI 是个方法论，想要它落地还是靠工具，所以我们先上了DevOps 项目，今年我们的计划启动 CMMI 加敏捷，结合起来一起实践。
前面讲过，我们核心目的是搭建一个公司级的工具平台，对照下来 DevOps 持续交付标准 3 级的各个能力项还是比较符合我们的实际需求的，所以选择先做这个。同时，DevOps 标准是实践型的标准，在项目实践过程中，不会闭门造车，我们可以参考业界的最佳实践，这是一个客观的度量尺，能够帮助我们自我检查，也让大家能够与行业对标。另外，通过评估，也能说明企业具备了这样的能力，有利于提高业界影响力，甚至有利于吸引优秀技术人员加入团队。
全球首个 DevOps 标准，即《研发运营一体化（DevOps）能力成熟度模型》，由中国信息通信研究院牵头，联合云计算开源产业联盟、高效运维社区、 DevOps 时代社区、 Google、BATJ、清华大学、南京大学、通信及金融等行业顶尖企事业单位专家共同制定。
目前，由中国信息通信研究院主导的DevOps标准已在联合国直属标准化组织 ITU-T、中国通信标准化协会（CCSA）正式立项。DevOps 标准评估体系主要包括敏捷开发管理、持续交付、技术运营、应用设计、安全及风险管理、系统和工具等部分的评估。
