美国政府自推出Healthcare.gov医保网站之后就故障频发，甚至有两个州打算退出该医保项目。要说咱们这些企业能从该网站得到哪些经验教训，那就是开发与发布大容量网站别做的那些事情。

鲜少有开发项目能与HealthCare.gov的规模与社会重要性进行对比。但如果政府的IT组织更仔细地考虑处理流量需求所需的技术，并了解慢工出细活的俗话，就不会发生这样让人纠结的事。

这些被忽略的元素包括站点的基本架构、适当的压力测试（测试网站高可用性与灾难恢复功能），最后一点是只有一个人从概念到交付负责该项目的管理。

没有采取适当的预防措施确保大容量网站的稳定性与可靠性，美国联邦政府不是唯一该问责的。例如，尽管HealthCare.gov最近遭遇大断电，这是由于某个托管供应商未指明的“元件失效”造成，其实很多IT组织都无法部署一个有效的DR策略。

“很多组织都没有灾难恢复策略，你可能觉得惊讶，”West Monroe Partners高级IT经理Nate Ulery表示，“多数情形下，组织投资了必要的软硬件用于DR，但他们并没有投资定期进行证明与测试的过程。因此，他们常常犹豫不决。”

很多企业都会发生类似HealthCare.gov这样的情况，没有考虑到两种类型的灾难：其一是大家都知晓的飓风与地震，还有一种就仅限于组织内部知道，可能只包括一个腐坏的应用或者单个硬件或软件组件故障。

“因此，多数人认为他们所购买的的硬件与软件简直就是万能的，其实不然。他们对于灾难恢复与高可用性能提供的功能想得太天真了。”

即使能够处理大容量的HealthCare.gov，该站点的架构模式应该更为谨慎选择。该站点的架构围绕着传统数据库模式构建，而不是以目录为中心构建，后者更适合在大量数据仓储中查询，找到相关信息并更快交付结果。

“对于存储与访问大量数据来说，数据库很好，但其设计目的不是以近乎实时的速度交付数据。目录对读存储信息进行了优化，让你能快速获取。HealthCare.gov的挑战在于不仅要管理大量数据，也要将来自外部第三方的数据链接在一起。”Novato公司系统开发经理Wade Ellery表示。

Ellery补充，HealthCare.gov不是唯一一家能从基于目录方式搜寻复杂数据集并快速返回查询的站点。事实上，他的大客户越来越多地转向不仅管理自己拥有的雇员与内部数据，还管理客户的雇员与数据。

“我们的保险公司管理的身份从1亿增至2亿，”Ellery说，“HealthCare.gov是最大的尝试，将所有这些身份与信息集合在一起，这预示着世界未来的样子。随着网络增长，我们开始追踪并链接更多信息，我们将构建需要这种（目录）方式的大型数据集。”

该理念最明显的错误是没有雇佣C级别的技术高层解决蔓延式发展的网站。他们表示，对该网站的发展愿景没有一个清晰的认识，无法对很多外部程序与50个左右的分包商卡法的很多不同的HealthCare.gov技术模块进行协调。

“必须得有一个主心骨从宏观角度看待问题，同时要有技术层的实践者。你不能让官僚主义或政客来作出技术层面的关键决策。”Ellery说。

作为美国的首席技术官，Steven VanRoekel之前在微软待了很久，他应该在该项目中承担重要角色，或者雇佣经验丰富的协调员。基于某些官僚或财政紧缩的考量，他或他的前任Vivek Kundra在该角色中能发挥多大效用还是个疑问。

“随着预算超支，联邦CIO通常没有那么多的控制权利。多数时候他们做得最好的就是跟着大方向走。”分析公司The Real Story Group创始人Tony Byrne表示。

除了脆弱的执行力，IT领导者还能从HealthCare.gov学到的是他们应该对同事尽量真诚：如果某事变得越加复杂与困难，提早告知，花时间教育。

Byrne承认，美国政府一开始就深陷其中，克服三大不同的元素，或就是他所称的“Web应用三重彩”。

“他们必须在前端提取一个非常复杂的客户旅程，申请不同的业务规则到后端交易，包括很多外部合作伙伴，并支持有大量峰值的大流量，”他说，“这些要求中的任意一个都需要非常专业的知识。”

该项目还有一个缺陷，技术工人无法控制事态发展，因为要赶在2013年10月1日完成并交付。但基于最高法院通过的奥巴马医改，在关于是否自己运行医疗交易所还是联邦政府运行，都消耗了大量时间，导致程序员没有合理的时间与金融资源交付一个让人满意的产品。

“任何大型软件项目都都无法限定时间。它们如同婴儿，准备好了就从妈妈肚子里出来，”Ellery说，“但却被政治与10月1日就得交付的承诺给困住了。”