《ELC：SpaceX的经验教训》中文翻译与自己的一些见解

原文地址：英文版地址，作者作者Jake Edge，发表于2013年3月6日。
文中灰色背景的是我的一些不成熟的看法，部分数据和资料来源于网络和相关论文，由于是非正式发表，也就不标注来源了，有兴趣的朋友可以自行查证，欢迎留言讨论。

在2013年嵌入式Linux大会的第二天，SpaceX的罗伯特·罗斯（Robert Rose）谈到了“从经验中学到的航天器开发软件”。在演讲中，他讨论了SpaceX如何开发其基于Linux的软件，以完成将航天器送入轨道甚至最终超越轨道所需的各种任务。他说，Linux在SpaceX上无处不在，从台式机到航天器，应有尽有。

Rose是SpaceX航空电子飞行软件团队的负责人。他曾是一名视频游戏程序员，并说从这项工作中获得的一些教训对他目前的工作很有价值。他于1994年通过Slackware开始使用Linux。

作为一家公司，SpaceX坚信要使人类成为多行星物种。他说，火星殖民地是目标，但要到达那里，就需要火箭和宇宙飞船。目前发射航天器很昂贵，因此有必要“降低成本”以达到目标。

这里说明了SpaceX的公司愿景，并将公司愿景通过分解，让程序员了解到了公司愿景，公司愿景通过分解落实到的部门愿景，以及和每个人工作的联系。很多伟大的公司都设立了很明确的公司愿景，并将每一个员工的工作与公司愿景相连接，从而增强员工的归属感和责任感。

Rose说，该公司遵循可重用性的理念，这有助于降低成本。航天飞机计划已经对此进行了一定程度的尝试，但是SpaceX对此进行了进一步的研究。不仅硬件组件可以在不同的航天器之间重复使用，而且软件也可以共享。该公司在自己的工厂从头开始制造火箭，而不是外包各种碎片。这样可以更紧密，更频繁地进行硬件-软件集成。

复用的重要性，复用的前提是在总体设计中充分的解耦，将总体分解成一个一个的模块，并对模块进行充分的测试与评估，并制定完整准确的模块使用说明，才能让模块真正成为资产。这一点其实非常难以达到，一方面需要总体设计人员的水平很高，这样才能充分的解耦；另一方面还需要对模块资产有充分的掌握，才能在总体设计中充分利用现有资源；此外，还需要员工有较高的学习热情，才能在最终实现中利用模块而不是重新造轮子。

Rose在SpaceX的早期发现很难适应的一件事是该公司对“最终目标”的关注。在做出决定时，人们经常会提出来：“这对火星任务有用吗？” 在做出决定时总是要考虑这个问题。他说，火星并不总是赢家，但是人们总是会检查这种担忧。

资源和员工精力的集中能极大的提升效率，这一点在敏捷的Scrum方法中也被作为重点进行说明。管理学中的一些统计数据也表明，即使是只占员工精力和时间不足10%的琐碎工作，也会造成至少30%以上的工作效率损失。（个人认为这一点在编程工作中损失更大，可能会在50%以上，而且增加出现Bug的几率）。

挑战性

公司面临的一些挑战是极端的，因为涉及人员和财产安全。飞船是危险的飞行器，例如，如果其燃料爆炸，可能会造成严重损害。没有“撤销”，没有第二次机会把事情做好。一旦火箭发射“它就飞走了”。在开始从事该行业之前，他没有遇到的另一个问题是太空辐射的影响，这种辐射会“随机翻转”位，这是系统设计需要考虑的问题。

看过另一篇报道说明了SpaceX是如何通过多个商用CPU共同运算，因为被随即反转的CPU（内存数据）毕竟是少数，因此可以通过设置多个CPU共同运算，少数服从多数的选择方法实现系统的可靠性。毕竟航天级器件几片芯片的价钱，普通的CPU能买一车了。但是需要注意的是，这些协同处理也是需要底层程序的支持的。

罗斯说，SpaceX与其他行业共同面临的挑战要少一些。例如，处理专有硬件和与开发平台不同的目标平台是嵌入式Linux面临的挑战。另外，SpaceX团队不得不面对一个普遍的问题，即“软件之外的任何人都不了解软件”。

Linux并不是SpaceX在龙式上唯一采用的软件系统，其飞船平台上采用的是Linux，编程语言是C和C++。他们针对自己的研发过程，专门写了一套自己的研发管理系统，主要用到了C#（windows?)/MVC4/EF/SQL/Javascript/Knockout/Handlebars/LESS/REST API。地面系统由于可靠性要求相对不高，因此采用了LabView。（我一直认为LabView是儿童玩具而拒绝在工程中使用，仅在实验系统中用于系统原型搭建，看来是小看LabView了）他们还有一套自己的航电测试团队和硬件工程师一起完成测试。其人数最多的是飞船上的软件开发人员，有35人，地面团队只有9人（2013年的人数，这个开发效率和能力吓死我了）。

SpaceX从Falcon火箭开始，最终将航空电子代码转换为Dragon飞船。共享代码的明显优势是，在一个平台上修复的错误会在另一个平台上自动修复。但是，对运载火箭和航天器的软件要求有所不同，很大程度上与可用的不同反应时间有关。只要航天器不在国际空间站（ISS）的250米以内，就可能需要一些时间来解决任何问题。对于火箭来说，这种奢侈是无法获得的。它必须在短时间内做出反应。

我认为，需要注意的是，共享代码库需要有良好的质量控制，否则可能带来很大的质量隐患，特别是在后期，型号增多，模块增多，维护会越来越困难。这方面的资料还没有收集到，不知道他们是怎样管理的。

误报是一个需要考虑的问题。罗斯提到了水星6号任务（美国首次载人轨道飞行）的隔热屏指示器，该指示器表明隔热屏已分离。美国宇航局试图找到一种没有隔热罩的再次进入的方法，但“最终还是成功了”。事实证明这是一个误报。同样，运载火箭和航天器的可反应时间不同。

收集数据

罗斯 引用弗雷德·布鲁克斯（Fred Brooks，《神话人月》的成名作），称“软件是隐形的”。他说，要使软件更清晰可见，您需要知道它在做什么，这意味着在“您能想到的一切上创建度量”。对于火箭，您不能仅通过JTAG进行连接并“启动gdb”，因此该软件需要跟踪其运行情况。这些指标应涵盖性能，网络利用率，CPU负载等领域。

他说，无论是从测试还是在实际使用中收集的指标，都应该存储起来，因为它“非常有价值”，可以追溯到它们。对于他的系统，遥测数据与程序度量标准一起存储，所有正在运行的代码的版本也是如此，以便在需要时可以重现所有内容。

我所见到的系统大多数也有收集，但很少有设计的这么细的，我觉得这一点值得所有系统设计人员考虑借鉴。当然，应该辅以历史回放与分析工具。我觉得这也是该公司能够快速发现问题并进行迭代的基础之一。

SpaceX的程序可以解析度量标准数据，并在“情况恶化”时发出警报。Rose说，实现这一点很重要，因为强迫一个人这样做“会很烂”。无论是从开发人员的测试，从航天器的运行还是从任务生成的数据，这些程序都可以运行相同的程序。任何失败都应被视为添加新指标的机会。这样做需要一段时间才能“融入节奏”，但“非常有用”。他喜欢使用libSegFault和ftrace之类的工具“监视错误报告”。

Rose说，自动化很重要，持续集成“非常有价值”。他建议始终为每个平台构建，甚至为“您不再使用的东西”构建。SpaceX做到了这一点，并且在构建未使用的代码时发现了有趣的问题。每当代码更改时，单元测试就从连续集成系统运行。他开玩笑说：“这里的每个人都有100％的单元测试覆盖率”，但是运行任何可用的测试并创建新的测试都是有用的。当他从事电子游戏时，他们进行了一项测试，可以将角色“扭曲”到某个水平的随机位置，并使其在四个方向上观察，这通常会发现问题。

他说：“实现流程自动化”。应该自动完成诸如编码标准，静态分析，空格与制表符或检测Emacs之类的事情。SpaceX的过程很复杂，没有票证，代码审查，签收等操作就无法进行更改，但是所有这些操作都会自动检查。如果静态分析是工作流的一部分，请确保静态分析不会生成，除非该代码通过了该分析步骤。

自动化很重要，持续集成很重要，自动化测试也很重要，自动化的流程管理与控制也很重要。这一点前段时间CMMI专家丛斌博士在线上答疑的时候也着重强调过，国内在这一块做的还很差，涉及多方面的原因，这里不做过多阐述了。

当构建失败时，它应该“大声地失败”，并带有“开始闪烁红色的监视器”，并通过电子邮件发送给团队中的每个人。发生这种情况时，您应该“立即响应”以解决问题。在他的团队中，他们有一个全尺寸的贾斯汀·比伯（Justin Bieber）抠图，放置在面对破坏构造的团队成员面前。他们发现“ 100％的软件工程师不喜欢Justin Bieber”，他们将迅速解决构建问题。

构建失败的措施，这一点应该是源自于丰田的生产线管理中的质量控制措施。justin照片这个方法不错，不过估计放一张justin的照片效果不好，他太帅，在国内，可以考虑放一张如花或者乔碧螺的大幅照片。

项目管理

在向经理过渡的过程中，罗斯不得不学会担心与以往不同的事情。他指出了“ 每个程序员都应该知道的97件事 ”中的“ 使看不见的东西更加可见 ”一文，将其作为灵感的来源。对于硬件，很明显它的集成状态是什么，因为您可以查看并看到它，但是对于软件而言并非如此。没有“软件开发没有进度条”。这导致他的团队尝试使用不同的方法来尝试进行项目规划。

各种“现成的”项目管理方法和方法估计项目将花费多长时间对于他的团队来说是行不通的。Rose说，设置适合您的人员和任务集的内容非常重要。他们尝试了各种技术来估算时间需求，从宽带delphi到基于证据的调度并发现没有一种技术本身可以很好地适用于该小组。他说，由于他们是软件工程师，因此“我们编写了自己的工具”，这是几种不同技术的混合。没有用于计划的“灵丹妙药”，而且“不太可能您采用我们的方法并将其应用”到您的域。他学到的一个难听的教训是，一旦您使用一种特定的调度方法取得了成功，您就“需要完成销售工作”以向工程师展示它的工作原理。下次，它将使它变得更好，因为会有更多的支持。

软件的计划制定与管理，在国内外都是个难题。每日站会和看板，能够让计划的追踪有依据，其数据可以作为计划调整的输入，从而实现计划的动态调整。我相信SpaceX也是应该这样做的。（如果谁有相关参考资料，麻烦赐教啊）

一些技术细节
在SpaceX，Linux用于所有事物。Falcon，Dragon和Grasshopper车辆使用它进行飞行控制，地面站运行Linux，开发人员的桌面也使用Linux。他说，SpaceX是“ Linux，Linux，Linux”。

罗斯继续简要描述了Dragon飞行系统，尽管他说他不能提供太多细节。它是一个容错系统，可以满足NASA接近ISS的要求。关于规则，即航空器需要能够容忍多少故障并仍允许其接近该站点，存在一些规则。它使用三重冗余计算机来达到所需的容错级别。当三个计算机数据不一致时，将采用拜占庭将军的算法（ Byzantine generals’ algorithm）来处理。例如，可能由于辐射事件更改内存或寄存器值而发生这种情况。

对于导航，Dragon使用从ISS接收到的位置信息以及它自己计算的GPS数据。当它接近站点时，它使用ISS的图像和站点的相对大小来计算到站点的距离。由于可能处于黑暗中，Dragon使用了热成像技术，因为测站的温度略高于背景温度。

他的团队不使用“现成的发行版内核”。相反，他们花费大量时间评估内核的需求。他们关注的领域之一是调度程序性能。他说，它们没有严格的实时要求，但确实关心唤醒延迟。他们使用一些测试来量化调度程序在不同情况下的性能，例如在对网络施加压力的情况下。一旦选择了内核，“我们将尽量不对其进行更改”。

这也就是为什么采用匪夷所思的非实时操作系统Linux，而不是实时操作系统VxWorks或者其他航天用的系统。因为即使是非实时的系统，其相关时延参数也基本摸透了。而且我相信，在实时性要求很高的情况下，很有可能采用了针对硬件的底层操作。关于这一点，我想如果没有很高的设计能力，最好不要这样做，因为这样设计如果没有强大的技术实力，其风险其实很高。就如济公大师所说的：“酒肉穿肠过，佛祖心中留。世人若学我，如同进魔道。”

罗斯说，他们使用的开发工具“极为复杂”。他们使用GCC和gdb，而在编辑器和开发环境方面“每个人都做自己的事”。开发始终以Linux为目标，但开发人员并不总是以其为台式机，因此他们还开发了许多基于POSIX的工具。切换到Linux桌面的主要原因是“开箱即用”的开发工具，例如ftrace，gdb（可以直接连接到调试目标平台），netfilter和iptables。

Rose为大型和复杂的嵌入式Linux环境的软件开发提供了有趣的观点。此外，他的演讲比我们之前介绍的SpaceX演讲更为公开，很高兴看到。该公司使用的许多技术对于大多数程序员来说都是熟悉的，这清楚地表明，为航天器创建代码的过程并非完全是火箭科学。