火箭首飞的软件复用事故 (Ariane 5)：一枚全新设计的火箭，为什么是被一段沿用旧型号的代码毁掉的？

# 商业复盘备忘录：火箭首飞的软件复用事故 (Ariane 5)

> 一枚全新设计的火箭，为什么是被一段沿用旧型号的代码毁掉的？
> 周期: 1996 | 行业: 新经济与出行
> 巅峰: 欧洲新一代大型运载火箭的首飞任务，承载多颗科研卫星，被视为欧洲航天发射能力的关键一步，项目投入巨大
> 终局: 首飞在升空数十秒后解体，火箭与载荷全部损失，事故原因被认定为沿用旧型号的软件在新飞行条件下触发数值异常

## 核心概览
复用的代码不是免费的：它的适用边界会随使用场景一起变化。巅峰期欧洲新一代大型运载火箭的首飞任务，承载多颗科研卫星，被视为欧洲航天发射能力的关键一步，项目投入巨大；终局是首飞在升空数十秒后解体，火箭与载荷全部损失，事故原因被认定为沿用旧型号的软件在新飞行条件下触发数值异常。

## 社区公投头号死因
1. [产品技术] 复用软件的适用边界未被重新评估 (1,576 票)
2. [组织管理] 主备计算机运行相同软件 (1,324 票)
3. [战略决策] 以「已验证」为由减少验证 (1,072 票)

## 可执行教训
### 复用代码时要重新验证「适用边界」，而不是验证「它以前能用」
> 把冗余系统的差异性作为设计原则，而不是成本项。

- ✅ 推荐做 (DOs):
  - 对复用组件重新评估输入范围与边界条件
  - 让冗余系统在实现上保持差异
- ❌ 绝不能做 (DON'Ts):
  - 不要用历史成功替代新场景验证
  - 不要让主备系统运行完全相同的软件

## 救亡方案
### 先重新界定复用组件的适用边界，再谈复用带来的成本节省 — 良略编辑部
干预时点: 1996 年首飞失败、事故报告确认软件复用问题后
- 必须断腕:
  - 停止以「验证过」为由跳过新场景测试
  - 停止让主备系统运行完全相同的软件
  - 停止把复用当作无风险的成本优化
- 破局动作:
  - 对复用组件逐项重估输入范围与边界
  - 让冗余系统在实现上保持差异
  - 为新场景补充针对性测试与防护
- 预期结果: 复用策略建立在重新验证的基础上，冗余设计具备真实差异。

## 社区见解
### 这段代码在旧火箭上飞了无数次都没出问题，原因是它的输出在新火箭上才第一次超出了取值范围。 — 良略编辑部 (工程师)
事故报告揭示的因果链非常清晰：软件里有一段负责把速度相关数值转换处理的逻辑，在旧型号的飞行剖面下，这个数值始终在安全范围内，因此不会触发异常；新火箭的加速更快，同一个数值超出了设计范围，处理逻辑失效并触发了错误状态，使计算机停止输出正确数据。更致命的是，主备两台计算机运行的是同一套软件，所以它们在同一个瞬间一起失效——冗余设计本应防住这种单点问题，但软件相同让冗余失去了意义。此后工程界对「复用」的态度发生了明显变化：复用可以，但必须重新界定它的适用边界。
- 如果重来一次的纠偏招式 冗余的意义在于「不一样」，一样的备份只是同一个错误的两个副本。

---
来源: 良略 · https://www.lianglue.com/c/ariane-5