文/童向杰 谢凤玲 王克凤 董丽花 周天才

1 引言

企业数字化转型是指企业利用数字化技术和能力来驱动企业内外业务创新和商业生态系统重构的一种途径与方法，其目的是实现企业业务的转型、创新、增长。它可以在以下三个方面进行智能化赋能：

（1）通过打造出轻量化或者服务化的PaaS、企业应用系统容器化、一站式敏捷IT开发与运维、自动编排和IT 资源最大化利用给企业IT 赋能；

（2）通过智能数据归一、数据统一治理与服务、数据实体化融合和数据资产化实现数据赋能；

（3）通过赋予企业（AI）智能，改变线性的人为经验决策，向基于大数据与算法模型的机器智能辅助决策，包括感知智能和认知智能。从而实现业务转型、创新以及收入增长。

而研发是企业经营的重要一环，因此数字化研发是在企业数字化转型中必须解决好的关键环节之一。对于软件企业，企业数字化研发通常采用软件DevOps 思想和方法，DevOps（Development 和Operation 的组合词）是一组过程、方法和系统的统称，用于促进开发（应用程序/软件工程）、技术运维和质量保障（QA 部门）之间的沟通、协调与整合。软件DevOps 融合了敏捷管理、持续交付、IT 服务管理和精益管理等四大部分内容，形成了完整的框架体系。与之对应，在工程实践上，通过流水线技术，体现价值流动思维，通过将过程任务代码化，实现过程自动化，也因此使得DevOps 在数字化软件研发中大放异彩，也是众多软件企业拥抱软件DevOps 的关键所在。

由于企业数字化转型本质上是要解决“IT”驱动“人”的问题，鉴于软件DevOps 的成功实践，所以DevOps 思想完全可以推广到硬件产品研发领域，虽然相对软件产品研发，硬件产品研发牵涉到学科、工具、供应链和管理等领域更广，但是本质上一样的，即硬件DevOps 就是利用数字化技术，消除数据孤岛，促进硬件产品研发各专业内部以及专业之间协作的一体化，达到消除业务痛点、提升效率的目的。但是，也正因为牵涉领域广，还有与企业现行IT 系统兼容问题，存在如投资大、建设周期长、短期支撑业绩提升度量等问题，硬件DevOps 进展比较缓慢，仍然以如高效产品研发（HPPD）和集成产品研发（IPD）为主，但是它们的现状依然是“人”驱动“IT”，相应地，研发数据是没有结构化的，如果智能化（AI）时代的到来，显然企业很难完成AI 转型的。正是综合考虑发展趋势，硬件产品数字化研发（硬件DevOps）是势在必行的。但是考虑到硬件DevOps 实施的挑战性，在硬件DevOps方案设计和实施策略就显得尤为重要。从另外一个角度来看，无论是提供硬件产品企业还是软件产品企业，都是通过“DevOps”实现数字化研发转型的。

2 软件DevOps和硬件DevOps业务模型

得益于三大主要数字化技术：流水线技术、微服务和容器技术，软件DevOps 思想付诸实践。图1是软件DevOps 业务模型和工具链示意图，可以看到软件DevOps 业务过程的经典哑铃模型，由计划、需求、开发、编译、测试、发布、部署、运维和监控组成。借助流水线技术和研发工具的结合，形成工具链，从而将过程任务代码化，实现过程自动化和闭环，进而形成持续迭代和持续交付能力。图1a 借助了敏捷思想，实现开发快速响应需求及其变更；图1b 是DevOps 的初衷，实现高质量的持续部署、运维。

为了便于比较，硬件DevOps 业务过程也按照哑铃模型设计，如图2可见，硬件研发过程由需求、开发、检查、仿真、试制、调试、测试、中试、量产、部署、运维、售后服务和监控组成。与软件业务过程主要不同有：

图1：软件DevOps 业务模型和工具链图

图2：硬件DevOps 业务模型

图3：硬件业务“公转”模型图

图4：硬件设计“自转”模型

（1）业务价值流更长，甚至需要第三方合作方参与协同，才可以完成既定研发目标；

（2）两个哑铃闭环模型中，硬件开发中的Dev 与软件开发中的Dev 是不同的，由于硬件开发是多学科开发，一个学科设计调整都可能影响到另外一个学科的设计，因此在硬件设计环节存在“自转”循环，如图2中a 所示，这一过程是完善与优化设计；

（3）图2中的三个箭头，右边两个箭头是不动的，需求和开发之间存在互动，比如说，设计因为技术瓶颈达不到预期，就可能需要调整产品需求；设计完成到检查环节的箭头也是不动的。而最左边箭头是可以动的，一旦移动到某个环节，发现需要修改设计，那么根据修改范围，可能需要从设计→检查→......重新开始业务循环，如图2中b 所示，即硬件业务过程存在围绕设计的“公转”循环；

（4）硬件业务开发过程存在虚拟迭代和实物迭代过程，所谓虚拟迭代是指产品设计通过仿真技术来评估产品的预期性能，一旦仿真结果达不到预期，需要优化设计；所谓实物迭代是指在试制、调试、测试等环节发现设计偏差后，需要重新优化设计，以满足预期的功能及性能指标要求。所以，硬件业务过程比软件业务过程复杂得多，在某种程度上，可以把软件业务过程看成硬件业务过程的简化版，即如长方体与正方体的关系。

为了更好理解硬件设计过程“公转”循环，设计了硬件业务过程的“公转”模型或者叫“雪人模型”，如图3。从检查、仿真之后的各个环节都可能重新触发新的迭代，越往后的业务过程因异常导致的设计迭代所付出的代价就越大，由此可见，硬件DevOps 需要重点实现：短迭代路径，如虚拟迭代（最左边两个循环就是虚拟迭代），甚至不迭代（通过提高一版投板成功率），来降低研发费用和缩短研发周期。

类似的，硬件设计“自转”循环模型如图4所示。由于硬件产品设计通常包括结构设计、工艺设计、硬件电气设计、部件设计、逻辑设计和底软设计等多学科的联合设计过程，而硬件电气设计还包括基带设计、射频设计、EDA设计和天线设计等。因此，除了需要硬件电气设计多学科协同循环设计外，还存在跨学科领域的协同开发。

由此可见，从业务模型的角度，可以看到硬件业务流和软件业务流是存在巨大的差异，也因此决定了硬件DevOps 的复杂性和建设成本与周期。

3 硬件DevOps架构设计

由于阿里云的“厚平台，轻应用”的技术架构能够为前台的一线业务提供更敏捷、更灵活的服务以适应瞬息万变的市场需求，而中台整合的运营数据能力、产品技术能力，对各前台业务形成强有力支撑，因此该技术架构更具创新性和灵活性，也同样适用于硬件DevOps的架构设计。

图5是硬件DevOps 中台分层架构模型，总体上采用了分层和分域相结合的策略。从分层的角度上来看，研发中台（硬件DevOps）服务对象包括硬件开发人员、客户（主要指内部业务流下游数字化制造等客户）、供应商、合作伙伴和子公司；前台由应用场景/活动、角色编排、接入层、角色化场景编排和业务应用层组成；中台则由角色化服务编排、扩展服务层、基础服务层、组件层和数据层组成，其中数据包括结构化的设计数据和管理数据；后台有PaaS 和IaaS 平台组成。而从系统服务对象，可以将整个架构分层硬件管理域（服务项目管理和产品经营等需要）、硬件工程域（直接服务工程设计与开发一线）和IaaS 平台三大部分。

硬件DevOps 分层模型中提到了几种编排，它们之间的关系如图6。通过几种编排器的组合应用，结合权限控制，生成与用户角色一致的业务流水线和工具流水线，给硬件产品开发与管理工作提供流程和工具支撑，也由此产生“IT”驱动“人”的核心作用。

结合硬件DevOps 业务模型、中台架构和分域策略，硬件DevOps 中台“域”模型如图7。用户通过硬件DevOps 门户接入硬件管理域，项目与交付管理是通过编排或者智能编排产生的角色化设计与管理应用界面，以满足项目管理和开发的需要，同时通过分布式服务或者应用来支撑角色化编排以及权限管理的。而硬件工程域是通过PaaS 平台、结构化数据管理和硬件平台、架构管理来支撑设计协同、仿真协同、工艺协同、测试协同和试制与发布协同的，通常硬件工程域更多的是提供开发工具自动化无缝链接来形成硬件产品开发中各学科的协同，因此，硬件工程域也叫做硬件工具链。

仅从硬件工具链中数字化设计来看，就牵涉到众多工具云化、设计一体化和工程数据结构化等大量工作，也牵涉到与之相匹配的基础设施的投资与建设，所以硬件DevOps 是一个极其复杂的系统工程，需要长期的投入，因此其本身建设也是DevOps 实践，是一个持续集成、持续迭代、持续发布与运维的过程。

4 硬件DevOps推进策略与原则

由于软件DevOps 已经有许多的成功实践，因此一些成功经验可以在硬件DevOps实施过程得到借鉴的，图8就是博时基金在2018年在China DevOps Day 展示其实践软件DevOps 的实施策略，其核心策略是：以提高工程工具效率为突破点采用自下而上搭建软件DevOps 体系与以管理、组织和考评为关键点自上而下为软件DevOps 提供管理资源支撑相结合，使得软件DevOps 实践取得了非常好的效果。

图5：硬件DevOps 中台分层模型图

图6：硬件DevOps 中台分层模型中的编排器

该策略在硬件DevOps 体系建设上同样适用的，从图5和图6硬件DevOps 架构模型可以看出，在中台架构的基础上进行了分域：管理域和工程域，也是为了将工程域作为硬件DevOps 建设突破点，确定了其优先级，比如说工程域中的仿真云、设计云等其核心作用就是为了提升工程工具效率的。另外，将硬件DevOps 拆成管理域和工程域也是组建硬件DevOps 研发团队的需要。考虑到整个体系的复杂性，建设之初需确定好阶段性研发重点和研发资源投放，是硬件DevOps 体系建设成功的基础。

其次，如前所述，硬件DevOps 体系建设本身是一次大规模的DevOps 实践，与软件DevOps 一样，也会用到工具云化、流水线编排器等等技术，但是由于硬件DevOps 更为复杂，在实施过程中需要对工程域或者管理域需要进一步进行拆分，以确定建设步骤，图9是硬件工程域建设步骤策略，只有这样，才能提高持续集成、持续发布和持续部署的效能，即让硬件DevOps 体系建设本身成为一次伟大的DevOps 实践，也是对软件DevOps 成效的一次检验！

再者，硬件DevOps 体系建设需要考虑快速变现，这也是为什么硬件DevOps 体系建设和软件DevOps 一样，选择提高工具效率为抓手。当然，硬件工具链牵涉学科众多，企业需要根据自身现状，选择影响当前研发业务最痛点作为突破点来启动硬件工具链建设。一旦相关领域取得突破，这将使得DevOps 文化从IT层面向工程一线推广，逐步深入人心。比如可以以仿真云作为试点，仿真云一旦建成，一方面解决了工作站或者单机版仿真作业慢的问题，仿真效率可以提升成倍提升；另外相应地提高了软硬件资产的使用效率，降低企业运营费用。如果能够将仿真前后处理与仿真计算结合，形成一体化仿真作业，使得仿真协同起来，形成合力，效能将进一步提升。

图7：硬件DevOps 中台域模型

另外，硬件DevOps 相对于传统研发模式来看，是一场革命，因此，需要赢得企业管理层自上而下的支持，特别是企业运营管理团队一把手的支持，包括资源支持和文化支持。与之配套的推进手段如指标、考核和激励等也是必不可少的。

硬件DevOps 体系（或者叫研发中台）建设要想取得好的效果，需要采用以上四个策略（（1）选取合适的突破点；（2）能够快速变现；（3）采用软件DevOps 开发、部署方法；（4）企业管理层支持）外，还需要遵循以下七个原则：

（1）复用原则：严禁各中心之间各种形式的重复开发，遵守One UI、One Logic、One Data 原则，这里的“中心”指的是如设计中心、仿真中心等；

（2）业务解耦原则：基础服务能力不能同层调用；

（3）数据解耦原则：每个中心独立数据库；

（4）高可用原则：每个中心实现高可用设计；

（5）标准化原则：每个中心符合分层模型定义、统一框架、规范、组件；

（6）自动化原则：每个中心UT 覆盖率＞60%，FT 覆盖率＞80%，ST 最小集覆盖率＞90%，该原则关注主要针对软件测试，确保业务上线质量；

（7）开放原则：中心服务默认在公司范围内开放。

5 结束语

对于完成数字化转型的企业，可以通过产品链路实现端到端数字化交付，如图10。从数字化研发角度，对于基于模型设计（MBD）的企业，通过它连接数字化营销，通过样机BOM 或者制造BOM 连接数字化制造，从而现成主业务流的协同与一体化，最后通过基于模型的结构化数据来与产品实物一一对应的。

另外，人工智能（AI）将离我们越来越近，它最终会融入到企业运营的方方面面，而影响AI 与企业运营结合的关键点就在于结构化数据。李开复在《AI·未来》一书中指出：正因为有了结构化数据，才可以很容易地将人工智能商用，帮助传统企业优化现有数据库，更好地识别欺诈、更明智地进行交易、发现供应链上缺乏效率的环节，使得企业进一步节约成本，利润最大化。由此可见，建设硬件DevOps 不仅仅是传统企业数字化转型的需要，更是为了迎接人工智能的到来所做的铺垫与准备，因此对于提供硬件产品的企业，没有数字化研发就会落后，甚至是没有未来的。

图8：博时基金软件DevOps 实施策略图

图9：硬件工程域实施策略

图10：数字化企业产品链路全景图