近期，亚马逊网络服务（Amazon Web Services）发生大规模故障，导致大量网站、游戏乃至智能家居设备瘫痪数日，引发广泛关注。云服务的分布式架构本应保护客户免受此类故障影响，究竟何处出了差错？亚马逊发布了一份详细的技术分析报告，而正如著名俳句所言：“绝非域名系统/不可能是域名系统/结果确是域名系统。”
这好比一起车祸现场：事故虽已清理完毕，但车辆排起的绵长队伍仍如手风琴般持续震荡。本次故障的首个问题在较短时间内得到解决——从10月19日23:48至10月20日2:40，历时三小时。然而正如交通拥堵案例所示，依赖链开始断裂，系统直至很久后才完全恢复。
根本原因据称是DynamoDB（数据库服务）的域名系统配置出错并被发布至Route53（域名系统服务）。继而EC2（虚拟机服务）部分功能随之崩溃，因其自动化管理系统依赖DynamoDB。而亚马逊的网络负载均衡器天然依赖域名系统，同样未能幸免。
需要强调的是，仅DynamoDB在整个美东一区的故障就足以摧毁数百万网站与服务。但EC2实例无法启动更是雪上加霜，负载均衡器受影响则堪称灾难级事件。
域名系统故障背后的具体技术问题，是程序员“最青睐”的故障类型——竞争条件：两个重复事件持续相互覆盖，正如动画片中兔八哥与达菲鸭争夺海报的经典动图所示。DynamoDB域名解析采用双组件架构：域名系统规划器定期发布考量系统负载与可用性的新方案；域名执行器在监测到新方案时，会以事务形式将其应用于Route53，确保方案要么完整执行要么完全放弃。
事故发生时，首个域名执行器正在缓慢执行旧方案。当新方案陆续抵达时，另一执行器获取并实施其中一份。此时Route53已载入有效更新数据，系统随即发起清理过期方案（含旧方案）指令，恰逢首执行器刚完成旧方案部署。
由于清理操作与旧方案最终执行同时发生，该方案此时已包含空信息并被应用，实质上删除了所有DynamoDB域名记录。这个重大失误必须手动修复，毕竟域名记录已处于矛盾状态。
与此同时，EC2服务开始崩溃——其自动化管理系统依赖DynamoDB。新建EC2实例受阻，导致请求积压如山。技术人员不得不长期限制EC2实例创建速率，意味着众多服务与网站需待实例上线才能恢复。
更棘手的是，亚马逊网络负载均衡器同样遭受重创。域名记录修复及传播的延迟，致使负载均衡器启动的新EC2实例处于矛盾网络状态。即便底层基础设施运行正常，大量健康检查仍告失败。这些失败检查导致网络负载均衡器节点与后端目标（果不其然！）被移出域名系统，许久后才重新归位。
事后，亚马逊技术人员暂停DynamoDB域名系统规划器与执行器运行，直至针对该竞争条件的修复方案出炉并增强防护措施。EC2将新增异常工况测试套件，网络负载均衡器则会配备控制机制，限制健康检查失败时的容量削减幅度。
自动化控制系统在云计算领域及任何正规企业中都不可或缺，但正如本案所示，它们需要极度缜密的编程与去中心化设计——而这正是亚马逊的失误所在。请始终铭记：“所谓云端，不过是他人计算机而已。”
