GitHub Status

小君 3， 2024

今天没有事故报告。

小君 2， 2024

没有事故报告。

小君 1， 2024

没有事故报告。

五月 31， 2024

没有事故报告。

五月 30， 2024

副驾驶事故

解决 - 这个事件已经解决了。
五月30，17:22 UTC

更新 - 副驾驶操作正常。
五月30，17:22 UTC

更新 - 我们已经推出了缓解措施，修复程序似乎是稳定的。这个事件已经解决了。
五月30，17:22 UTC

更新 - 副驾驶性能下降。我们正在继续调查。
五月30，17:14 UTC

更新 - 我们的CoPilot API目前遇到了后端连接问题，我们正在积极采取缓解措施。
五月30，17:14 UTC

调查 - 我们目前正在调查这个问题。
五月30，17:14 UTC

五月 29， 2024

没有事故报告。

五月 28， 2024

代码空间事件

调查 - 代码空间运行正常。
五月28，21:24 UTC

解决 - 这个事件已经解决了。
五月28，21:24 UTC

更新 - 解决方案已经实施，我们正在看到一些恢复。在标记此问题解决之前，我们将继续监控一段时间。
五月28，21:19 UTC

更新 - 我们仍在调查根本原因和补救方案。与此同时，这里有一个解决方案，能够从DockerHub拉图像:

1. 创建一个免费的DockerHub帐户https://hub.docker.com(或者如果你有的话，使用一个现有的账户)。
2. 创建DockerHub的秘密/PAThttps://hub.docker.com/settings/security(读权限应该足够)。
3. 去https://github.com/settings/codespaces

添加三个cospace秘密:

- DOCKERHUB_CONTAINER_REGISTRY_PASSWORD(等于你创建的DockerHub PAT)
—DOCKERHUB_CONTAINER_REGISTRY_SERVER(等于https://index.docker.io/v1/）
- DOCKERHUB_CONTAINER_REGISTRY_USER(等于你的DockerHub用户名)

4. 确保将这些秘密设置为对目标repo可见。
5. 创建/重建您的代码空间

以上步骤摘自官方文档:https://docs.github.com/en/codespaces/reference/allowing-your-codespace-to-access-a-private-registry#example-secrets
五月28，20:53 UTC

更新 - 重复更新，如上所述
五月28，20:53 UTC

更新 - 一些代码空间目前无法为DockerHub托管的图像正确创建。其他注册中心应该不受影响。我们正在调查根本原因，并将很快发回报告。
五月28，20:23 UTC

调查 - 我们正在调查代码空间性能下降的报告
五月28，20:17 UTC

五月 27， 2024

没有事故报告。

五月 26， 2024

没有事故报告。

五月 25， 2024

没有事故报告。

五月 24， 2024

没有事故报告。

五月 23， 2024

代码空间事件

解决 - 在2024年5月23日的15:31到16:02之间，代码空间服务报告了所有地区代码空间的降级体验。经过进一步调查，发现这是一个错误报告问题，并没有对用户产生影响。实现的新错误报告开始在现有的非面向用户的错误上提出，这些错误将在流中进一步处理，在控制器级别，这些错误不会对用户造成影响。我们正在努力改进我们的报告发布流程，以减少未来类似的问题，包括更新监视器和仪表板，以排除这类错误。我们还对内部API响应进行了重新分类和修正，以便更好地表示用户面对的错误，从而获得更准确的报告。
五月23，16:02 UTC

更新 - 我们正在调查所有地区客户试图启动代码空间的错误率增加的情况，大约15%的尝试受到影响。任何受影响的客户可能会尝试重新启动其代码空间。我们正在继续调查。
五月23，15:41 UTC

调查 - 我们正在调查代码空间性能下降的报告
五月23，15:31 UTC

五月 22， 2024

没有事故报告。

五月 21， 2024

行动事件

解决 - 在2024年5月21日，在11:40 UTC和19:06 UTC之间，由于上游云提供商的配置更改，各种服务经历了延迟增加。

GitHub Copilot Chat的P50延迟高达2.5s, P95延迟高达6s。GitHub Actions在工作流运行更新时延迟了20 - 60分钟。由于GitHub Actions延迟，GitHub Enterprise Importer客户经历了更长的迁移运行时间。此外，预算通知和UI报告的计费相关指标被延迟，导致计费详细信息过时。事故发生后，没有数据丢失，系统恢复正常。

在12:31 UTC，我们检测到云主机延迟增加。在14:09 UTC，非关键流量暂停，这没有导致恢复服务。在UTC时间14:27，我们在一个网络网关集群中发现了高CPU负载，这是由一个预定的操作系统升级引起的，这导致了集群内意外的、不均匀的流量分布。我们在UTC时间16:35开始部署额外的主机。在17:58 UTC完成再平衡，在18:03 UTC观察到系统恢复，并在19:06 UTC完成。

我们已经确定了对负载阈值的监视和警报中的漏洞。我们对这些修复程序进行了优先级排序，以缩短检测和缓解此类问题的时间。
五月21，19:06 UTC

更新 - Actions运行正常。
五月21，18:14 UTC

更新 - 我们开始看到对操作工作流运行、工作流作业运行和检查步骤的任何延迟的恢复。仍然遇到似乎卡住的作业的客户可以重新运行工作流以查看已完成的状态。我们也看到了GitHub企业导入器迁移的复苏。我们将继续监测恢复情况。
五月21，18:03 UTC

更新 - 我们将继续调查操作工作流运行、工作流作业运行和检查步骤状态更新的延迟。这影响了100%使用这些功能的客户，平均延迟20分钟，P99延迟1小时。客户可能会看到他们的Actions工作流可能已经完成，但是运行可能会出现挂起，等待其状态更新。这也影响了GitHub企业导入器的迁移。迁移可能需要更长的时间才能完成。我们正在与我们的供应商合作解决这个问题，并将继续提供更新，因为我们了解更多。
五月21，17:41 UTC

更新 - 我们将继续调查操作工作流运行、工作流作业运行和检查步骤状态更新的延迟。客户可能会看到他们的Actions工作流可能已经完成，但是运行可能会出现挂起，等待其状态更新。这也影响了GitHub企业导入器的迁移。迁移可能需要更长的时间才能完成。我们正在与我们的供应商合作解决这个问题，并将继续提供更新，因为我们了解更多。
五月21，17:14 UTC

更新 - 我们正在继续调查操作工作流运行、工作流作业运行和检查步骤的延迟，并将在我们了解更多信息时提供进一步的更新。
五月21，16:02 UTC

更新 - 我们已经确定了第三方网络配置的变化，并正在与提供商合作解决这个问题。当我们了解更多信息时，我们将继续提供最新消息。
五月21，15:00 UTC

更新 - 我们已经确定了导致操作工作流运行、工作流作业运行和检查步骤延迟的网络连接问题。我们正在继续调查。
五月21，14:34 UTC

更新 - 我们正在调查Actions作业状态的延迟更新。
五月21，13:58 UTC

调查 - 我们正在调查Actions性能下降的报告
五月21，12:45 UTC

五月 20， 2024

我们正在调查性能下降的报告。

解决 - 在5月19日上午3:40 UTC和5月20日下午5:40 UTC之间，负责渲染Jupyter笔记本的服务降级。在此期间，客户无法渲染Jupyter笔记本。

这是由于Redis依赖的一个问题，这个问题通过重启得到了缓解。我们的监控出现问题，导致我们的响应延迟。我们正在努力提高监测器的质量和准确性，以缩短检测时间。
五月20，17:05 UTC

更新 - 我们开始看到恢复渲染木星笔记本，并继续监测。
五月20，17:01 UTC

更新 - 客户可能会在从PR diff页面或文件选项卡查看呈现的Jupyter笔记本时遇到错误
五月20，16:50 UTC

调查 - 我们目前正在调查这个问题。
五月20，16:47 UTC

产品

平台

支持

公司