如何突破嵌入式DevOps实施中的硬件掣肘？

百度百科中对DevOps的定义是，“一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。”它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例，透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

嵌入式DevOps的发展并非一蹴而就

根据Google DORA(DevOps、Research与Assessment)团队最新的《DevOps现状》报告，在DevOps方面成效不佳的团队很少能够在6个月内将软件投入生产运营。即便他们做到了，也会有16%-30%的失败率，而且他们很可能需要长达六个月的前导时间来让代码投入生产运营。就算变更不那么频繁，但某些事情发生变更带来的风险相对较高，而下一次更新可能又需要6个月的时间。

与此相比，精英团队的部署频率要高出973倍(基本上可以每天都可以根据需要进行多次更新)，从提交到部署的交付周期要快6570倍，从故障中恢复的时间更快，其变更失败的可能性要低30%。

失败意味着什么？根据IT软件质量联盟(CISQ，Consortium for IT Software Quality)2018年发布的报告，美国劣质软件的总成本为2.84万亿美元。平均而言，每个失败项目的成本大约是5000万美元。

这就是为什么企业，尤其是从事碎片化的嵌入式和物联网产品开发的企业，对DevOps的接受度越来越高的根本原因，因为DevOps可以大幅降低成本并提升效率。但嵌入式DevOps的发展也不是一蹴而就的，它经历了从传统开发、敏捷方法，到持续集成/持续部署，再到完整集成的DevSecOps四个阶段：

• 传统开发：传统开发方法将嵌入式DevOps分为三个流程。独立团队编写代码、整理代码以及测试代码。这在“瀑布式”软件开发方法中运行无碍，但是它的速度太慢，无法满足当今市场需求。

• 敏捷方法：这类方法为嵌入式DevOps提供了一种新的路径，可以更快速地发布新版软件代码。同时，这也是按照“DevOps”理念来整合不同流程和团队的第一步。

• 持续集成/持续部署(CI/CD)：随着团队能够以空前速度推出新代码，DevOps方法的迭代也在快速演进。在每次迭代中采用卸载/重新安装的方式已变得不切实际。然而，CI/CD方法可以使软件系统在不停止运行的情况下进行迭代演进。

• 完整集成的DevSecOps：随着开发团队越来越忙，以及新代码定期发布，系统的安全风险也在增加。DevOps现在的任务是将安全性作为团队工作流程中必不可少的组成部分。

坏消息和好消息

不过，尽管DevOps有着诸多好处，但并非所有人都愿意尝试，尤其是对嵌入式DevOps来说更是如此。与软件DevOps不同的是，嵌入式DevOps严重依赖硬件，随着电子系统变得越来越复杂，更多硬件的出现正成为嵌入式DevOps实施的瓶颈。

来自风河(Wind Rriver)公司的Jeff Gowan表示，当一家公司开始尝试DevOps时，往往都需要首先解决以下两点问题：一个是需要克服开发惯性，另外则是通过合理的ROI，解决管理层的预期。其次，如果您是从事智能边缘开发，如前文所述，那么硬件就会成为关键问题，但好消息则是模拟仿真可以解决这些问题！

Jeff Gowan详细解读了物理硬件可能给DevOps应用带来问题的四种方式及其应对方法：

• 开发生命周期瓶颈

如果某些硬件还没有上市，或是虽然已经上市但成本过高，这对设计团队的打击无疑是巨大的。Jeff Gowan将其形容为，“有点像您已经拥有了一辆豪华跑车，但它只能使用某种稀有的燃料油，但目前在任何地方都找不到。”寻找相似的代用品去满足正在开发的系统，也不是正确的方法，尤其是当面对工业机器人、飞机这样的关键应用设备时，它们对可靠性的要求之高超乎想象。

• 精度与速度

有些开发团队使用某种形式的模拟或仿真来解决缺少硬件部件的问题，试图在精度和速度之间找到平衡。但在Jeff Gowan看来，应用场景对仿真模型的精度有着特定的要求。例如，如果团队正在开发基于Intel的特定SoC芯片，但无法获得这款芯片，就可以在仿真x86系统上进行开发和测试，或者在相似设备上进行较普通的x86开发。开发人员可能会发现一些缺陷，或者错误地认为自己的设计是可靠的——但一旦能在真实的电路板上进行开发，很可能发现以前做的工作都白费了。

所以，他建议在开发早期就要拥有一套高度逼真的模型，并将其集成到DevOps流水线中，这才是更好的选择。换句话说，DevOps流水线中的仿真模拟越精确，开发人员对代码的信心就越高，软件发布准备也会更加完备。

• 无损测试

在不损坏实验室、不破坏实际设备的情况下，如何对虚拟设备进行反复的压力测试，甚至摧毁它以便发现所有漏洞？在这方面模拟仿真技术带来的好处非常明显。 

通过使用模拟仿真进行测试，可以扩展DevOps实践的价值，加快产品的认证速度，同时大幅削减硬件实验室的成本。通过采用预先模拟技术，设计人员几乎可以对无穷无尽的场景组合进行测试，测试的次数也几乎是无穷无尽。不需要更换硬件、重新布线或重新配置，只需直接点击重置、修改测试场景，然后再次执行即可。甚至可以在夜间将其设置为自动运行，然后在第二天早上登录观察运行结果。

• 多设备集群测试需求

显而易见，在一台设备上和在由几十台、几百台甚至上千台设备建立的实验环境中运行测试，是完全不同的两码事。Jeff Gowan举例说，有一家企业曾将所有测试设备连接到网络中，跨越公司的整个园区。虽然这是可以做到的，但是既痛苦又昂贵。因为必须购买所有设备，然后花时间让所有设备实现网络互连。即便设备不是散布于办公室的各个角落，而只是在一个实验室里，那同样会到处都是电线电缆。

“环境混乱是真正的挑战。”他表示，模拟仿真技术将是应对上述挑战的良策——不受任何限制，无论是一台设备还是1000台设备，一旦设置了环境，就可以很容易地添加其他设备并根据需要修改配置。而且，通过对所有模型进行模拟仿真，用户还可以更加频繁地进行测试，这有助于提高测试的信心，进而提高产品的质量。

“一招制敌”

Simics Simulation是风河推出的全系统模拟软件，从芯片到系统和网络，Simics均可模拟。Simics全系统模拟工具可以运行未经修改的目标软件，包括与硬件相同的bootloader、BIOS、固件、操作系统、板级支持包(BSP)、中间件和应用程序。通过将故障导入模拟系统，可以在安全可控的环境中测试安全威胁。-在真实的硬件可用之前，软件开发和测试人员就可以提前在simics的虚拟硬件上开展工作，并提前完成大部分的开发和测试。

“从一开始就采用高精度模型”是Simics的突出亮点之一。得益于此，用户无需等待供应商提供硬件，也免除了工程师因为没有硬件而等待的时间，可以立即开始工作，确保在项目截止日期前有足够的时间运行所需的全部测试。

与此同时，每项测试项目的更改，都会自动直接反馈到DevOps流水线中，从而允许用户根据需要随时进行部署。如果一个模拟模型被破坏了，只需按下按钮，就会立即重新创建起来。更有意义的是，可以自动设置并再次运行，方便用户直接查看结果。

考虑到系统的开发、调试、集成和测试过程中面临的最大困难就是有时候缺少目标硬件和物理实验室，因此开发团队只能退而求其次使用替代方案如评估板或基于PC主机的开发。有了Simics之后，这个问题就迎刃而解了——整个开发团队都能随时随地获得一个虚拟的实验室，而且是一个完整的系统而不是某个部分，这样每个开发人员都能基于整个系统来思考、设计方案与开发。

总体而言，通过提供物理硬件的虚拟替代方案，Simics支持试验、故障排除、共享、共同、测试和运行、开发、配置等七项完整的开发任务，大大提高了工程效率，降低了开发成本，使嵌入式敏捷开发成为可能。