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负载提高到超出最大设定容量，导致我们的隔离管理程序无法调度，从而导致部署失败。
在预演环境（staging environment）测试期间，这项更改无意中与另一个更新捆绑在一起，这掩盖了CPU限制问题，并阻止了部署前检测。
后续计划
鉴于此次事件以及近期其他不太严重的问题，我们认识到当前“一次性”的部署方法不足。我们计划实施金丝雀式部署，允许我们首先将更改部署到金丝雀区域，然后再进行全面发布，特别是对于需要冗长发布和回滚程序的重大集群级更改。
展望未来，我们将在预演环境（staging environment）中强制执行一次只测试一项更改的策略，以防止潜在问题被掩盖。
最后，我们正在努力建立更清晰的错误预算和内部服务水平目标（SLO），以指导我们的工程团队在决策潜在风险变更时的过程。
有疑问、建议或其他想法？请随时与我们联系。