如果要问，这几年的汽车行业里，什么增长最快？有一个答案是，“概念”。
概念实在是满天飞，似乎是没有几个新概念加持，大家讲话时，都不由得会羞红双脸。
DevOps是从IT飞过来的热点概念之一。同很多其他概念一样，我们耳熟能详，但似乎又很难准确描述出它是什么。
本文就致力于拆解这个DevOps，抽取其精华，并破除概念的遮蔽。此外，也初步寻找它在汽车行业里的位置。
1
DevOps的历史渊源
我们从两个维度来讲DevOps的渊源：
与汽车的渊源：从1950年开始发展的丰田精益的衍生。
与敏捷的渊源：从2001年开始发展的敏捷实践的延续。
DevOps这个名字则源自Patrick Debois于2009年在比利时发起的第一次DevOpsDays活动。
总体来说，在软件领域，DevOps与敏捷有着密不可分的关系和非常相近的原则。
当然，DevOps也有自己特定的增量或说强调的重点，继续往下看。
2
汽车与IT中的概念的差异
DevOps是由Development和Operation这两个词组成的，而它们也存在于汽车行业，但含义不同。
Development
在汽车行业，用Engineering会更贴切些，因为Development的内涵稍窄，主要侧重于描述预研类项目或者局部设计开发类领域，并不足以涵盖大多数工程活动。
IT的Development的范畴则会更大。我们可以从Engineering和Development这两个词的差异，体会到那一点行业差异的微妙。
Operation
汽车行业的Operation主要是用来描述工厂运营的，也就是SOP后的大批量生产及相关职能的总称，而当软件真正上车再到客户手里又是下一个阶段了。
DevOps中的Operaton更多是IT系统或产品部署到客户生产环境后运维的概念，此时，也已经正式给客户提供服务了，并不存在汽车出厂运输这种环节。
可见，这里的差异会更突出，二者完全不是一个维度的概念，汽车软件的运维意味并不明确，当前形势下也不够现实，所以，这里的差异几乎会一票否决在汽车行业里去实现DevOps最初的愿望。
当然，如果往长远预想，OTA足够成熟自由后，开发阶段的变更就能够及时持续体现在消费者车上，那样，才更接近IT DevOps的场景。
关于汽车与IT的差异，我在早期的一篇文章“软件和机械到底有何异同？”中的“软件工厂”部分有过简单的介绍，可以参考。
不过，两个行业在Operation阶段都追求稳定性倒是一致的。另外，我们也可以放大汽车行业Operation的范围，比如，将验收部门理解为Operation，而后去尝试适配DevOps的理念或实践。
概念梳理完毕后，我们就可以抛开偏见和盲从来看待DevOps。
3
DevOps的基本原则：三步工作法
这部分内容将构成DevOps的基本框架。
所谓三步工作法，既是有一定内在逻辑次序的工作步骤，也对应着三个工作原则，即流动原则、反馈原则和持续改进原则。
流动原则：从左到右，让工作从开发到运维快速地流动，强调快速向客户交付价值。
反馈原则：从右到左，让工作的表现快速反馈，强调快速获得客户对价值的反馈。
持续改进原则：从全局进行持续改进，强调系统性的优化。
下面我们会依次展开3个原则的一些具体内容。
4
第一步：流动原则
流动，像水一样流动。先抛开实际场景，我们尝试从这种意象感中寻找让工作流动的方法。
4.1 工作放到桌面上
为了能够知道工作堵塞在什么地方，就需要把工作从桌子底下拿上来，精心撰写的ppt是不可能反映真实现场的，比如，看板、共享数据存储区、质量评审等。
4.2 让员工安心工作
为了让工作效率持续，要保证价值增值人员（比如，开发）不受干扰地完成工作，避免多任务切换，避免某些领导或职能为了刷存在感或自我成长而让员工频繁汇报。
4.3 有成果就赶紧交付
对于软件开发，最典型的就是代码，及时提交，daily构建。
4.4 减少沟通接口
组织庞大后，为了分工精细和流程标准化，难以避免地会增加更多的接口，多手信息会不断传递。
最好是用自动化的手段去覆盖人工接口，这样还可以保留分工的收益。
4.5 消除浪费
这个概念在精益里提得非常多。比较典型的有手工操作、数据传输延迟、资源不足导致的等待以及几乎不会有第二个人看的文档等。
4.4 自由搭建环境
对于IT而言，这里会有开发环境、测试环境与（类）生产环境，如果环境能够快速搭建且数量充裕，开发、测试、运维自然是更快速通畅。
对于汽车行业来说，生产环境的障碍主要集中在周边件成熟的实车，由于实车成本高昂以及多模块协同困难，环境的获取是个巨大瓶颈。
短期内，可以尝试的是提升台架的真实性；长期看，或可建立云端环境，这样就能够快速获取并更新交互模块的最新软件。
总之，整车环境的快速搭建应作为车厂的核心优化点。
此外，汽车软件环境还包含另外一环，就是终端客户对软件的评价，也就是从终端客户视角的实际用车环境里评价软件。
我们可能没有办法把真正买车的客户引进来，但可以提前把开发版本发布给内部类似职能团队，比如，后道的质量或体验团队。从这里我们也可以引出另外一个车厂关键优化点，整合验收资源。
4.5 统一代码仓库
为了最大程度降低生产环境出问题的风险，可以应用统一的代码仓库，将所有代码、库、脚本、配置文件等都纳入软件版本管理系统，以便能够快速准确地恢复生产环境。此外，通常对于生产环境的任何变更，都要通过软件版本管理系统处理，而非手动。
实际上，这一部分理念不太适用于汽车软件，但给我们的启发是，OTA失败后，如何快速恢复。
4.6 持续构建集成和自动化测试
CICD已经比较广泛地应用在了汽车软件行业，比如，常用的Jenkins、GitLab CI等。以及，自动化测试工具自动化地完成静态扫描、单元测试、集成测试等。
在这里，很关键的一点是，基于乃至后续验收测试的问题，去不断完善早期自动化测试的用例和脚本，以让其尽可能提前识别问题。
不过，汽车软件的多层次、多职能测试是一个障碍，目前还局限在模块级的早期开发阶段。
5
第二步：反馈原则
除了下游的反馈，这里也关注终端客户的反馈，也就是所谓的生产环境的运维环节。
对应地，可以总结为两个要素：
快速、频繁地获取下游客户的工作反馈，以保证开发及时调整。
快速、频繁地获取生产环境的表现，以保证系统安全可靠。
据此，我们来总结相关的方法与实践。
5.1 建立监控机制
通常，我们要建立全面的监控系统，监控各个环节的数据表现与日志记录等，一旦生产环境发生意外，能够第一时间识别。
对于这一点，汽车行业也不太明显，产品本身功能安全设计中的嵌套诊断监控倒是有类似的意味，但它暂时无法反馈到企业的运维部门。
现在，我们期望通过层层审批来获取反馈，通过各种KPI来监控表现，但仍然流于形式和漫长等待的居多。
我们需要思考，如何搭建反映真实开发现场的指标体系？如何建立反映终端客户状态的数据埋点机制？
5.2 应用A/B测试
这种思路更多适用于用户体验的开发中，比如，在网站或app开发中，将控制组A和实验组B两个版本推送给不同的用户群，然后基于不同用户的反馈，来判断两个版本的优劣。
类似地，这在汽车行业也暂时没看到实现路径，大规模用户的互联网环境和一人一车的用车环境不能类比。
5.3 代码评审
各类领导评审已经不鲜见了，而其带来的弊端，正是我们要解决的，暂且不论。
在各种评审中，代码评审是个平民化的、非官僚的，但又颇为奏效的手段。常见的实践有，结对编程、代码工具门禁、会议评审或邮件评审等。
6
第三步：持续改进原则
在前两步的交付与反馈中，我们得到了产品，完成了业务。
这一步更多集中在最容易被人忽视的地带——改进上。
改进也包含两个层面：人与产品。前者侧重于人的能力和责任意识的提升，后者侧重于组织、流程、基础设施及产品的架构优化。
这里必然要以务虚的文化作为起步，但我们又不想谈文化，因为文化是所有人都知道且认同，但又不知所云或不以为然的东西。文字解决不了这种问题。
简单提两点实践。
6.1 使用全员共享的数据库（含代码库）
改进的前提是让人知道，不知道的话，既无动力，又无能力。这和前面所讲的“工作放在桌面上”殊途同归，既然文化宣贯没用，不如从技术手段限制私藏私控数据与信息的行径。
6.2 清理技术债务
不完备的文档、复杂的系统架构、诡异的产品逻辑、屎山代码，这都是技术债务，要及时清理。
这个道理人人都懂，这也是是所谓的重要但不紧急的事。
手段上，可以设定强制的清理技术债务时间段，这个时间段不允许进行功能开发。这种方式在我以前经历的一家精益工厂见到过类似场景，生产线是不允许班组长干活超过工作时长的30%的，他们要致力于班组与产线这个系统的管理和优化。
7
写在最后
大体上，汽车行业可以这么看待DevOps。
DevOps致力于融合开发和运维来持续向终端客户交付价值。
车载软件没有DevOps里的Ops，没有运维。
DevOps比较适合汽车软件工具链的开发。
DevOps是另外一个更大的概念——敏捷的一部分。
敏捷来源于精益，那些满是油污的汽车工厂可能并不代表落后。
精益也是一个包罗万象的概念集合。
历史的方法解决不了未来的问题，跨行的方法也解决不了本行的问题。
太阳底下没有新鲜事，所有这些概念都在重复讲类似的事情。
重点学习概念背后的基础原则、基本方法、单体工具与良好实践。
所以，不要纠结了各种概念本身，不必强调我们在走什么体系框架。
跨越式解决问题的核心仍然是技术，比如，工具链和自动化测试。
空杯、往外看，并聚焦于自己的业务。
完
