2025年5月，David Lyon通过七周调查，发现并证实了AWS Lambda平台级故障，影响VPC内Node.js函数进行HTTPS调用。故障在执行中途发生，函数返回成功响应后崩溃，且无日志、错误或遥测数据。尽管提供了详尽证据并通过所有官方渠道升级问题，AWS支持、客户经理、内部投诉及高管沟通均未得到有效回应，最终问题被忽视。

文章主要内容总结：

标题：AWS Lambda 静默崩溃——平台故障而非应用错误
作者：David Lyon
发布时间：2025年7月7日
来源：Lyons-Den.com

1. 问题背景

David Lyon 作为一家医疗健康领域的 AWS Activate 初创公司的 CTO 和首席工程师，在七周的调查中发现并证明了 AWS Lambda 存在一个平台级别的静默崩溃问题。该问题影响了在 VPC 中运行并发出 HTTPS 请求的 Node.js 函数。崩溃发生在函数执行过程中，甚至在函数返回成功响应之后，且没有任何日志、错误或可捕获的异常。

2. 调查过程

为了隔离问题，Lyon 采取了以下措施： - 将函数简化为最小可复现代码。 - 在不同运行时、区域和基础设施基线进行测试。 - 在 EC2 上重建并证明问题完全消失。 - 提供了日志、跟踪、指标和内部观察结果。

3. AWS 支持的回应

尽管提供了大量证据，AWS 支持团队仍然坚持问题出在代码上，并建议迁移到 EC2 或 Fargate。Lyon 通过多个官方渠道（包括支持、账户执行、正式投诉、AWS Activate 等）进行升级，但均未得到有效回应。最终，AWS 内部团队在复现问题时也遇到了同样的崩溃，但依然将责任归咎于 Lyon 的代码。

4. 关键发现

• 平台级别崩溃：崩溃发生在 Node.js 运行时、HTTPS 流终止和 Lambda 的 VPC 微虚拟机网络堆栈的交集处。
• AWS 内部复现：AWS 内部团队复现了崩溃，但错误地将其归因于代码中缺少 reject() 调用，而实际上 Lyon 的代码已经包含了这些处理程序。
• 支持流程的失败：AWS 的支持模型无法处理平台级别的故障，尤其是在初创公司的情况下。

5. 最终决策

由于 AWS 未能提供有效的技术支持，Lyon 决定将整个基础设施迁移到 Azure。Lambda 被停用，关键服务在 EC2 上重新构建，并最终迁移到 Azure。这一决策不仅是技术上的，更是文化上的，因为 AWS 未能在其平台出现问题时承担责任。

6. AWS 的最终回应

AWS 在最终回应中承认了崩溃的存在，但将其归因于“反模式”的使用，并拒绝提供内部诊断数据。Lyon 对此进行了逐点反驳，指出 AWS 的回应充满了矛盾和不实之处。

7. 发布报告的原因

Lyon 发布此报告是为了让其他开发者、CTO 和云架构师了解： - AWS Lambda 可能在系统级别静默失败。 - 标准调试工具（如日志、跟踪、X-Ray）无法提供可见性。 - 支持团队可能会在应用层问题被排除后仍然推诿或拖延。

8. 后续事件

Lyon 试图在 r/AWS 论坛上分享此报告，但账号在提交后立即被永久封禁，帖子从未公开。这一事件进一步反映了 AWS 在处理此类问题时的系统性失败。

9. 结论

AWS Lambda 的静默崩溃问题及其支持流程的失败，揭示了平台在可靠性方面的重大风险。Lyon 通过详细的调查和证据，证明了问题的存在，但 AWS 始终未能承认或解决这一问题。

图片标记：文章中未提及图片，故不保留图片标记。

这篇评论主要围绕作者对AWS Lambda执行模型的误解展开，评论者普遍认为作者误解了Lambda的基本工作原理，尤其是在返回HTTP响应后继续执行异步任务的期望。以下是主要观点和论据的总结：

1. 作者误解了Lambda的执行模型

• 评论者指出，Lambda在返回HTTP响应后会立即停止执行，这是平台的文档化行为，而非bug。
  • 评论4: "Your function runs until the handler returns a response, exits, or times out."
    （“你的函数在返回响应、退出或超时之前一直运行。”）
  • 评论6: "If you are using Lambda with a function URL, you aren’t guaranteed that anything after you return your http response remains running."
    （“如果你使用带有函数URL的Lambda，你不能保证在返回HTTP响应后任何代码会继续运行。”）

2. AWS支持的问题

• 尽管作者误解了Lambda的行为，但评论者也指出AWS支持未能有效沟通，导致问题拖延。
  • 评论6: "I am not sure why AWS Support was unable to communicate this OP."
    （“我不确定为什么AWS支持未能向作者解释这一点。”）
  • 评论14: "The fact that support didn’t engage us seems odd as we have gotten engaged for far more silly stuff."
    （“支持没有联系我们似乎很奇怪，因为我们曾因更琐碎的事情被联系过。”）

3. 作者的沟通方式和态度

• 评论者批评作者的愤怒和傲慢态度，认为这阻碍了问题的解决，并影响了其专业形象。
  • 评论10: "If OP had just written up their experience without all the sneering and potshots at Amazon support, people would’ve just gently corrected them."
    （“如果作者只是写下自己的经历，而不是对亚马逊支持冷嘲热讽，人们可能会温和地纠正他。”）
  • 评论25: "This level of arrogance is just crazy. Think of the hundreds of better-qualified, but worse-at-bullshitting people who would have been better in every single position this guy has ever worked in."
    （“这种傲慢程度简直疯狂。想想那些更有资格但不太会吹嘘的人，他们在作者曾担任的每个职位上都会做得更好。”）

4. 技术建议与替代方案

• 评论者建议使用SQS队列或其他方式来处理异步任务，而不是依赖Lambda在返回响应后继续执行。
  • 评论6: "I believe Lambda has some callbacks/signals you can listen to, to ensure your function properly cleans up before the Lambda is frozen."
    （“我相信Lambda有一些回调/信号可以监听，以确保你的函数在Lambda冻结之前正确清理。”）
  • 评论16: "The only way you can do async in Lambda is to spawn another Lambda function."
    （“在Lambda中执行异步任务的唯一方法是启动另一个Lambda函数。”）

5. 平台选择的反思

• 评论者指出，选择平台时需要理解其限制和设计模式，而不是强行适应自己的需求。
  • 评论17: "Lambda ain’t Node.js. Yes, it runs JavaScript, but that doesn’t make it Node.js."
    （“Lambda不是Node.js。是的，它运行JavaScript，但这并不意味着它是Node.js。”）
  • 评论13: "If the designer expects a reliable system that guarantees processing of the request after the return of the status, they cannot rely on a server to not crash the moment the response was sent to the wire."
    （“如果设计者期望一个在返回状态后仍能保证处理请求的可靠系统，他们不能依赖服务器在发送响应后不崩溃。”）

6. 资源浪费与优先级

• 评论者认为作者在调查和撰写长篇PDF上浪费了宝贵的资源，尤其是对于初创公司而言。
  • 评论11: "The time spent in those meetings or writing this vitriolic pdf would have gone a long way towards shipping features."
    （“在这些会议或撰写这篇充满敌意的PDF上花费的时间本可以用于发布功能。”）
  • 评论19: "Not sure if a seven-week investigation is the best use of engineering resources at early startups."
    （“不确定七周的调查是否是早期初创公司工程资源的最佳利用方式。”）

总结：

评论者普遍认为作者误解了AWS Lambda的执行模型，尽管AWS支持在沟通上存在问题，但作者的态度和沟通方式也阻碍了问题的解决。建议作者理解平台限制，并采用更合适的解决方案，同时反思资源的使用优先级。