使用Amazon SQS和AWS故障注入服务测试应用韧性
内容提要
本文介绍如何使用AWS故障注入服务（FIS）和系统管理器自动化，通过分阶段拒绝SQS队列的数据平面访问，测试应用在故障下的韧性。实验验证生产者侧熔断器、缓冲机制及消费者侧积压恢复能力，并利用CloudWatch指标评估恢复行为。文章强调设定明确假设、安全策略范围及监控客户影响指标，以发现并修复故障处理缺陷。
延伸解读
实验设计的关键：明确假设与安全边界
文章强调，韧性实验的核心是设定可衡量的假设，例如“失去SQS访问5分钟，生产者应在30秒内打开熔断器”。同时，安全策略至关重要：拒绝策略必须仅限数据平面操作，避免拒绝管理操作导致队列被锁死。建议使用标签（如FIS-Ready）限定目标队列，并在非生产环境先行测试。
分阶段故障注入的价值
通过逐步增加故障持续时间（2、5、7、15分钟），可以观察不同层面的韧性表现：短时故障测试快速失败和熔断机制，长时故障暴露线程池耗尽、内存压力等系统性问题。这种渐进式方法有助于区分瞬时故障与持续故障对应用的影响，并验证恢复机制在不同压力下的表现。
监控指标的正确解读
文章指出，队列指标如ApproximateNumberOfMessagesVisible在故障期间可能停止变化，这本身是异常信号。但停止条件应基于客户影响指标（如应用错误率），而非队列指标，因为后者在故障中本应波动。恢复阶段需关注积压消息的排空速率，若排空停滞，可能表明消费者过载或卡住。
恢复阶段的潜在风险
恢复后，生产者可能重放缓冲消息，消费者需处理积压。若积压过大，消费者可能不堪重负，导致消息被重新失败并推入DLQ。文章提醒，DLQ在故障期间不会填充，因为消息未被接收，恢复时才可能移动。此外，长时间故障后，部分缓冲消息可能已失去时效，需评估是否仍值得处理。
Q&A
如何使用AWS FIS和SSM Automation模拟SQS队列故障？
通过AWS FIS编排SSM Automation文档，该文档对目标SQS队列应用一个临时的、范围限定的拒绝策略，阻止数据平面操作（如发送、接收、删除消息），持续一段时间后自动移除策略以恢复访问。FIS模板按阶段增加中断时长，以测试不同故障场景。
为什么在SQS故障注入实验中不能拒绝sqs:*权限？
因为显式拒绝会覆盖所有允许，包括自动化自身的清理权限。如果拒绝包含sqs:SetQueueAttributes、sqs:AddPermission和sqs:RemovePermission，可能导致队列被锁定，即使应用策略的角色也无法移除策略，造成无法清理。因此应仅拒绝数据平面操作。
在SQS故障注入实验中，如何区分生产者和消费者的故障处理行为？
生产者侧关注发送消息失败时的行为，如是否快速失败、打开熔断器、本地缓冲或丢弃消息；消费者侧关注接收和删除消息失败时的行为，如是否退避轮询、积压增长以及恢复后能否处理积压。通过观察各自的指标和状态来区分。
在SQS故障注入实验中，为什么DLQ在故障期间不会填满？
因为消息移动到DLQ需要消费者接收消息达到maxReceiveCount次数，而故障期间ReceiveMessage被拒绝，消息未被接收，接收计数不增加，因此不会触发DLQ。DLQ可能在恢复期间因消费者处理积压失败而填充。
如何设置SQS故障注入实验的停止条件？
停止条件应基于客户影响指标，如应用错误率、负载均衡器5xx计数或DLQ深度，而不是队列指标（如ApproximateNumberOfMessagesVisible），因为那些指标在故障期间本应变化。阈值应根据假设设定，例如错误率超过10持续2分钟则停止实验。
在SQS故障注入实验恢复期间，应观察哪些指标来判断系统是否健康恢复？
应观察NumberOfMessagesSent是否恢复基线、ApproximateNumberOfMessagesVisible是否稳定下降、ApproximateAgeOfOldestMessage是否下降、电路断路器是否关闭、DLQ是否有消息进入，以及应用错误率是否恢复正常。
SQS故障注入实验的四个阶段分别持续多久，各阶段能揭示什么问题？
四个阶段分别为2分钟、5分钟、7分钟和15分钟。2分钟阶段揭示快速失败和熔断器激活；5分钟阶段揭示积压积累；7分钟阶段揭示线程池和内存压力；15分钟阶段揭示长期访问丢失下的系统限制。
在SQS故障注入实验中，如何确保消息不丢失？
生产者应使用本地持久化存储缓冲消息，并在恢复后重放；消费者应具备幂等处理能力以安全重试。实验后应核对发送消息数与处理消息数加上DLQ和缓冲存储中的消息，确保没有丢失。
