2023年5月23日 Deno Deploy 事后分析
2023年5月23日，UTC 时间 20:42 开始，我们在 GCP 上托管的所有 Deno Deploy 服务，包括 deno.com 和 deno.land，都经历了意外中断。由于日志发布导致的 CPU 容量激增，服务大约在 45 分钟内无法访问。
我们始终致力于为用户提供稳定可靠的平台，这是我们的首要任务。对于此次事件给您带来的任何不便，我们深感抱歉并诚挚道歉。本报告概述了事件经过、中断原因以及我们计划采取的措施，以防止未来再次发生此类事件。
影响
在 45 分钟的时间内，用户经历了服务中断，无法访问 Deno 的主要网站和 Deno Deploy 上的部署，包括 deno.com 和 deno.land。所有 Deno Deploy 托管的部署都受到了此次事件的影响。
事件时间线
所有时间均为 UTC 时间，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 负载增加到超过最大设定容量，阻止了我们的 isolate hypervisor 被调度，并导致部署失败。
在暂存环境中的测试期间，此更改不慎与另一项更新捆绑在一起，这掩盖了 CPU 限制问题，并阻止了部署前检测。
下一步是什么？
鉴于此次事件和其他最近发生的非严重问题，我们认识到当前“一键式”部署方法不足。我们计划实施金丝雀式部署，允许我们在全面推广之前首先将更改部署到金丝雀区域，特别是对于需要漫长推出和回滚程序的重要集群级更改。
展望未来，我们将强制执行在暂存环境中一次测试一项更改的策略，以防止掩盖潜在问题。
最后，我们正在努力建立更清晰的错误预算和内部服务级别目标 (SLO)，以指导我们的工程团队在有关潜在风险变更的决策过程中。
有任何问题、建议或其他想法？请随时给我们留言。