美国医保网站 Healthcare.gov:为什么一个花了几亿美元、还有充足时间的政务网站,会在上线当天就崩掉?
没有人对整体负责的分工,等于把集成风险交给了上线那一天
美国医保网站 Healthcare.gov:巅峰期美国联邦医疗保险交易平台,承担让数千万人线上投保的公共任务,合同金额与公众关注度都是同类项目中最高的一档;终局是 2013 年 10 月上线即瘫痪,绝大多数用户无法完成注册,被作为大型 IT 项目集成失败的典型案例,承包商合同被终止。
美国联邦医疗保险交易平台,承担让数千万人线上投保的公共任务,合同金额与公众关注度都是同类项目中最高的一档
2013 年 10 月上线即瘫痪,绝大多数用户无法完成注册,被作为大型 IT 项目集成失败的典型案例,承包商合同被终止
5,722 票參與
1 方案 · 1 見解
投稿会先进入待审,通过后才进入公开目录和站点地图。
核心敗因全民歸因公投
投票選擇您認為導致該企業/項目最終死亡的最核心死穴,認同即可即時投票計入權重
多家承包商各自开发、缺少统一集成责任
接口与数据标准不统一,集成风险在上线时才集中爆发
没有有权做技术决策的单一负责人
跨部门的方案争议无法及时裁决,问题被推迟到上线日
需求持续变动而验证不足
功能范围在开发过程中不断调整,压力测试与端到端验证被压缩
上线前的可用性验证不充分
没有按真实并发量做完整压测,容量问题在上线当天才暴露
時間線:從高峰到終局
项目立项与开发
平台开工,多家承包商分别承接不同模块,需求在开发中多次调整
上线即瘫痪
开放注册当天系统无法承受访问量,绝大多数用户无法完成注册
紧急抢修
外部技术团队介入重组架构与发布流程,系统可用性逐步恢复
恢复与问责
平台在年底前基本可用,但承包商合同被终止,项目成为公共 IT 失败的典型案例
四大維度全景復盤剖析
發展背景與全盛期基石
项目由政府部门牵头、多家大型承包商分别承担不同模块,目标是让民众在线比价并完成投保,涉及身份核验、补贴计算与多家保险公司的数据对接巅峰期的成绩单是:美国联邦医疗保险交易平台,承担让数千万人线上投保的公共任务,合同金额与公众关注度都是同类项目中最高的一档。此时的它拥有渠道、品牌与资本的合力,看起来没有任何理由会输。
致命轉折點的戰略誤判
需求在开发过程中持续变动,多家承包商各自开发、接口没有统一标准,且项目缺乏一个有权限做技术决策的统一负责人,问题在上线前没有被完整验证底层架构的缺陷被增长掩盖了很多年,真正爆发时表现为线上事故、体验崩塌与迭代停滞,修复成本远高于当年重做的代价。
內部組織文化與盲目傲慢
技术决策长期被短期交付目标绑架,「先上线,以后再改」变成永久状态,没人对架构健康度负责。
轟然倒塌的崩盤推演
2013 年 10 月上线即瘫痪,绝大多数用户无法完成注册,被作为大型 IT 项目集成失败的典型案例,承包商合同被终止。美国医保网站 Healthcare.gov的结局不是某一次意外,而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
商業落地避坑實操法則
以血淋淋的商業代價淬煉出的創業與經營行動準則(DOs & DONTs)
多方分工的项目,必须先指定一个对整体负责的人
集成问题不会消失,它只会等到上线那天一起出现。
- •为跨承包商的项目指定有实权的技术负责人
- •在上线前按真实并发量完成端到端压测
- •不要让需求在开发后期继续扩张
- •不要用分摊责任的方式代替集成责任
絕地求生模擬器:如果你是當時的CEO,在關鍵轉折點該如何挽狂瀾於既倒?
歷史不可更改,但思維可以淬煉。針對核心轉折點,提出手術刀式改革方案與資源調配破局法,交由全網創業者與投資人可行度公投。
先冻结需求做端到端压测,再恢复上线
關鍵干預時點:2013 年 10 月 1 日上线当天出现大面积不可用时
- •冻结新增功能需求
- •停止由多家承包商各自发布版本
- •停止在没有整体负责人的情况下继续并行开发
- •指定对整体架构与发布负责的技术负责人
- •按真实并发量完成端到端压测并修复容量瓶颈
- •统一接口与数据标准后再逐步恢复上线
抢修期间资源集中投入容量与集成问题,功能交付以可用性通过为前提。
平台在较短时间内恢复可用,投保人能够在开放期内完成注册,避免项目成为公共 IT 失败的长期案例。
行家深度復盤見解
來自創業者、投資人、前員工和行業專家的真實第一手復盤反思
项目并不缺预算也不缺时间,缺的是一个能对整体负责的角色。多家承包商按各自合同完成模块,接口标准、版本节奏与数据口径都不统一,而这些接缝处的矛盾没有人在开发期有权限拍板,只能被一路推到上线。等到真实访问量到来,容量与集成问题同时爆发,抢修只能靠临时加入的外部团队从架构层面重组。
大型项目最难治理的不是代码,是责任边界。
商業復盤與避坑備忘錄 · 美国医保网站 Healthcare.gov
为什么一个花了几亿美元、还有充足时间的政务网站,会在上线当天就崩掉?
# 商業復盤備忘錄:美国医保网站 Healthcare.gov > 为什么一个花了几亿美元、还有充足时间的政务网站,会在上线当天就崩掉? > 週期: 2010 - 2013 | 行業: 工具與互聯網 > 巔峰: 美国联邦医疗保险交易平台,承担让数千万人线上投保的公共任务,合同金额与公众关注度都是同类项目中最高的一档 > 終局: 2013 年 10 月上线即瘫痪,绝大多数用户无法完成注册,被作为大型 IT 项目集成失败的典型案例,承包商合同被终止 ## 核心概覽 没有人对整体负责的分工,等于把集成风险交给了上线那一天。巅峰期美国联邦医疗保险交易平台,承担让数千万人线上投保的公共任务,合同金额与公众关注度都是同类项目中最高的一档;终局是 2013 年 10 月上线即瘫痪,绝大多数用户无法完成注册,被作为大型 IT 项目集成失败的典型案例,承包商合同被终止。 ## 社區公投頭號死因 1. [產品技術] 多家承包商各自开发、缺少统一集成责任 (1,882 票) 2. [組織管理] 没有有权做技术决策的单一负责人 (1,581 票) 3. [戰略決策] 需求持续变动而验证不足 (1,280 票) ## 可執行教訓 ### 多方分工的项目,必须先指定一个对整体负责的人 > 集成问题不会消失,它只会等到上线那天一起出现。 - ✅ 推薦做 (DOs): - 为跨承包商的项目指定有实权的技术负责人 - 在上线前按真实并发量完成端到端压测 - ❌ 絕不能做 (DON'Ts): - 不要让需求在开发后期继续扩张 - 不要用分摊责任的方式代替集成责任 ## 救亡方案 ### 先冻结需求做端到端压测,再恢复上线 — 良略编辑部 干預時點: 2013 年 10 月 1 日上线当天出现大面积不可用时 - 必須斷腕: - 冻结新增功能需求 - 停止由多家承包商各自发布版本 - 停止在没有整体负责人的情况下继续并行开发 - 破局動作: - 指定对整体架构与发布负责的技术负责人 - 按真实并发量完成端到端压测并修复容量瓶颈 - 统一接口与数据标准后再逐步恢复上线 - 預期結果: 平台在较短时间内恢复可用,投保人能够在开放期内完成注册,避免项目成为公共 IT 失败的长期案例。 ## 社區見解 ### 把一个系统拆给五家公司做,最难的部分不是每个模块,而是它们之间的接缝。 — 良略编辑部 (工程师) 项目并不缺预算也不缺时间,缺的是一个能对整体负责的角色。多家承包商按各自合同完成模块,接口标准、版本节奏与数据口径都不统一,而这些接缝处的矛盾没有人在开发期有权限拍板,只能被一路推到上线。等到真实访问量到来,容量与集成问题同时爆发,抢修只能靠临时加入的外部团队从架构层面重组。 - 如果重來一次的糾偏招式 大型项目最难治理的不是代码,是责任边界。 --- 來源: 良略 · https://www.lianglue.com/c/healthcare-gov