一次例行替换，为何让支付系统中断四小时？

三年前，一家大型支付处理商的结算服务在对账高峰期中断了整整四个小时。事后复盘发现，问题既不出在硬件故障，也不是遭遇了DDoS攻击，而是一次部署过程中的例行ECS任务替换。

这次替换撞上了系统对单个Redis节点的隐性依赖，授权链随即出现连锁超时。代价是七位数的SLA违约金，以及耗时两个月才重新赢回企业客户的信任。

对大多数严肃的混沌工程项目来说，真正的起点往往就是这样一次事故。它不是从理论出发，而是通过事后分析暴露出一个尴尬的事实：人们对系统故障模式的理解，远比想象中匮乏。

混沌工程的老手册，撞上支付系统的新问题

混沌工程并不新鲜。Netflix让它广为人知，亚马逊云科技围绕它构建了故障注入模拟器（FIS），几乎每一份云原生架构指南都会提到它。

但那些为无状态Web应用编写的手册，一旦套用到运行在Amazon ECS上的支付系统，往往会以令人痛苦的方式失效。标准混沌实验建立在一些假设之上，而支付系统的设计恰恰违反了这些假设。

在典型的Web服务里，引入延迟、观察性能下降、然后回滚，流程清晰。但在支付系统中，实验过程中正在处理的交易可能处于三种状态之一：已授权但未捕获、已捕获但未结算、已结算但未对账。终止实验并不会让这些交易停下来，它们会卡在一种模糊状态里，既需要人工干预，又可能触发合规异常。

大多数混沌测试框架允许你针对一定比例的实例或任务进行测试。支付系统通常存在隐式状态耦合，这让“10%的任务”这种表述无法准确反映实际影响范围。一个处理批量结算的ECS任务，哪怕只占服务集群极小部分，也可能处在数千笔交易的关键路径上。

还有一层约束来自合规。PCI DSS、SOC 2以及大多数银行业监管规定都要求，任何会故意降低生产系统性能的操作，都必须经过变更管理审批。未经审批就运行混沌实验，会直接导致审计问题——很多团队是在事后才发现这一点的。

这些限制并不意味着混沌工程在金融科技领域被禁止。它说明的是，这套流程需要换一种方式搭建。

ECS替换任务时，那个致命的窗口期

ECS引入了一类独特的故障，而那些专为Kubernetes或裸机EC2设计的混沌分析工具，对此覆盖不足。

当ECS替换任务时——无论是部署过程中、健康检查失败还是Spot实例中断——它会根据部署配置，在排空旧任务之前先启动新任务。“旧任务清空”与“新任务健康”之间的这段时间窗口，正是支付系统容易受伤的地方。

如果授权服务在启动时向服务注册表或负载均衡器注册，而“最低健康百分比”配置又没有考虑预热期，流量就会打到尚未从参数存储加载配置、也没建立数据库连接池的任务上。任务会处理请求并返回错误，但健康检查端点返回的是200状态码，ECS根本识别不出这个任务已经处于降级状态。

控制这一行为的配置位于ECS服务和任务定义中。把deployment_minimum_healthy_percent设为100，可以防止ECS在滚动部署期间让任务数量低于目标值；把health_check_grace_period_seconds设为120秒，能让任务在ECS把流量路由过去之前，有足够时间从参数存储加载配置、预热数据库连接池；stopTimeout设为120秒，则确保任务清空过程中正在进行的事务能够完成。

这些数值都不是默认值。它们是在混沌实验发现默认30秒宽限期对某项支付授权服务不够用之后，才被调优出来的——那项服务在启动时需要加载加密密钥，并建立与多个下游依赖项的连接。

在这里，真正值得做的混沌实验不是“终止一个任务”，而是“把启动时的配置加载延迟15秒，观察负载均衡器会往这个任务上发什么”。大多数团队直到事故暴露了这个漏洞，才想起来做这项实验。

93秒故障转移，37000个请求打向失效端点

ECS服务发现使用Route 53来注册任务。当任务停止运行时，DNS记录的TTL决定了客户端还会继续把请求路由到已失效IP地址多长时间。在支付系统中，服务之间通过私有DNS相互调用，60秒的TTL意味着任务停止后，连接故障会持续60秒。应用程序能否优雅处理这种情况，取决于HTTP客户端的配置，而不是ECS。

在一个每秒处理400笔交易的系统里，团队把Route 53的TTL配置为60秒，并预期故障转移能在这个时间窗口内完成。实际测得的故障转移时间是93秒。

这多出来的时间来自两个此前没被考虑到的缓存层：JVM的默认DNS缓存，其默认TTL取决于JVM版本和安全管理器配置，通常为30秒，但在某些配置下可能无限期保留；以及VPC解析器缓存。在每秒400次交易的情况下，这93秒的窗口导致大约37000个请求被发送到了已失效的端点。

实验结束后，团队把TTL缩短至10秒，并调整了JVM的网络相关配置。这个数字上的落差，正是混沌实验的价值所在——它把“以为”变成了“实测”。