类目

【直播回顾】DevOps国标来啦！｜践行者第35期

原创

发布：践行者于 2024-03-22 13:52:35

最后编辑：晏瑞宇于 2024-03-22 13:56:14

926次查看

摘要：DevOps国标是什么，有哪些独特之处？一起聊聊DevOps国标！

本篇目录

随着数字化时代的到来，企业的信息化建设日益成为其核心竞争力的体现。DevOps理念逐渐受到了广泛关注。

为此，我们特别邀请到了上海翰纬信息科技有限公司副总经理孙翊威老师、资深DevOps咨询顾问汪珺老师、以及中国电子技术标准化研究院DevOps评估负责人刘北辰老师，一起和大家聊聊DevOps国标的相关问题。

一、DevOps国标来啦！

1.DevOps国标简介

刘北辰老师：

中国电子技术标准化研究院是专业从事工业和电子信息技术领域标准化科研工作的机构。截至2022年底，电子标准院在电子信息和技术领域共制定了14,203项标准，其中国家标准占据了4,199项。值得一提的是GB/T 42560-2023，为开发运维一体化的国标。电子标准院还主导了5,300多项行业标准，并且成功地引领了244项国际标准的制定。此外，电子标准院还荣获了14项国家级奖项和333项部级奖项。

国标立项政策的背景，源于两大层面：国家政策与国际政策。

国家政策

为了贯彻工信部的十四五软件和信息技术服务业发展规划，我们致力于推进模式与机制创新、软件开发模式的优化，并广泛推广软件开发云和智能化开发工具。此外，我们特别关注软件交付、产品升级、运维服务的一体化实现。同时，工信部的十四五信息化和工业化深度融合发展规划也强调了依托工业互联网平台，以推动高水平、高效率的轻量化设计、并行设计、敏捷设计、交互设计和基于模型设计的进步，进而促进设计与工艺制造运维的一体化。

国际政策

美国和英国均积极推出数字化战略，其中美国战略和数字与数字化服务标准都将敏捷开发、DevOps等现代化方法作为政府鼓励推荐的方法。这些国际趋势为我们国标立项政策的制定提供了重要参考和借鉴。

国标研制的背后，承载着行业的期待与努力。自2020年6月启动以来，历经一年多的精心打磨，标准草案在2021年7月已初具雏形。紧接着，经过标准院内审会的严格筛选与完善，于2021年8月至11月期间完成了征求意见稿的定稿。随后的2021年12月至2022年6月，标准经历了广泛的网络与现场征求意见，并成功通过了技术审查会，确保了标准的科学性与实用性。自2022年7月至2023年5月，标准逐渐走向成熟，形成了报批稿，最终得以正式发布。值得一提的是，这一标准的正式实施定于2023年12月1日。

国标是由中国电子技术标准化研究院牵头制定，主要编制单位还有南大、北斗天地、网易、共青科技、华为技术、中兴通讯等国内30余家产学研用单位。

DevOps国标

徐东伟老师：

本标准正式实施是2023年12月1日，这与正式发布的日期有什么区别？

刘北辰老师：

“正式实施”相当于标准可以落地，如正式的标准贯标、标准评估工作等可以开展了。而“正式发布”后会有一个准备期，一方面是让大家了解，另一方面是我们也要有所准备。

徐东伟老师：

“DevOps国家标准”是一种口语化表达，它的全称是系统与软件工程开发运维一体化。

刘北辰老师：

对，“DevOps”是由“Development”和“Operation”组成，分别取了两个单词的前三个字母。大家可以通过公共服务平台（openstd.samr.gov.cn/bzgk/gb/），在国标详情页中点击在线预览，就可以在线阅读国标的全文内容，但只能在线阅读不能下载。

DevOps国标

2.国标的重要性

刘北辰老师：

我们从四方面来介绍国标的重要性：

标准化实践

国标提供了标准化的实践指南。我们的国标名为GB/T，它并不完全遵循传统的推荐标准写法。相反，它在每个条款后面都附加了实施指南，以便大家在阅读标准时能够更便捷地形成落地思维。此外，本标准还有助于组织建立一致的DevOps实施方法，确保各个团队之间的协作与配合，从而降低沟通和合作成本。这是国标在标准化实践方面所起到的作用。

质量保证

国标涵盖了质量管理和安全管理两大能力领域的要求，有助于组织确保软件交付的质量和安全，提升系统的稳定性和可靠性。

风险管理

国标还提供了风险管理和合规性方面的指导，帮助组织识别和管理潜在风险，并确保在软件开发和交付过程中符合法规和标准的要求，从而降低项目失败和因违反法律而产生的风险。

效率的提升

通过采用国标规定的最佳实践和流程组织，我们可以实现工作流的优化和自动化，进而提高开发交付效率，加速软件上线和反馈周期，从而更好地满足客户的需求。

孙翊威老师：

刚才刘老师是从编制角度来说国标的作用。我记得2019年、2020年的时候，行业内有一个争议：DevOps是否应该做成标准。当时有两派观点，一派认为DevOps就是实践，另一派则主张制定标准。其实双方都有各自的道理，很难说服对方。从标准的角度来看，我们需要理解标准的本质和编写的逻辑。我们经常提到逻辑的两个重要概念：归纳和演绎。

归纳

制定标准实际上是一个归纳的过程。从2016年到2020年国标开始编写，再到现在，我们国内DevOps团队做的实践都是将团队的独特性形成一般性规律，实现了从特殊到一般的归纳过程。

从归纳角度来说，DevOps国标是将30多位编委聚集起来，将他们的经验和实践进行归纳，最终形成了一个普遍的DevOps规律。这与每个团队或组织单独进行DevOps实践不同。每个团队单独实践时，只能形成自己独特的方法和观点，存在局限性。但当我们将这些经验汇集起来，通过归纳整理形成一个标准，它就具备了普适性。

演绎

制定标准的重要性在于其演绎过程。当实践经验被归纳成一个国家标准后，对于所有应用这一标准的团队或组织来说，这个标准成为他们实践的依据。标准已经通过广泛的抽象归纳被定为国家标准的统一框架，它为团队的实践活动提供了指导。我们可以从标准出发，推断团队的实践行为，同时验证这些行为是否符合一般规律。基于这一标准体系的严谨框架，我们可以得出DevOps团队实践这一标准的必然性。因此，从归纳和演绎的角度来看，制定标准不仅仅是一个规范实践的过程，更是一种逻辑推理的本质体现，无论是在实践中总结标准，还是在标准的指导下进行实践。

从我们咨询工作的角度来看，标准并不是仅仅拿着一堆文件与大家对标，这只是表面现象。其实，它的本质是一个经过众智归纳形成的国家标准，需要通过演绎的方式在组织中指导实施，发现新的改进项，成为组织持续提升的新知。

刘北辰老师：

孙总说得非常正确。我认为标准来源于实践，并最终应用于实践。在制定标准之前，我们集合了众多产学研用单位，充分汲取了实战中的经验和教训。当标准形成后，它还需要指导实战中的应用，确保标准的落地实施。

汪珺老师：

我讲一个亲身经历，在2015年我在美国就开始做DevOps，这算是非常早的。在美国做DevOps，很多时候都是以工具先行，加上敏捷开发方法。但当我回国后发现，其实中国很多企业还没有做。当企业做的时候，开始考虑：我是否要对标国际的Capital One、Barclays银行。

但中国的特色在于将流程和工程紧密结合，比如金融、通讯、物流、航空、互联网，包括现在的汽车、新势力制造等。以各类To B生态和To C的生态为例，照搬了国外的方法，仅仅只是把工具链打通但没有考虑其流程。坦率地说，许多国外的业务从思维方式到IT软件都是很简单的但是垂直纵深化，中国则是业务形态思考齐备、融合多。国外软件不像国内软件那么复杂、集成难度大、有严格的质量合规要求。

在这过程中，我时常遇到客户向我咨询与国际企业对标会出现问题，以及该参考哪些成功的实践案例。一些领先和具有创新精神的行业佼佼者，如顶尖的银行或新兴的互联网银行，他们在各自的领域内确实已经涌现出许多值得借鉴的最佳实践。众多来自金融、通讯和产学研等领域的参编者纷纷涌现，他们会聚合成最佳实践，逐渐形成了一套普适的原则。

大家在看国标内容时，会发现其言简意赅的特点。在每个阶段和每个级别的区域实施时，国标以清晰的相关标准为指导。而不像2015年时，每个人对DevOps的理解不尽相同，导致研发、运维、测试甚至业务需求等部门难以达成一致。由于大家的认知和理解存在差异，这会出现大量的矛盾。当国标发布后，我们会形成一个普适的原则和标准化实践。通过标准化实践，最终归纳总结成大家普遍接受的标准，该标准再进一步引领大家去不断地涌现适合自己的实践。所以，我们要归纳、总结和抽象，再进行解读和思考。

国标为我们描绘了一幅清晰的未来蓝图，不仅对我个人而言，更对广大客户而言，明确了我们可以达到的目标和愿景。我们在当前阶段的构建重点是什么呢？面对DevOps项目，内部涉及的项目规模庞大，我们如何确保沟通的顺畅和准确对齐呢？国标的发布将成为我们咨询、甲方、乙方等各方在实践中的重要指导原则。它不仅为我们提供了明确的方向，更在理论层面为我们提供了进一步的指导。

3.开发运维一体化成熟度模型的六大能力域

DevOps国标

国标涵盖了六项关键能力域，即项目管理过程改进、支持、保障，产品研发、服务管理和基础设施。这六项能力域进一步细化为三十项具体能力，这些能力均根据五级程度来定义实践和组成。项目管理、过程改进、支持和保障主要侧重于组织管理的考察，而产品研发、服务管理和基础设施更偏向于技术层面。

项目管理

一个项目无论是否引入了Ops流程，或是像DIAuth在敏捷方法上的发展，项目管理的起点都是制定项目计划，而计划的基础是估算。在制定计划时，我们需要明确项目的大致范围，即项目的规模以及需要完成的功能点。结合生产率，我们就可以预估项目所需的大致工作量。项目计划依赖于准确的估算，因此“估算与计划”作为“项目管理”的第一个能力考察。

当项目进入执行阶段，“监控与调整”变得至关重要。我们需要密切关注项目是否按照预定的时间和资源分配顺利进行。若在执行过程中发现某个节点出现超时或超期的情况，我们必须迅速制定调整策略，确保计划能够如期完成。

“风险与机会管理”是项目管理中不可或缺的一环，因为风险和机会往往相伴相生，妥善处理它们对于项目的成功至关重要。在项目规划阶段，我们可以利用组织的风险库来预估项目执行过程中可能遭遇的风险，以及这些风险可能带来的机遇。我们的目标是最大程度地降低风险发生的概率，并努力确保即使风险发生，其造成的危害也能控制在最小范围内。同时，我们要积极把握机遇，将其放大，让正面效应持续产生。

有些企业可能存在这样的需求，涉及到一些外部采购的物品，因此我们增加了一个“供方管理”，这也是我们30个能力中唯一一个可以裁剪的。例如，如果一个企业或组织不需要进行外部采购，即没有这样的行为，那么它们可以不必参与供方管理的评估。

过程改进

“过程改进”的第一个能力是“组织治理”。从管理层的角度来看，需要为公司或组织制定一个整体方针，此方针中包含专门负责过程改进的领域。在这个领域里，组织会成立一些过程改进的EPG小组，负责资源分配和过程改进的整体计划，为组织管理者提供强大的指导。此外，为了支持过程改进，还需要“建立过程改进基础设施”，从人力、物力、财力方面给予支持。

“过程资产管”也相当重要，因为在过程改进过程中会形成一些规程文件、指南文件、模板文件等，这些都是过程改进的宝贵资产。那么对于过程资产，我们需要制定一个管理策略。在很多情况下，组织会建立一个过程资产库，并在其中收录各种过程改进，包括标准工具、标准实施等。而效能管理则更侧重于效率、进度、质量以及价值。在DevOps度量体系中，通常我们可以使用发布频率、发布失败次数、平均故障恢复时间等指标作为“效能管理”的衡量依据。对过程改进来说，我们还需要一些“组织级培训”进行相应的支撑。

支持和保障

“度量和分析”的能力至关重要。不论是估算和计划，还是说过程改进，在过程中都需要收集和分析一些度量的指标。根据指标的分析结果，我们会得出结论并提出指导性的意见。此时，我们需要利用“根因分析和解决”的能力，根据各个原因去制定一系列的解决方案。在有了解决方案后，我们需要跟踪其有效性。值得注意的是，根因分析在过程改进中还涉及“配置管理”，这其实并不难理解。

“安全管理”更偏重于开展安全合规教育，同时管理组织资产、活动以及软件产品的安全合规性。此外，它还涉及到根据需求进行相应的培训，制定研发和生产环境的安全标准，并在组织层面建立安全风险监测和事件应急响应机制。从这方面来看，我们都知道在SecDevOps中，我们要将安全机制贯穿于整个DevOps流程之中。

我们还需要具备“决策分析和解决”的能力。在进行一些重大事项之前，我们需要制定若干备选方案。这个时候，我们就需要定义并记录这些备选方案，然后做出决策并记录结果。接下来，我们会引入识别备选方案的解决方案，并选择评价方法、使用准则和方法来评价和选择最终的解决方案。此外，我们还需要建立、使用和维护基于角色的权威主体的描述等。

“过程质量保障”是指识别和解决过程以及工作产品中的问题，并开发和实施更新，以遵守质量保证方法和计划。通过这个过程，我们进一步沟通和解决产品研发过程中的质量和不合规问题，识别并记录改进的机会。

产品研发

不论我们采用敏捷开发还是瀑布模型，它们都涉及到“产品规划”、“架构与设计”。在此基础之上，国标根据DevOps的特定，特别加入了“持续集成和交付（CI/CD）”。这考察的不仅是在DevOps流程中进行CI/CD的相关活动，建立并更新CI/CD的一些相关规范和标准；还考察的是构建自动化系统对CI/CD的支持能力，以及将CI/CD实践融入到组织标准研发过程之中的能力。

服务管理

“开发运维一体化”中的“开发”指的是产品研发，而“运维”则指的是服务管理。服务管理与前面所讲的项目管理相似。首先，我们要有一个“战略服务规划”，即根据组织的商业目标去规划组织中提供的标准服务。然后，我们要评估“服务交付”能力，根据服务协议来更新我们的组织级服务协议，并准备和持续交付服务进行运维。接下来，我们要建立服务交付组织，并利用组织资产来制定服务交付的协议和方法。同时，服务交付也需要一个“服务监控”机制，监控服务是否有异常，当出现不良结果时进行根因分析，并采取措施进行纠正。这是保障服务质量的重要环节。“服务连续性”主要关注的是在服务出现异常中断时，我们如何迅速恢复服务，以及有哪些手段可以实现这一目标。为了实现服务连续性，我们需要进行服务的保障工作，设定服务优先级，并定义一些服务治理手段。此外，我们还需要建立应急预案和培训，并定期对预案进行演练和改进。

基础设施

DevOps要基于系统和工具链的整体规划和支撑。所以说我们有了这个系统与工具的规划，首先我们要制定支持DevOps的系统和工具发展规划，并且这个规划是持续性的，也就说每年都可以规划来年的一些新工具的升级和改造。接下来就是接一些系统和工具的支撑，系统工具的支撑其实就是提供适合的工具去支持适应组织，这种特色的DevOps实践包括一些自动化、可视化以及组织级的连通性、全流程的可视化一站式服务。最后是环境支撑，就是提供了满足团队的DevOps实践的需求的环境。

DevOps需要基于系统和工具链的整体规划和支持。因此，在有了“系统与工具的规划”后，我们首先要制定支持DevOps的系统和工具发展规划，并且这个规划是持续性的，即每年都可以规划来年的新工具的升级和改造。“系统与工具支撑”其实就是提供适合的工具去支持适应组织的特色DevOps实践，包括自动化、可视化以及组织级的连通性、全流程的可视化一站式服务。“环境支撑”提供满足团队DevOps实践需求的环境。

以上就是我为大家介绍的这个开发运维一体化能力成熟度模型的六大能力域、三十项能力。

4.模型成熟度等级的演进

DevOps国标

五级模型的成熟度等级的演进规则是参考了CMMI，该能力等级成熟度设定的一些规则同时也融入了一些DevOps国标的特色。

1-5级的CMMI5级能力成熟度模型是大家都比较熟悉的。

第一级被定义为初始级，其中标注为红色的部分表示尚没有完整的、系统的实践集。但即使如此，它已经有了满足能力、意图和价值的初步方法，因此我们将其定为一级。
第二级相当于已经在项目级的这个层面上已经有了满足能力全部意图或价值的实现，换句话说在项目的层面上已经有了一套自己的打法能够支持能力相关过程定义所需。
第三级则已经升级为定义级，即组织级的能力，这种能力需要横跨多个项目和部门，形成标准流程。换句话说，对于同一个组织来说，a、b、c、d这四个项目应当采用相同的实践集来进行相应的处理和执行。这些项目还应该有明确的裁剪规范，以及由组织制定的标准规程文件和标准指南文件等，以支持三级的定义级要求。
第四级是定量管理级，它是在三级的基础上，所有项目的执行都应遵循一套统一的做法。由于大家在三级基础之上的做法和策略都相同，因此收集到的度量资源或度量数据都是归一化、统一定义的数据。在这个基础上，我们有能力将管理升级到四级定量管理级。
第五级持续优化级，分析的重点不再是特殊原因，而是能够分析出一般原因，以此来提升过程性能，更好地支持组织业务目标的实现。

这就是我国国标的演进规则，总共分为五个级别，其中一级不作为评估对象，我们通常从二级开始进行评估取证。此外，国标每个条款下都会提供相应的实践活动示例以及这些活动所生成的输出物，包括测试列表、测试分配结果以及利益相关方参与情况的记录。

5.评估模型的特点

刘北辰老师：

评估模型包括项目管理、过程改进、支持和保障、产品研发、服务管理、基础设施这六大能力域。以基础设施为底座，毕竟做DevOps，肯定离不开系统和工具链的支撑。底座之上是产品研发和服务管理两部分，也就是我们会在这几部分考察常说的开发运维一体化。在这三部分之上，是组织能力一体化的体现，通过项目管理、过程改进和支持保障这三方面，进行一体化集成能力的考察。换句话说，根据这幅图，我们可以得出，这个评估模型有两大特点：

特点一：研发运行一体化是一种产品交互的方式，不仅强调了产品研发、服务运维管理以及运行环境管理这个能力一体化，还强调了与项目管理、过程改进和支持保障等相关领域一体化的集成能力。
特点二：我们在做成熟度评估的工作中，面向的组织可以是实体部门（如金融银行内部的科技部门），也可以是临时群体（如临时性的项目组）。这就是评估模型的特点。

6.参与评估有什么好处？

DevOps国标

刘北辰老师：

首先在输入过程中，我们有组织内部需求和外部需求两方面。从内部需求来看，参与评估的组织是一方面为了考察DevOps目前的执行效果，另一方面是可以增强产品的质量和可靠性，通过评估获取一些持续改进的建议，最终达到降低开发成本的目的。从组织外部需求来看，参与评估可以提升用户的满意度，巩固行业领导地位，满足双方的评估要求等等。

中间这部分是依据GB/T 42560-2023国家标准，以及依据该标准制定的评估模型解决方案：六项能力域、三十项能力、五级成熟度，以及在这之下分级的实践级要求，针对组织级、项目级不同的颗粒度开展开发运维一体化的评估工作。

我们的服务成果在最右侧，有两方面：一方面是通过评估后，由电子标准院出具评估报告和证书；另一方面是对组织参评的实践和过程进行评估，识别被评估方过程实施中的改进机会，推动实施能力持续改进。

7.评估的流程是什么样的？

DevOps国标

刘北辰老师：

被评估组织要先提交评估申请表，随着评估申请表还要提交一些文审材料。评估申请表里要写组织的基本信息，包括至少两项参评项目的介绍信息，然后就是参与评估工作的人员信息等等。评估期间可能还要经过多轮迭代，如果我们认为合格了，那么就可以受理评估申请，并且开展文审工作了。

接下来就进入预评估阶段，现场预评估的时候需要拿着文审材料，对照这个组织的申请表。我们会抽取30个能力中的某些能力，进行相应考察。如果认为该组织提供的材料和被评估组织人员的口录能够对照上，我们会提供一份就绪性检查报告。就绪性检查报告会决定这个组织是否能参与到正式评估工作中，如果我们认为具备正式评估的条件了，就会进入正式评估工作中，如果说不具备，还需要打回去，需要被评估组织再做相应的整改、修改。

进入正式评估工作时，还是由四院作为评估机构，我们指定组长编制现场评估计划。到了现场，我们会召开首次会议，签署保密协议等文件（我们有义务对被评估组织的文审材料保密），然后开始进行逐个能力域的评估取证和访谈工作，并同步记录评估检查表。最后评估组会出具不符合项报告（考察完所有能力后，将一般不符合项或严重不符合项记录在不符合项报告里），如果说评估不通过，我们还有一次整改机会。当评估通过时，我们还会召开内审会议。内审会议会换一批专家，对整体评估过程进行复审。如果内审专家也认为没问题，就会编写评估报告，进行发证工作。如果内审会议没有通过，企业还要进行一次整改操作，重新再提交进行现场评估，大体流程就是这样。

8.国标需要哪些生态玩家？

DevOps国标

刘北辰老师：

先从需求方来看，需求方大体分为两类：

一类是甲方，甲方是已经引入了DevOps流程工具的组织，自身有一些需求，想考察工具使用的执行效果，想获取改进建议，或想通过培训服务培养过程改进专员。培养出来的过程改进专员一方面可以配合评估工作，另一方面，过程改进专员留在企业也可以继续依据国标进行DevOps落地实施；
乙方包括DevOps工具厂商、软件外包公司等。乙方的需求是提升甲方的满意度，巩固行业领导地位。同时对乙方内部来说，也想通过DevOps的实施加快软件的交付速度，包括怎么高质量交付、快速地交付，同时也想获取改进建议。

以上是需求方，有了需求方之后，我们就要有一些相应的服务提供方：

首先是评估服务方，目前电子标准院基于该标准会提供一套成熟度能力评估服务；
第二是咨询服务方，提供DevOps实践的专业咨询和建议服务。根据一些参评单位的需求和情况，对这些单位的DevOps实践进行分析、规划和指导，辅导单位能够更好地参加评估工作；
第三是培训服务方，这就需要很多资深专家，可以面向软件企业，提出解决方案，并作为解决方案的提供商、咨询服务机构等，基于标准开展培训和考核认定。刚才提及的举办培训班，有一个比较关键的条件，就是制定一套比较好的培训教材，这时就需要资深行业专家出谋划策，以后也可以作为培训讲师，帮助我们培养很多DevOps的过程改进人才；
最后是宣贯服务方：主要是以省市为单位，联合地方的主管部门、行业协会，比如软件协会可以持续地召开DevOps标准宣贯会，提高软件企业对本标准的认可度。

9.DevOps成熟度评估申请名额即日开放！

刘北辰老师：

即日起，我们开放DevOps成熟度评估申请名额。目前，企业申请评估名额，需要具备以下资格：

第一，企业需在过去一年具备至少一个已经成功实施的DevOps项目经验，且至少完成两个项目。这是因为我们颁发的是组织级证书，重点评估整个组织的成熟度和能力。
第二，具备CMMI评估经验将是一个加分项。因为我们的组织级管理评估涵盖项目管理、过程改进以及支持保障三大能力域。此外，申请DevOps成熟度等级应与CMMI等级相对应。例如，如果您的CMMI等级为三级，那么您最高可申请的DevOps级别为三级。

大家可以直接根据图中信息联系我们，也欢迎大家关注软工分委会的公众号，以获取更多相关信息。

DevOps国标

二、干货问答实录

Q1：什么企业适用DevOps？

刘北辰老师：

我认为，希望通过引入DevOps的工具或系统，以提升软件开发效能的企业，最适合用DevOps。

孙翊威老师：

第一种是真的需要DevOps提升效能。第二种是跟风，别人做了我也做。我们可以从企业本身的业务（比如做互联网业务还是做传统行业的业务）特点；对交付的效能及频率的要求；对业务的价值等维度衡量和判断是否引入DevOps。

我们的客户基本集中在金融行业，它覆盖稳敏双态的特点，既有后台核心系统的稳定要求，又有前端手机银行这种快速敏捷的要求，所以对它来说，会在前端的业务上，更多引入DevOps，在一些核心系统上慎用DevOps技术。所以我们还是要看业务形态，选择是否引入这种模式。

Q2：非软件研发企业适不适合引入DevOps？

汪珺老师：

目前，金融、通讯、物流、航空、互联网、甚至制造设备制造等多个行业，都在靠IT支撑软件和硬件融合发展。我们要重新定义IT不光是软件，也可以是软硬结合。第一个支持业务的发展，第二个是通过IT来加速业务生态发展和加速市场布局，快速推送或者说质量的相关驱动和要求。在这种情况下，通过人为增加很多成本，或者是说把风险发到市场上去，通过DevOps把人或者组织的流程，靠人和人之间的传递，人和人的操纵。像富士康流水线旁边站的都是人，我们逐步地构建这种机械臂，促进我们的产业升级。

因此，不仅仅是纯软件，现在很多制造能源甚至到国家的一些企业，这些是指软硬件和软件驱动的结合，都可以用DevOps来完成。所以在这几年的过程中，我们会发现很多金融、通讯、物流、航空、互联网、汽车、新能源制造等领域，包括军工，都在向这个方向发展。

Q3：新能源电驱动行业也用DevOps吗？

汪珺、孙翊威老师：

使用，新能源汽车电驱动行业的本质是软件定义汽车。目前也接触过十几家该行业的客户，对DevOps咨询、平台建设到实施，都有强烈的诉求。

Q4：照着国标做就能做好DevOps吗？

刘北辰老师：

这有一个前提：满足国标的一级、二级还是更高级是有区别的。如果只是满足一级的话，那么显然只能达到一个初步的水平。但是，如果满足国标二级的所有实践，那么这个项目至少是可控的。

如果您的组织遵循国标三级，那么组织内所有项目的实施方式将趋于一致。这时，大家将遵循统一的规范流程来开展DevOps实践。从组织层面来看，这种做法确保了标准的统一性和一致性。此外，工具或系统的制定也需遵循国标相应的条款要求。因此，只要全面落实国标的各项要求，并根据组织的实际情况选择适合的特色进行实施，那么是能够成功推进DevOps的实施。

孙翊威老师：

简单地照本宣科绝非解决问题的正确方法。不论是进行认证辅导还是具体落地实施，我们都必须紧密结合客户的实际情况。当我们参照国标进行操作时，必须认识到国标不仅是一个体系，更是一个模型。这个模型为我们指明了方向，告诉我们如何去达到国标的要求。例如，国标可能规定了10个关键方面，而我们目前可能只关注并实现了其中的6个，还有4个尚未触及。这正是国标对我们的指导作用所在。如果没有国标作为参考，我们可能会局限于自己曾经做过甚至擅长的那6个方面，而忽视了其余4个同样重要的方面。这种局限性的做法往往会阻碍我们的全面发展和进步。

国标提供了一个体系化的框架，使你能够全面审视自己的工作，从而发现潜在的不足和遗漏。基于这一框架，你可以细致地对照国标来识别存在的差距，并进行针对性地优化调整和补充。这样的做法，不仅能够帮助你更好地实施DevOps，展现出你的灵活应变和独立思考能力，而非简单地遵循教条。

我们需要理解，国标不仅是一个文档，而是一套体系化、系统化的方法。从整体上看，这也是国标被认为是组织级别的，而非仅仅项目级别的原因。

汪珺老师：

我认为国标是一个模型。华为有一句话叫“五看三定”，即看行业和趋势、看市场和客户、看竞争、看自己、看机会。首先，我们要观察行业，如大家都在遵循国标，因此国标可以代表行业趋势。其次，我们要审视自己，要量力而行。以10个人的研发团队为例，从业务支撑度和团队规模考虑，我认为团队没必要评估DevOps国标5级。我们应该将国标作为镜子，根据不同的业务周期，结合自身的能力、科技投入、产出预期以及业务发展场景、竞品的增速，来决定我们在该领域应该做什么。否则，我们就会陷入照本宣科的境地。

Q5：对企业来说，过国标是一种荣誉还是必须通过？

刘北辰老师：

我认为它不是一种必须要过的。一种情况是，当组织内部已经运转了一套DevOps的工具或平台时，想考察DevOps的执行效果，这时可以请评估机构依据国标进行组织内部DevOps执行效果的考量；另一种可能是希望通过这次评估，获取改进建议；还有一种可能就是通过拿证，巩固行业的领导地位。

Q6：过等保和过国标哪个更容易一些？

孙翊威老师：

等保（网络安全等级保护）和国标本质上是一个标准，没有哪个容易点的说法，“难者不会，会者不难”做得不好肯定就过不了。

Q7：国标和EXIN的DevOps体系的差异性在哪里？

汪珺老师：

EXIN构建的是一些国际的方法和模型，国标代表的是结合中国实际构建的整个标准体系。

我是EXIN的首批DevOps授权讲师。EXIN在2016-2017年推出的EXIN DevOps Master，是一个培训体系，结合国际一些方法论推动，主要是以培训的形式切入。国标更多是树立一个标杆，它是一个模型、一个参照物，让我们认知到自己，尤其让企业认知到要往哪个方面努力，所以这两者之间并不冲突。我为了个人和企业的成长，去学习相关的培训体系，在组织内部也要对标和自评，甚至要通过评估、评审来证明我们的实力。

Q8：DevOps国标和SPCA关系是怎么定位的？

孙翊威老师：

SPCA是一个类似CMMI的标准，主要对标的是CMMI。DevOps国标在开发方面借鉴了CMMI模型，在运维领域借鉴了ITSS的模型。所以说，不能直接去比较。

DevOps国标虽然有涵盖“过程改进”的部分，但它在评估的时候，还是要围绕着DevOps开发一体化的核心主线。CMMI是组织级的，它已经在很多组织作为一个开发的实践标准做。当我们做DevOps时，我们更会关注：CMMI的组织级要求在DevOps实践中是否得到了执行？或在DevOps推行中所总结的实践是否又提升了组织级的规范。

Q9：在国标中，SecDevOps如何定义？

刘北辰老师：

就国标而言，我们确实需要考察安全合规性方面，主要包括安全合规的教育培训，涉及管理组织资产、活动与软件产品的安全合规性，以及研发生产环境的安全标准。我们必须及时跟进相关法规要求，确保这些要求贯穿安全活动和软件产品的研发全过程。

安全审计活动也是其中的一个考察方面。从技术层面来看，比如在Git上提交代码后，我们可以使用Sonar进行静态代码扫描。这可以发现一些代码的语法错误，也算是安全方面的一个环节。此外，在形成制品后，进行组件漏洞的扫描等，如果加入这些环节，也可以认为是一种有效的安全管理实践。

Q10：如何成为DevOps国标的评估师？

刘北辰老师：

目前来说的话，四院是唯一的评估机构，所以说要成为评估师的话，最简洁的途径就是加入四院。另一种方式是未来会规划DevOps培训班，一方面，培训班可以讲解国标具体如何应用，另一方面，在培训班中，也会讲国标在具体的评估工作中，以及实战中的使用方法。

在培训班中，我们会设置考试，考试通过后，我们会发一个过程改进专员的证（当然还不是评估师的证），理论上说，我们凭借这个证，就可以作为企业方的代表参与评估工作。此外还会有升级策略，比如再往上考就是评估师。不过，培训班可能还需要再等一段时间。

Q11：国标证书有效期是多久？需要复审吗？

刘北辰老师：

证书有效期现在定的是三年。在18个月时，我们会有监督操作，主要是看初评阶段发现的改进项有没有改进。到两年半时，我们会提示客户要不要续证，如果需要续证或升级证书，需要重新进行初评或初审。

Q12：国标整体评估周期多长？

刘北辰老师：

评估周期很大程度依赖于文审材料的准备。文审材料到位、现场预评估结束后，我们会出具就绪性检查报告，这里会出现两个走向：一个是可以进入正式评估环节，另一个是文审材料不到位，需要再次整改。

如果一切顺利，预评估通过后，我们会在三周到一个月之内组织正式评估。拿三级来举例，在正式评估中，预计是三个人、四天左右的工作量。正式评估完毕后，如果评估通过，会有内审加写评估报告的过程，大概一个月。

所以，如果文审材料过关，取证的最快速度需要2到3个月左右。当然，文审材料审核需要花费多长时间，要看企业自身的能力和准备的充分性。

Q13：只是文审就可以吗？

文审是指被评估方提供与本次评估相关的证据材料，评估机构依据国标进行材料有效性审核判定。当评估机构认为文审材料基本合格后，将会安排现场预评估工作，此时针对文审材料的重点与被评估方进行现场访谈，访谈中如果发现问题，评估机构将要求被评估方进行文审材料的进一步修改。所以文审只是整个评估工作开始时的一个必要环节，评估工作不能只有文审。

Q14：DevOps标准是有一套打分体系吗？

刘北辰老师：

DevOps国标包括五个等级，共计252个条款。要获得三级认证，需要满足大约230个条款的要求，这意味着每一个条款都不能出现严重的不符合项。换句话说，不允许有任何一个实际操作与标准要求完全相悖，或者完全缺乏相应的做法。只要不存在严重不符合项，即使组织目前存在部分改进项或一般不符合项，也可以被视为通过。然而，如果某个条款存在多个一般不符合项，这些不符合项加在一起可能会影响该条款的整体执行效果。在这种情况下，我们可以将多个一般不符合项升级为一个严重不符合项，这意味着该条款将无法通过。

Q15：评估费用是多少？

刘北辰老师：

费用还要等一等，我们现在属于试点预评估阶段，但很快，我们会有相应的政策出来。像费用问题、证书的样式、评估工作量时间安排等等，都会有正式文件出来，请大家稍微再等一等。

Q16：国标在开发和运维的衔接和融合方面是怎么考量和评价的？

刘北辰老师：

国标里专门有一个产品研发能力的考察，还有一个服务管理能力的考察。其实这两个能力都建立在统一要求的考量系统和工具能力的要求基础之上。在产品研发的七个能力，以及服务管理的四个能力中，每一个能力的某个条款，都会有相应的工具实施要求。我们通过系统与工具的实施，将产品研发和服务管理结为一体。另一方面，我们也会通过组织和规程方面的要求，将产品研发和服务管理从管理的角度结合在一起。

Q17：DevOps平台是选择自建、开源还是商用？

汪珺老师：

根据企业特性、团队组成、业务发展速度要求、资金和时间比例等，来决定自建、开源或者商用。

例如：

企业都是外包组成，自己员工为管理者，那么建议一体化商用；
企业员工为自己所有，技术能力非常牛，善于专研问题，并且DevOps工具链出问题后可以不太影响业务，那么可以考虑自建或者开源；这块也有公司文化，包括团队高层的思路影响；
是否开源，除了人员技能、业务要求等，要判断开源是否对于内部信息安全生态和监管要求造成影响，例如金融等，目前都要进行开源治理，如果企业内部没有办法去维护开源生态和安全，那么建议商用；
从时间成本和投入成本上看，如果企业可以用时间换商业成本，自身员工成本可以不计入业务发展成本，那么可以考虑自建；如果成本可以高投入但是要求见效快，那么考虑商用；如果在业务发展初期，既要考虑成本也要考虑时间，可以考虑先开源，简单地搭建一下，但后期业务做大后要考虑DevOps工具链的并发性、安全性、功能齐备性是否阻碍业务发展。

综合来看，公司业务特性要求、团队文化、公司监管合规要求、人员能力、是否外包、时间和成本因素等，综合考虑DevOps如何进行建设。