案例研究：一个异常导致航空公司停飞

问题的规模

你是否注意到，那些最终演变成重大问题的事件，往往始于微不足道的小错误？一个小小的编程失误，就像雪球一样开始滚动。随着它不断加速，问题的规模也越来越大。一家大型航空公司就遭遇了这样一起事件。最终导致数千名乘客滞留，公司损失数十万美元。以下是事件的经过。

航空公司的事故

和往常一样，所有名称、地点和日期均已更改，以保护相关人员和公司的隐私。 此次事故起源于对支持核心设施（CF）的数据库集群进行的一次计划内故障转移。当时，航空公司正朝着面向服务的架构转型，其目标通常包括：

• 提高代码复用率
• 缩短开发周期
• 降低运维成本

此时，CF系统尚处于第一代。CF团队制定了按功能分阶段推出的计划，这是一个合理的策略，听起来可能也很熟悉——因为如今大多数大型企业都在推进类似的项目。

CF能够根据日期、时间、城市、机场代码、航班号或任意组合，查找并返回航班详情列表。事故发生时，自助值机终端、电话菜单以及“渠道合作伙伴”应用程序已更新为使用CF服务。

渠道合作伙伴应用程序会向大型在线旅游预订平台提供数据 feeds。IVR 系统和自助值机终端都用于为乘客办理登机手续。开发计划中包含将登机口工作人员和客服中心的应用程序逐步迁移到 CF 进行航班查询，但这些更新尚未实施。这一点后来证明是幸运的，我们很快就会看到原因。

核心设施架构

CF 的架构师们清楚地认识到该系统对业务的重要性。因此他们设计了高可用性架构。系统运行在一组 J2EE 应用服务器组成的集群上，并配备冗余的 Oracle 9i 数据库。所有数据存储在一个大型外部 RAID 阵列中，每天进行两次异地备份，同时在另一台机箱中保留磁盘镜像副本，确保其延迟不超过五分钟。

纯粹由熔融沙粒、旋转的金属锈蚀物和操作系统构成。

CF 技术细节

Oracle 数据库服务器每次仅在一个集群节点上运行，由 Veritas Cluster Server 负责控制数据库服务器，分配虚拟 IP 地址，并挂载或卸载 RAID 阵列上的文件系统。最初，一对冗余的硬件负载均衡器将外部流量导向其中一个应用服务器。像自助值机服务器和 IVR 系统这样的客户端应用，都会连接到前端的虚拟 IP 地址。到目前为止，一切正常。

下图展示的是物理基础设施中常见的高可用性架构，这种设计非常可靠。

CF 的可靠性

CF 并未出现典型的单点故障问题。每一块硬件都实现了冗余：CPU、硬盘、网卡、电源供应、网络交换机，甚至风扇也都具备冗余设计。

事实上，距离主站点三十英里外还有一个备用站点，可在主系统发生故障时立即接管。