2023 年 5 月 23 日 Deno Deploy 事后分析
2023 年 5 月 23 日，格林威治时间 20:42 开始，我们在所有托管在 GCP 上的 Deno Deploy 服务（包括 deno.com 和 deno.land）中遇到了意外停机。由于日志记录推出导致 CPU 容量激增，这些服务无法访问大约 45 分钟。
我们致力于为用户提供稳定可靠的平台，这是我们的首要任务。对于此次事件以及由此造成的任何中断，我们深感抱歉并诚挚道歉。这份报告概述了事件、停机原因以及我们计划采取的措施，以防止此类事件在未来发生。
影响
在 45 分钟的时间里，用户遇到了服务中断，无法访问 Deno Deploy 上的关键 Deno 网站属性和部署，包括 deno.com 和 deno.land。所有 Deno Deploy 托管的部署都受到此事件的影响。
事件时间线
所有时间均为格林威治时间，2023 年 5 月 23 日。
- 20:34 - 启动对我们的生产集群的日志记录更新。
- 20:42 - 第一个警报触发，指示系统故障。
- 20:45 - 团队成员报告 deno.com 无法访问。
- 20:47 - 立即发布了状态更新 发布。
- 20:51 - 回滚程序启动。
- 21:04 - 系统开始显示恢复迹象，警报减少。
- 21:18 - 我们的大多数系统都已恢复。
- 21:27 - 所有系统警报完全恢复。
- 21:43 - 事件正式标记为已解决。
我们估计从系统开始出现故障到完全恢复，停机时间约为 45 分钟。
根本原因
意外停机是由对我们生产集群的日志记录更新触发的。此更新引入了新的服务，该服务无意中将我们的 CPU 负载提高到超过设定的最大容量，阻止了我们的隔离 hypervisor 进行调度，并导致部署失败。
在登台环境中进行测试时，此更改无意中与另一个更新捆绑在一起，掩盖了 CPU 限制问题，并阻止了部署前检测。
下一步
鉴于此次事件和其他近期不太严重的问题，我们认识到当前的“一次性”部署方法不足。我们计划实施金丝雀式部署，允许我们首先将更改部署到金丝雀区域，然后进行全面推广，特别是对于需要长时间推广和回滚程序的重大集群级更改。
今后，我们将实施在登台环境中一次测试一项更改的策略，以防止掩盖潜在问题。
最后，我们正在努力建立更清晰的错误预算和内部服务水平目标 (SLO)，以指导我们的工程团队就可能存在风险的更改做出决策。
有任何问题、建议或其他想法？随时联系我们。