美空军凯塞尔航线软件工厂的软件现代化实践

“美空军要在21世纪突破机载软件工作方式的界限，为军种开辟出新的，道路并使软件日益成为制胜优势的来源”。——2019年，时任美空军采办、技术与后勤助理部长威尔·罗珀。

根据美空军2022年6月透露的消息，在俄乌冲突期间，位于德国拉姆施泰因空军基地的第603空中作战中心部署了“凯塞尔航线全域作战套件”（KRADOS，Kessel Run All-Domain Operations Suite），作战中心利用其实时计划和空军任务周期自动化能力，并每天使用该软件向空军领导曾做空袭计划简报。

一、什么是“凯塞尔航线全域作战套件”

“凯塞尔航线全域作战套件”是美空军凯塞尔航线软件工厂预算授权占比最大的软件项目。据报道，凯塞尔航线计划在2022年上半年完成该软件的第一个最低可行能力版本（MVCR1），这个版本的目标是取代在卡塔尔乌代德空军基地美空军第609 空中作战中心的战区战斗管理核心系统（TBMCS）软件。（注：TBMCS战区战斗管理核心系统由洛克希德·马丁公司开发，2000年在空军战役管理中得到应用，为空军指挥官提供空战计划、以及指挥和控制空战任务的能力。）

根据最近的消息，“凯塞尔航线全域作战套件”集成了10个应用程序。其中被媒体提到的有4个：

——“闪击”（Slapshot，命名来自曲棍球运动）：空战任务计划和管理工具；

——“拼图”（Jigsaw，命名来自漫威漫画）：加油计划和管理工具；

——“格架”（Spacer）：空域管理工具；

——“麦太”（MaiTai）：安全数据查阅工具。

二、关于凯塞尔航线软件工厂

凯塞尔航线软件工厂于2017年就开始运行，其命名来自美国科幻“星球大战”。然而，直到2022年2月，美国防部发布《国防部软件现代化战略》才明确美国军方“建立美国防部全部门的软件工厂生态系统”的愿景目标，这时，美空军已经建设了18个软件工厂（参考文章：于无声处听惊雷！美空军部已建立17家软件工厂）。可以说，在美国防部软件现代化方面，美空军和凯塞尔航线走在了前面。

凯塞尔航线软件工厂的标志，下面写着“代码、部署、成功”（美空军图片）

凯塞尔航线的正式名称是美空军寿命周期管理中心第12支队，是美空军首个软件工厂。“凯塞尔航线全域作战套件”是该软件工厂最重要的软件项目。“凯塞尔航线”的名称取自星球大战系列故事，寓意为通过高科技捷径达到目的。该软件工厂希望快速提高空军软件开发、采购和装备速度，通过敏捷原则将长达数年的时间线缩短到几个月，并在过程中节省资金。

星球大战系列故事中，由于阿卡德漩涡内部环境复杂危险，一般飞船在前往凯塞尔星时无法依靠超空间跃迁直接抵达，而必须沿着相对安全但复杂的航线进行多次短距离跃迁。故事中，汉·索罗驾驶千年隼号从凯塞尔星出发，通过高水平的技术，以12秒差距（距离单位，1秒差距约为3.26光年）的一次超时空跃迁横穿阿卡德漩涡，打破了长久以来的航线飞行记录（美空军图片）

作为美空军的第一个软件工厂，凯塞尔航线是如何组建的呢？2017年国防创新部门（DIU）投资了100万美元开发Jigsaw数字化加油规划软件，以解决美空军空中作战中心使用Excel+白板的规划方式带来的低效、不可靠等问题。项目团队仅用了四个月的时间就基本完成Jigsaw的开发，在部署后的六个月内就因为效率的提高而收回了成本。美国防部和空军为了继承该项目取得的经验，以项目人员和其他软件现代化政府团队为基础，组建了凯塞尔航线软件工厂。

美国防部国防创新委员会（DIB）前往卡塔尔乌代德空军基地的一个作战中心调研时，看到当时美空军加油规划的工作模式，一名军官将数据输入Excel，另一名军官在白板上做标记（美空军图片）

三、凯塞尔航线的运行模式

1、以用户为中心

在最早开发Jigsaw加油规划软件时，项目团队就和空中作战中心的用户一起交流软件需求和价值，以及提高效率的途径。之后也采用了持续和客户交流协作的方法——在开发“凯塞尔航线全域作战套件”中，凯塞尔航线项目团队和美空军第609空中作战中心一直保持密切合作。

凯塞尔航线采用敏捷开发模式，这允许用户新增或者调整软件需求，并周期性更新需求和功能的优先级。在软件设计和研发过程中，凯塞尔航线团队也采用了与用户持续交流的模式，组建了研发-用户联合团队，明确应用程序和工作流程的交互关系。凯塞尔航线建设软件项目的初期目标不是提供原型，而是建设用户可以测试并用于支持作战的最小可行产品（MVP），之后的让用户参与测试，以启动开发、测试、学习的循环迭代，建立用户持续参与的机制。

这与按早期需求向用户提供最终系统的传统软件项目非常不同。因为软件建设方明确知道一个阶段发布的软件版本不能满足全部需求，但可以随着时间不断更新提高软件应用价值。在实践中，持续交付意味着对软件的定期更改，甚至可以达到每天多次，最终随着时间的推移积累产生重大变化。

例如，2019 年 12 月，卡塔尔乌代德空军基地的联合航空航天作战中心开始使用独立应用程序Jigsaw和Slapshot进行空中加油规划管理和作战任务规划管理。这两个应用作为独立程序使用了一年多，并没有集成到一个通用数据层中。到了2021年1月，“凯塞尔航线全域作战套件”的最小可行产品（MVP）发布，采用了通用数据层，集成了包括Jigsaw和Slapshot在内的 10 个应用程序。2021 年 5 月，联合航空航天作战中心开始使用该套件开展主要空中任务规划管理。

2017年国防创新部门（DIU）投资了100万美元开发Jigsaw数字化加油规划软件，以解决美空军空中作战中心使用Excel+白板的规划方式带来的低效、不可靠等问题。解决形成的初始软件如上图所示，该软件在美国中央司令部试用，大幅提高了空中加油效率。读者可将此图界面与上图白板操作对比（美空军图片）

2、持续更新和交付

凯塞尔航线还面临与商业软件不同的问题。军用软件需要支持10 个不同的环境，因为用户在非密、秘密和机密网络上，不同的盟友还使用这些网络的不同分支。

为了完成面向用户的软件部署、版本维护，并减少部署过程中的人为因素，软件工厂采用自动化的持续集成和持续部署管道技术。

其中的开发管道基于GitLab仓库平台，当开发团队确认更新完成后，会通过持续集成管道来推送代码和依赖软件。持续集成管道中包含安全发布功能，包括代码扫描、依赖检查，同时使用Nexus仓库进行存储。这样，就可以执行与其他应用程序和服务联合的集成测试和验证。

完成测试和验证后，就可以启动面向生产环境的部署。测试完成的软件镜像会从Nexus仓库移动到专门的部署管理器 （RADD），以实现生产环境部署。持续部署管道的具体操作取决于部署目标环境，如亚马逊非密云（AWS unclassified cloud）、本地秘密云（on-prem Secret cloud）还是机密云（Top Secret cloud）。

软件工厂频繁使用这些管道来开展持续集成和持续部署。凯塞尔航线的团队平均每3.3小时通过管道部署一次代码。从开发团队准备部署起，平均只需要8小时，就能完成开发环境到生产环境的部署。相比而言，将软件从非密网络转移到秘密网络中所需的时间更多，因为需要刻录光盘并进行检查扫描等人为工作。

3、基于DevSecOps实践敏捷开发和持续跟踪

这套持续创新和交付的敏捷开发框架就是“开发、安全运维一体化”（DevSecOps），也是美国防部主要推荐的敏捷开发框架。

DevSecOps由一系列方法、流程和技术组件构成，技术部分已经被美国防部和空军集成到面向软件项目的一号平台（Platform One）产品中。DevSecOps能够帮助开发人员在开发过程中更早地识别漏洞并降低风险。遵循DevSecOps流程可确保构建的内容具有充足的安全性并符合行业标准规范。开发过程使用持续集成和持续交付（CICD）管道。一旦在开发工作在该管道中完成测试，就会作为持续集成和持续交付管道的一部分进行安全扫描。

美空军在软件“开发之星”（DevStar）活动中采用的“开发、安全和运维一体化”敏捷软件开发流程（美空军图片）

传统开发团队在软件投入生产环境运行后，就认为开发工作已经完成。但对采用敏捷开发实践的软件工厂来说，即使软件部署在生产环境后，开发工作也还是处在进行时。凯塞尔航线软件工厂一直采取持续跟踪、持续响应的模式，不断跟踪生产环境中的应用程序，并解决使用中遇到的问题。除采用安全方式监控应用程序确保其可用性外，凯塞尔航线平均能够在 120 分钟内解决软件问题。并会在事后进行无故障追溯，以确定从根本上解决问题。无论从哪方面看，这都是一个相当专业的软件研发机构。

最近的典型案例，是解决从阿富汗喀布尔的哈米德卡尔扎伊国际机场撤离任务中，第609空中作战中心遇到的软件问题。因为撤离和疏散工作中的任务数量大幅增长，导致软件无法持续正常运行。凯塞尔航线团队在空中作战中心报告软件问题的12个小时内，将计算和存储资源转移到美国中央司令部的相关平台上，同时采取措施提高性能、修复 SQL 数据库连接错误、清理 bin 文件、添加新功能、对数据进行分片、改善软件负载。最终在一天内提出解决方案，并彻底解决了问题。

截至2022年1月，美空军17家软件工厂和“一号平台”在美国大陆的分布。至2月又增“奥丁”厂，总数达18家（美空军图片）

四、一点看法

可以说，以凯塞尔航线为代表的软件工厂是美空军上一波软件采办领导团队的遗产，尤其受到柴兰、罗珀、邓拉普等技术官僚的作用和影响。军用软件存在硬件研制周期长、软件技术更新快的矛盾问题，同时又长期面临进度慢、成本高、功能不可控等疑难。大范围设立软件工厂等政府开发团队，全面采用以用户为中心的思想、推进基于DevSecOps的敏捷开发模式，以实现持续更新和交付的目标。如此大范围的动作和决策，即使放在软件行业，也是极大胆的创新实践，但这一创新实践却是很有可能对症了。