中兴大规模系统产品 DevOps 探索之路

彭小阳

作者：张佑文

我今天介绍的，可能稍微有一点差异，是CT领域的实践。

一、系统产品的研发

CT领域有哪些特点？决定了我们在DevOps上有一些比较大的差异。

1、第一部分，给大家介绍系统产品的特点。

第一特点，产品的要求非常高。
这一点，可能做IT的很不服气，觉得IT要求更高，这个确实是，但是有差异的。比如性能和容量要求很高，有的系统产品，像核心网的单网要支持的用户数量都在百万、千万甚至到亿级的用户，但IT的兄弟很不服气，觉得他们的支持比这个更多。
差异在哪？IT的解决方案资源是分布式的，是一种弹性的。双十一来了，可以大量弹性部署很多应对，但CT产品可能是单体架构，或者是有备份容灾，这套设备上去之后，你需要应对这么大规模的用户量，或者说在新年等重大节日进行高峰的负荷冲击，这个过程中甚至不太有机会重新部署硬件，因为部署周期也相当长，这对产品的要求比较高。
第二点是质量可靠性要求高，平时可能上网没连上，再刷新一下就可以了，但对于通信设备而言，电话一打通，直接面临的可能就是投诉，所以这个要求非常高。
第三点是产品维护周期长，意味着十年的设备还要考虑版本的兼容性，对整个研发的要求和考验是非常大的，在开发的过程中需要考虑到这个波及的影响，甚至在现场运营过程中，也需要考虑到兼容。
第二特点，产品差异大。像IT很多都比较类似，甚至行业之间也可以很好的进行沟通和对接，但我们的产品差异很大。
第一点，云管端。从云到管道到终端，相互间的差异非常大。
第二点，很多都是嵌入式软件，是绑定在一起的，这些设备之间相互的共享很难。
第三点，制式场景。无线里有3G、4G、5G，3G里还有不同制式的差异，对研发造成很大的挑战，甚至一个很小的设备，里面要内置大量不同的场景，这是产品间的差异。
第三特点，协同难度大。
第一点，因为单套设备非常复杂，所以团队规模量也很大，IT很多时候讲究小团队就可以完成，7-9个人就可以做成一款IT产品，但像我们的通信产品，有的团队要达到上千人，这些团队怎么快速高效进行产品交付？这个是面临的考验。
第二点，跨地域协同。中兴这边的系统产品有地域差异，比如西安、南京、上海、深圳等等，怎样快速进行交付协同？
第三点，项目群并行开发。项目群如何协同？这都是对我们DevOps实践产生制约的。
第四特点，实现复杂。
第一点，千万级代码规模。有的编译之前要几天，后来到小时，现在到多少分钟，有了5G可以缩短至十几分钟，代码的规模非常庞大。
第二点，大量协议信令支持。
第三点，不同设备终端兼容。
第四点，版本兼容。

2、系统产品研发框架

为了支撑高复杂性的研发，对研发活动和时间提出了比较高的要求。像一个人能保持密切联系的数有一个上限，150人以内的团队，严格来说不需要进行很复杂的管理上的支撑，就可以开展团队上的活动。但如果超过这个数目，就会超过人大脑的处理极限，需要很多流程和工作的支撑，使这个团队进行协同。
在大规模系统产品里，在组织层面要提供支撑。像这么大的产品，我们在规划产品管理、项目管理、团队管理协同层面，都需要提供一定的支撑，使交付活动朝着一个目标有效进行。
所以在组织协同层面，我们需要进行一系列的支撑。比如刚才提到不同维度的支撑，还有知识层面，以及资产层面的支撑，为了全局的优化改进，还需要建立度量系统进行支撑。
第二个层面是最重要的，在价值流交付的层面需要进行支撑。这是中兴系统产品在研发交付价值流当中最主要的活动，从需求规划一直到最终的部署、运维、监控，整个价值流当中有三条主线，最上面是软件交付的主线，从软件设计一直到软件版本的发布。
中间是硬件产品线，下面还有一条文档交付的主线，系统产品的复杂度，使用户在使用系统产品的时候，需要了解大量关于系统产品的特性和使用的配置方法，这些需要通过文档进行相应内容的传递。这三条主线必须有效协同，进行完整的交付，然后在客户端进行部署和运维。实际整体的DevOps实践，也要围绕这三条主线进行。

3、中兴系统产品发展历程

这是中兴对这几年DevOps实践探索的历程进行的总结。

2010年到2012年是探索阶段，重点做了敏捷探索，在工具和提效层面，重点是为了交付需要开发的自研工具，主要是在试点层面进行探索，大部分还是传统的研发模式。
2013年到2015年，开始在项目级推行敏捷，这时候提出了敏捷的成熟度模型、DevOps成熟度模型，通过这两个模型带动流程和技术实践的提升和改进。这段期间我们也进行了内部研发工作的共创共建，把云CI和云测试进行建立，在项目的交付版本周期层面，通过流程的优化改进已经有所提升，达到了三个月左右，早期这个基本在一年甚至半年以上。
2016年到2017年产品级敏捷，DevOps正式在公司立项，重点项目的交付周期进行了大幅度缩短，质量也有明显的提升。
2018年到219年，这是DevOps平台产品化的阶段，重点进行DevOps产品化并提升它的可用性，在产品安全、合规方面也做了一些实践，我们内嵌到整体流程。

二、痛点与挑战

前面介绍了系统产品的特点和实践历程，我们在前期探索过程中碰到了哪些痛点和挑战？

1、项目诉求

项目上线DevOps平台，会有一些明显诉求。
首先这个平台必须要能快速上线，不需要项目通过大量自己DIY的过程。
第二个是需要灵活配置，刚才也介绍了，系统产品这块的差异非常大，不同的项目有自己的特点，需要根据项目特点进行灵活的配置，满足项目自身的要求。
第三个是高可用，产品交付的压力非常之大，晚上经常加班，周六周日也要外发版本，这种情况下DevOps平台要求不间断运行，要求达到2个9、3个9甚至4个9的要求。
第四个是轻量级维护，项目希望集中精力在价值交付上，要做到感知比较小，维护量比较小。
第五个是优秀实践快速复制。
第六个是整体方案需要具备持续演进特点，不能说一旦哪个工具出现重大的问题，或者是售后有问题，给整个方案造成项目不可用的情况。在实践的过程中，我们结合方案框架本身和项目诉求，做了大量的改进工作。

2、DevOps方案挑战

方案层面的挑战除了项目诉求其实也非常明显。DevOps里面涉及大量开源工具，怎样选择更有代表性或者是更合适的工具？不同的项目特点不一样，有可能在选型上会有比较大的分歧，怎样能确定工具的主行道？这是我们要面临的难点。不同时期引入的工具存在重复建设，这也是我们面临的问题。
早期我们探索的时候，在架构层面的设计不足，大量依赖于项目自主式的改进，在持续演进时会暴露出扩展方面有巨大缺陷，需要我们进行顶层设计，公司在这方面也走过一些弯路，成立了专门的规划和设计团队，使我们的方案具备可演进性。
能力方面，前面也说到我们是做CT的，早期IT相关的技术积累不足，这块对我们来说也是一个挑战，而且有些开源工具前期的接触比较少，引进过来之后怎样能快速通过适当改进满足项目诉求？这方面的响应也比较慢，需要我们不断去提升。
资源方面，公司内部的资源分布在各地，分布在各个不同的组织部门，在DevOps里面射击队资源的统一调度，怎样把分散资源整合起来提升效率？这都是对我们的巨大挑战。

三、DevOps实践

这是目前DevOps解决方案的框架，是基于分层框架进行的，最底层是基础设施，包含资源池、物理机、虚拟机、容器，一系列的功能都作为基础设施层。
上一层是数据层，主要是价值交付的关键数据，比如代码、用例、文档、制品，包含数据仓库。
往上是服务层，包含两层，第一层是能力中心，这些能力中心是由内部开发包括外部引进的工作组成的，比如需求中心、版本中心、组件中心、集成中心，这些类似基础能力平台，为服务上层持续交付的流水线提供服务。
在这些中心的基础上，我们上面有变更管理、持续集成、发布测试、持续交付、运营监控五个大领域，支持系统端到端领域的交付。最上层是场景层，主要是项目的重要触点，从规划到管理开发，还有协同、共享、全景化视图。

这是我们的基础设施层，分为几个层次。底层是数据中心，我们在不同的研发基地设置了数据中心，上面有资源池调度能力，再上面是云服务对外接口，最上层是对基础设施的管理。

对项目而言提供服务，这是DevOps目前最关注的。上面蓝色的示意图是DevOps的五大领域。在服务层领域，最重要的是通过各个中心能力的编排和调度来提供DevOps服务的能力。我们可以看到，前端是变更管理，通过需求中心、故障中心，对系统产品产生的一系列变更进行分析、处理、排序，纳入到规划里。
规划结合已有的内外部组件进行总体交付版本的规划。进入到开发环节，我们进行代码的开发实现、编译构建，进行一系列的测试、集成、打包，最后到测试中心进行测试执行和测试结果的分析，最终到交付中心，提供版本的归档和外发下载。
下面是开发过程中对于产品安全和合规一系列能力的支撑，从开源扫描、代码质量扫描、缺陷扫描、安全漏洞扫描到病毒扫描，贯穿到整个开发交付的全流程。

下面是第二个大的领域CI，这是相对比较成熟的领域。CI这块目前的解读方案是基于模型的解读方案，我们会结合CI通用模型建立流水线相关实体重要模型，进行代码化，解读方案会基于代码化模型进行模型解析和事物构建，最后在DevOps平台上创建CI实例。
CI的配置会切分为项目配置和公共配置，可以极大程度降低项目使用CI的工作量和维护成本，下面CI的公共库是把CI里面用到的公共能力进行封装提供给项目，希望项目自己进行二次开发。右边是DevOps平台进行工作的调度，上面是正在运行的CI各个实例。

这是具体产生的分层CI，系统产品的规模非常大，所以在CI里面也是通过分层CI的方式进行不同层面的守护，比如个人CI，对个人代码的变更进行守护。在组件的范围内对组件变更进行守护，再到上层是针对产品做的，还有一个是解决方案。通过分层的CI守护，使变更影响面和波及面缩短到最小，保障在整体的产品层面和解决方案层面随时有可用版本。
这是我们发布测试层面的解读方案，基于在版本和特性里根据交付需求和特性进行测试用例的设计，目前有一个内部研发的自动化设计工作，可自动生成用例，通过用例生成脚本。在环境自然这块进行虚拟自然和物理自然的管理和调度，用例生成后可以在测试实施的时候申请到资源，然后在资源上执行用例。
用例执行完之后，还会有针对用例的分析，结合版本相关的数据，结合版本发布的质量策略进行分析，最终进行版本质量红线的保障。比如是版本的质量策略要求，我们不能有任何漏洞或严重缺陷，最终在自动化测试完毕后，会判断这个版本是否达成要求，如果达不成要求，版本不能推送到发布的制品库。

下面是测试过程中的测试数据，包含数据之间的关联关系，包括需求、特性、用例、故障相互之间的关联关系。

这个是我们在DevOps解读方案里做的探索。严格来说前面谈的DevOps很多是在软件领域，我们希望结合产品特点，利用软硬件一体化交付的特点，在硬件快速研发和交付层面做一些探索，我们进行了基础能力建设，结合硬件特点搭建数字化设计的云，进行线上的硬件设计、仿真、检查、测试，目前也是在探索阶段，希望能加快整体硬件交付的速度。

这个也是系统产品特有的特点，就是文档持续交付的探索。系统产品这块文档的交付，运营商的要求非常高，新有的高端运营商在拿到产品之后，实际要求必须严格按照文档进行操作。
有的运营商是用自己的流量进行维护，我们的人即使对我们的设备非常了解，也不允许进行设备操作，导致文档层面的要求很精准，所以文档的交付压力也非常大。早期的文档有大量手工的环节，甚至有很多线下交互，我们这个实际是把文档的交付自动化。
在生产环节，要进行文档内容的结构化，结构化的主要目的是减少文档的重复及冗余信息，减少文档内容的不一致，一部分内容只要写好，可以在多个地方同步应用，可以提升文档生产效率，在文档的质量上也有比较好的结果。
首先需要对内容生产架构进行设计，找其不同的角色，在文档的需求、方案、特性中都进行过设计，通过自动化流水线抽取内容单元进行组装，这些组装的内容进行代码化管理，在发布阶段可以根据发布的文档组织架构对各个内容单元进行组装，最后形成用户所需要的文档。这个文档也可以通过快速反馈，把问题反馈到作者这边，由作者进行修订。
这个方案的特点，一个是实现了文档的同源，这是文档编写过程中非常重要的要求。第二个是把研发信息进行结构化。第三个是最终文档生成的过程要全程自动化。第四个是通过这种模式，实现文档编写过程中达到全员共创，每一个角色可以把自己岗位最专业的内容进行输出，最终文档的生成可以结合各个角色输出的知识点形成最佳的文档。

还有一个系统产品关注的方面，就是产品的安全及合规。我们现在把安全和合规的能力作为版本外发当中必须要经过的环节，这里面重点是针对开源、白盒代码扫描、黑盒漏洞测试、病毒，会在版本级CI的打包环节开始进行各项扫描，在测试环境阶段对整个交付物进行完整扫描。
这是为了降低项目上线和应用成本做的界面和入口。项目上线的时候，只需要在Web界面进行项目注册，就可以使用整体提供的CI流水线，提供需求和测试管理的视图。

这也是在整个DevOps实践中非常重要的环节。早期我们进行DevOps改进的时候，我们也觉得需要通过系统化模型引导大家在DevOps上不断持续改进，当时自己内部结合业界实践来做，最早的时候我们看到百度做了工程能力的等级，参考了他们的实践，对DevOps成熟度进行定义。
早期我们只需要做自动化的探索，第二级要求通过DevOps实践支撑迭代交付，比如持续集成，自动化测试水平需要达到一定程度。到了第三级，要求从需求到测试环境部署的范围段里能实现自动化交付。到了第四级，希望从需求到商用环境端到端的部署能力有所提升，并且有全流程的自动化度量分析。到了五级，我们希望能把智能运维的实践纳入进来。
右图是针对模型的五个维度，从持续规划到监控与反馈，是全周期进行能力要求，我们也把需求、管理、硬件可靠性等等都纳入了进来。

这是在整体方案上的收益。我们首先有一个整体解决方案的框架，在公司范围内统一了DevOps术语，这个也是正在推进当中的。
第二个是分层模型，我们的解读方案是基于业务活动进行抽象提炼，基于CI系统建模，围绕整个研发交付活动的业务核心，把工具细节进行剥离，用户在使用的时候进行配置，它也会比较容易理解，因为这些活动是前期抽象的，也是结合业务活动本身来开展的，使用的时候不需要理解实现，只需要理解自己开展的这些活动就可以做配置。
第三个是工具解耦，我们解决方案的特点不是一上来就把工具作为首要考虑的因素，而是建立好模型再选择工具，希望能跟工具特定的功能和特性做解耦。在解决方案不变的情况下，可以进行工具的切换。

这是运维方面带来的好处。
第一个，整个解决方案模型部分代码化，包含配置信息进行代码化，多分支自动化管理，包含流水线的管理，自动化程度会比较高，分支拿出来可以快速编译出版本。
第二个，整个解决方案里把DevOps平台里的开发实现和配置部分做了解耦，项目的运维小组只需要关注配置相关的内容就可以了，配置人员的工作量也大大降低。
第三个，我们对DevOps整个发布的产品进行了版本化管理，每一个流水线正常工作时所使用的DevOps产品版本号会进行严格的定义关系的关系，保障随时都能构建出历史某个时间点构建出的版本。

四、思考与展望

前面重点介绍了解决方案、框架、重点实践，最后做一下思考与展望。

这个框架之前也给大家介绍过，有几个方面我们目前准备做进一步的探索和尝试，比如关于组件的共享。公司有几万个研发人员，我们没有像谷歌那样实现单一代码库管理的情况下，怎样使得大家的研发成果能快速共享和复制？
我们实际在做组件共享的功能，这个功能使得不同产品之间有一些公共协议、公共组件可以快速被引用。另外，我们DevOps也关注全局优化，产品大了每个人能看到的范围受限，这种情况下进行全局优化很困难。
大项目对于整体的把握非常关键，所以我们开发了全景视图，让项目里不同的角色能快速得到需求端到端的信息，需求吞吐量的信息，需求交付过程中的风险信息、进度信息，可以快速看到，启动快速决策和全局优化。服务层有两块是短板，变更管理和运维监控管理。这也是我们后续想重点探索的方向。

这是关于端到端的协同。我前面介绍的内容大家也看得很清楚，还是集中在开发到制品库这一段，华为的同学昨天也提到，我们只有Dev，没有Ops。如果要真正产生价值，需要跟最终客户关联，实现端到端的贯通，这块也是比较大的课题。
最终能实现我们的价值，从客户这边来，然后到客户部署，以及到客户部署之后的反馈，这个大的闭环可以真正实现，包括今天上午也在跟广东移动做一些交流，希望有一个试点，能真正通过两个企业之间DevOps平台的对接，实现整个价值流的闭环。如果单靠我们，这个实际是非常困难的事情。

这是DevOps的航标，经过之前老师的介绍，我们觉得这个非常体系化，在国际上也比较领先。前期很多的探索，比如公司内部有敏捷改进，还有DevOps的相关改进，内部是分开的，但航标把它们融合在一起，这也是我们后续准备重点进行的探索，把敏捷DevOps融为一体，做一体化的改进。
目前内部的成熟度模型已经跟航标做了对接，进行了大幅度的优化，也希望能借助于航标里面的优秀内容，能够在内部做拉齐。
分享内容到此结束，谢谢大家！