支付系统混沌工程暴露ECS任务替换与结算风险

某大型支付处理商曾在对账高峰期发生长达四小时的结算服务中断，诱因不是硬件故障或DDoS，而是一次例行ECS任务替换与单个Redis节点的隐性依赖叠加，最终造成授权链路连续超时。公司因此支付了七位数的SLA违约金，并花费两个月重新恢复企业客户信任。

这起事故说明，面向无状态Web服务设计的混沌工程假设，并不适合直接套用到支付系统。支付交易可能处于“已授权未捕获”“已捕获未结算”或“已结算未对账”等不可逆中间态，停止实验并不等于终止事务；按10%的任务划定影响范围，也无法反映一个批量结算任务可能牵动数千笔交易。此外，PCI DSS、SOC 2及银行监管要求对生产降级操作实施变更审批。

ECS任务替换还会制造新任务已接流量、但配置和连接池尚未准备好的窗口。实践中，团队将服务最小健康比例设为100%、最大部署比例设为200%，健康检查宽限期和任务启动期均设为120秒，并启用部署熔断及自动回滚；容器停止超时也设为120秒，以便排空期间完成交易。默认30秒宽限期不足以支持加载加密密钥及连接多个下游依赖。更有效的实验不是简单终止任务，而是将启动配置加载延迟15秒，观察负载均衡器是否提前发送请求。

服务发现同样可能放大故障。某系统每秒处理400笔交易，原先将Route 53 TTL设为60秒，但实测故障转移需要93秒，原因包括JVM DNS缓存和VPC解析器缓存，期间约有3.7万次请求发往失效端点。团队随后把服务发现TTL及JVM的networkaddress.cache.ttl统一调整为10秒，并通过停止单个任务测量各依赖服务继续访问旧IP的时长。

Spot实例中断则可能直接造成财务状态不明。一次夜间结算任务原计划在75秒内处理约5万笔交易，模拟中断在第58秒发生后，1.4万笔记录停留在“结算已启动”，下游清算机构却未收到提交。自动恢复无法识别部分提交状态，人工处理耗时六小时，结算服务最终迁移至按需资源。

合规混沌工程应采用“审批优先”模式，先定义授权成功率高于99.5%、P99延迟低于200毫秒、未解决交易为零等稳态指标，再依据交易角色而非实例数量划定范围。团队为任务标注role=auth-primary、role=auth-secondary和role=audit-writer，并计划先从audit-writer任务开始实验。