单位换算错误毁掉探测器 (Mars Climate Orbiter):一枚飞行了几亿公里的探测器,为什么毁在了一次单位换算上?
最廉价的技术错误,往往造成最昂贵的后果
单位换算错误毁掉探测器 (Mars Climate Orbiter):巅峰期美国航天机构的火星气候探测任务,目标是研究火星大气与水循环,探测器经过长期飞行抵达火星,项目投入数亿美元;终局是探测器在进入火星轨道阶段失联,调查确认导航软件的单位换算不一致,导致轨道计算错误,探测器进入大气后损毁。
美国航天机构的火星气候探测任务,目标是研究火星大气与水循环,探测器经过长期飞行抵达火星,项目投入数亿美元
探测器在进入火星轨道阶段失联,调查确认导航软件的单位换算不一致,导致轨道计算错误,探测器进入大气后损毁
4,028 票参与
1 方案 · 1 见解
投稿会先进入待审,通过后才进入公开目录和站点地图。
核心败因全民归因公投
投票选择您认为导致该企业/项目最终死亡的最核心死穴,认同即可实时投票计入权重
接口定义缺少单位强制校验
关键物理量的量纲在跨方传递时未被复核
跨机构协作缺少统一标准
双方沿用各自惯用单位与流程,未在合同中统一约定
内部疑问未被升级处理
工程师提出的异常未按风险流程上报,错失纠偏机会
数亿美元投入随任务失败归零
载荷与探测器损失,后续任务的安排与预算受到影响
时间线:从高峰到终局
探测器抵达火星前
探测器完成长时间飞行接近火星,轨道调整按计划进行,但轨道数值出现无法解释的偏差
工程师提出疑问
有工程师对轨道计算数值提出疑问并发出提醒,但问题未被升级为正式风险处理
进入轨道阶段失联
探测器在轨道插入阶段失联,任务失败,调查随即展开
调查结论公布
调查认定导航软件单位不一致导致轨道计算错误,接口验证与复核流程存在明显缺失
四大维度全景复盘剖析
发展背景与全盛期基石
探测器由一方制造、另一方负责导航与任务控制,双方团队各自沿用惯用单位与流程;接口规范中对关键物理量的单位定义缺少强制校验,数据在传递过程中无人复核其量纲,且任务期间已有工程师对轨道数值提出过疑问但未被升级处理巅峰期的成绩单是:美国航天机构的火星气候探测任务,目标是研究火星大气与水循环,探测器经过长期飞行抵达火星,项目投入数亿美元。此时的它拥有渠道、品牌与资本的合力,看起来没有任何理由会输。
致命转折点的战略误判
导航团队使用的一方数据以英制单位计算推力,而任务方按公制解读,导致轨道预测出现系统性偏差;探测器在接近火星时轨道高度远低于预期,进入大气后损毁,任务失败,直接损失数亿美元,后续调查把责任归因于接口与验证流程的缺失早期为了速度堆起来的技术债没有及时偿还,等到业务规模翻倍,系统已经无法支撑新场景,重构又意味着停掉增长,只能一路将就。
内部组织文化与盲目傲慢
工程团队疲于救火与打补丁,优秀工程师流失,剩下的人只能用更低效的方式维持系统运转,形成恶性循环。
轰然倒塌的崩盘推演
探测器在进入火星轨道阶段失联,调查确认导航软件的单位换算不一致,导致轨道计算错误,探测器进入大气后损毁。单位换算错误毁掉探测器 (Mars Climate Orbiter)的结局不是某一次意外,而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
商业落地避坑实操法则
以血淋淋的商业代价淬炼出的创业与经营行动准则(DOs & DONTs)
跨团队接口要对「单位、精度、范围」做强制校验
把量纲检查写进流程,而不是依赖人的细心。
- •在接口层面强制校验单位与量纲
- •让一线提出的异常自动进入风险流程
- •不要依赖默契解决跨团队标准差异
- •不要把异常提醒当作个人意见
绝地求生模拟器:如果你是当时的CEO,在关键转折点该如何挽狂澜于既倒?
历史不可更改,但思维可以淬炼。针对核心转折点,提出手术刀式改革方案与资源调配破局法,交由全网创业者与投资人可行度公投。
先把跨团队接口的强制校验做上,再谈任务进度
关键干预时点:1999 年 9 月探测器失联、调查确认单位不一致后
- •停止依赖默契处理跨团队标准差异
- •停止让一线提出的异常停留在口头提醒
- •停止在接口规范中省略量纲定义
- •在接口层强制校验单位、精度与范围
- •让异常提醒自动进入正式风险流程
- •在合同与规范中统一跨方技术标准
任务已失败,改进主要作用于后续项目与流程。
跨团队接口具备强制校验,同类隐患在早期即可被发现。
行家深度复盘见解
来自创业者、投资人、前员工和行业专家的真实第一手复盘反思
事故的原因在技术层面非常简单:负责推进数据的软件输出的一个物理量用英制单位,而导航侧按公制解读。两者差了一个换算系数,于是在长距离飞行中被放大成轨道偏差。真正值得反思的是它为什么没有被拦住:跨机构协作时,双方各自有一套成熟流程,合同与接口规范里没有把单位作为必须校验的项;而任务后期,工程师其实已经发现轨道数值不对并提出疑问,但这条信息没有升级为正式的工程风险。事后多数航天机构的流程里都增加了强制量纲检查——制度通常是这么长出来的。
在跨团队协作里,最危险的不是不知道,而是「以为对方和自己一样」。
商业复盘与避坑备忘录 · 单位换算错误毁掉探测器 (Mars Climate Orbiter)
一枚飞行了几亿公里的探测器,为什么毁在了一次单位换算上?
# 商业复盘备忘录:单位换算错误毁掉探测器 (Mars Climate Orbiter) > 一枚飞行了几亿公里的探测器,为什么毁在了一次单位换算上? > 周期: 1998 - 1999 | 行业: 新经济与出行 > 巅峰: 美国航天机构的火星气候探测任务,目标是研究火星大气与水循环,探测器经过长期飞行抵达火星,项目投入数亿美元 > 终局: 探测器在进入火星轨道阶段失联,调查确认导航软件的单位换算不一致,导致轨道计算错误,探测器进入大气后损毁 ## 核心概览 最廉价的技术错误,往往造成最昂贵的后果。巅峰期美国航天机构的火星气候探测任务,目标是研究火星大气与水循环,探测器经过长期飞行抵达火星,项目投入数亿美元;终局是探测器在进入火星轨道阶段失联,调查确认导航软件的单位换算不一致,导致轨道计算错误,探测器进入大气后损毁。 ## 社区公投头号死因 1. [产品技术] 接口定义缺少单位强制校验 (1,325 票) 2. [组织管理] 跨机构协作缺少统一标准 (1,113 票) 3. [组织管理] 内部疑问未被升级处理 (901 票) ## 可执行教训 ### 跨团队接口要对「单位、精度、范围」做强制校验 > 把量纲检查写进流程,而不是依赖人的细心。 - ✅ 推荐做 (DOs): - 在接口层面强制校验单位与量纲 - 让一线提出的异常自动进入风险流程 - ❌ 绝不能做 (DON'Ts): - 不要依赖默契解决跨团队标准差异 - 不要把异常提醒当作个人意见 ## 救亡方案 ### 先把跨团队接口的强制校验做上,再谈任务进度 — 良略编辑部 干预时点: 1999 年 9 月探测器失联、调查确认单位不一致后 - 必须断腕: - 停止依赖默契处理跨团队标准差异 - 停止让一线提出的异常停留在口头提醒 - 停止在接口规范中省略量纲定义 - 破局动作: - 在接口层强制校验单位、精度与范围 - 让异常提醒自动进入正式风险流程 - 在合同与规范中统一跨方技术标准 - 预期结果: 跨团队接口具备强制校验,同类隐患在早期即可被发现。 ## 社区见解 ### 这是航天史上最便宜也最昂贵的错误:换算一个单位几乎不花钱,而后果是整枚探测器。 — 良略编辑部 (工程师) 事故的原因在技术层面非常简单:负责推进数据的软件输出的一个物理量用英制单位,而导航侧按公制解读。两者差了一个换算系数,于是在长距离飞行中被放大成轨道偏差。真正值得反思的是它为什么没有被拦住:跨机构协作时,双方各自有一套成熟流程,合同与接口规范里没有把单位作为必须校验的项;而任务后期,工程师其实已经发现轨道数值不对并提出疑问,但这条信息没有升级为正式的工程风险。事后多数航天机构的流程里都增加了强制量纲检查——制度通常是这么长出来的。 - 如果重来一次的纠偏招式 在跨团队协作里,最危险的不是不知道,而是「以为对方和自己一样」。 --- 来源: 良略 · https://www.lianglue.com/c/mars-climate-orbiter