76 Circle Ci incidents · 2025年11月 — official updates, affected components, duration and resolution details.
我们发现了影响我们Mac基础设施的网络问题。 我们正在调查 很快会提供最新消息 顾客可能在此期间排队.
我们已经确定了我们的Mac基础设施供应商的联网问题,并且正在与他们合作解决这个问题。 我们开始看到一些恢复,但我们预计顾客可能会看到一些排队. 我们很快会再更新的.
我们的Mac基础设施供应商对这个网络问题应用了一个定律,我们看到队列时间恢复正常. 我们要继续观察 事情一段时间。 我们很快会再更新的.
我们没有看到进一步的影响 排队时间和一切都恢复正常。 我们赞赏你耐心地努力解决和监测这一问题.
自动翻译自官方事件更新。
客户在查看计划使用UI或调用计划使用API时可能会出现间歇性出错. 我们已查明了这一问题,并正在积极努力减轻这些错误.
我们通过计划使用API缓解了这个问题,UI中的相关页面正在正确加载.
这一事件已经得到解决.
自动翻译自官方事件更新。
在协调世界时19:49至协调世界时2026年8月25日21:07之间,试图使用GitHub登录到CircleCI的客户无法登录,并收到来自GitHub的一个错误,称回调URL无效. 已经登录的客户没有受到影响。 GitHub 登录功能正常。 我们感谢你在我们团队努力执行一个解决方案时表现出的耐心.
自动翻译自官方事件更新。
问题的原因已经确定,我们正在着手解决这个问题.
一项措施已经执行,我们正在监测结果.
透视数据再次好. 谢谢你的耐心.
自动翻译自官方事件更新。
GitHub在https://www.githubstatus.com/incidents/zkxwbgr0cnmx上报告了影响CircleCI管道触发和伐木的事件。 飞行中的工作正在运行,但向GitHub Pull Request报告的状况可能会失败.
GitHub API的出错率仍然很高, 我们将继续在获得更多信息后提供最新情况.
GitHub的API持续出现高误差率, 使用GitHub作为VCS的客户可能会因此受到CircleCI平台经验的影响. 这与GitHub事件直接有关: https://www.githubstatus.com/incidents/zkxwbgr0cnmx 互联网档案馆的存檔,存档日期2013-12-21. 一旦获得更多信息,我们将提供最新资料.
我们开始观察到GitHub APIs的稳定有所改善。 我们将继续监测他们恢复的情况.
GitHub API 出错率和延迟似乎已经恢复。 我们将继续进行监测.
GitHub的一些API仍然退化,导致少量与承诺状态更新和钩处理相关的故障. 我们将继续尽最大努力减轻这些影响.
GitHub的API似乎正常运行.
自动翻译自官方事件更新。
在协调世界时8月15日下午1:00结束的计划维护之后,对工作处理的一些影响在我们宣布的窗口外持续了约30分钟. 一些客户继续看到工作开始出现延误,少数工作因基础设施出错而失败,直到协调世界时13:30左右。 这个问题已经解决,工作处理已经恢复正常。 在此窗口中工作失败的客户可能重新运行受影响的工作 。 我们感谢你在我们团队努力执行一个解决方案期间表现出的耐心,并对扩大的影响可能造成的任何不便表示歉意.
自动翻译自官方事件更新。
GitHub is currently experiencing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h). Customers who use GitHub as their VCS may experience impact to their CircleCI platform experience as a result, impacting checkout and workflows. We will provide another update as we have more information to share. Thank you for your patience.
The issue impacting customers who use GitHub as their VCS while GitHub was undergoing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h) has now been resolved. GitHub has resolved the underlying issue and the affected functionality has returned to normal. We thank you for your patience.
Between 13:50 UTC and approximately 17:30 UTC on August 11, 2026, some customers experienced delays of up to an hour in pipeline status updates and in notification delivery. Between 16:40 UTC and 17:00 UTC within that same window, a small number of customers also saw newly created pipelines fail to process, appearing in an errored state in the UI and API. The issue has been resolved and all affected functionality has returned to normal. Customers whose pipelines errored during that window can retrigger them. We thank you for your patience while our team worked on implementing a fix.
Usage API data is delayed for 8/5/2026. All prior data remains available. We are investigating. Thank you for your patience.
The issue has been identified and a fix is in progress.
A fix is in place and is being monitored. Thanks for your patience.
The Usage API issue has been resolved. Data has been loaded for yesterday, 8/5/2026. We appreciate your patience.
We are seeing an issue with Insights service where the data from the last 24 hours is lagging. We are investigating.
We are continuing to investigate and will update as we know more.
We have identified the issue, and are working with our upstream provider to resolve it now.
The upstream issue has been resolved, and the insights data from the last 24 hours has caught up. Thank you for your patience.
We are experiencing increased queue times for Windows, Android, and GPU jobs due to capacity constraints with a third-party infrastructure provider. Jobs will continue to be processed but may take longer than usual to start. Thank you for your patience while our engineers work to resolve this.
We're starting to see queue times slowly recovering. We'll be monitoring this situation, we appreciate your patience.
Queue times continue to gradually recover with our third-party infrastructure provider, though we've seen a slight uptick in the last 30 mins. We're keeping an eye on this and will keep you updated as things get back to normal. Again, thank you for your patience.
Queue times for both Android and Windows jobs, which had been recovering, have started to rise again. This continues to be related to capacity constraints with our third-party infrastructure provider. We'll continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.
Queue times for both Android and Windows jobs continue to be volatile, with sharp swings up and down. This remains related to capacity constraints with our third-party infrastructure provider. Our team will continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.
Queue times for both Android and Windows jobs, affected by capacity constraints with our third-party infrastructure provider, have been recovering significantly for the last half hour. We're continuing to monitor for a bit longer to confirm they return to normal levels. We appreciate your patience.
Queue times for Android and Windows jobs have reduced significantly over the last hour. You may still notice brief, isolated queuing at times, but this is no longer at incident-level impact. This was related to capacity constraints with a third-party infrastructure provider. We thank you for your patience while we monitored the situation. If you have any issues, please reach out to our Support team.
GitHub目前正在经历服务退化(https://www.githubstatus.com/incicents/yjysg0xrl67m)。 使用GitHub作为VCS的客户可能会因此体验到对其CircleCI平台体验的影响,会影响出账和工作流程. 随着我们有更多的信息要分享,我们将提供另一个最新情况。 谢谢你的耐心.
这一问题影响到在GitHub服务退化期间使用GitHub作为其VCS的客户(https://www.githubstatus.com/incidents/yjysg0xrl67m)。 GitHub解决了根本问题,受影响的功能恢复正常. 我们感谢你的耐心.
自动翻译自官方事件更新。
我们正在调查使用gen3资源类开始工作方面的延误.
我们正在继续调查使用gen3机器执行器影响客户的高档等候时间。 受影响的工作可能需要比通常更长的时间才能开始。 一旦有更多的信息要分享,我们将提供另一个最新情况.
我们已查明了这个问题,并正同我们的提供者一起努力,解决第三类资源的可用性问题。 一等兵和二等兵都全面投入使用.
在协调世界时7月22日19:24至协调世界时7月23日01:50之间,使用gen3预览机(Linux VM)资源类的客户遭遇了延误,在某些情况下,工作未能启动. 我们已经取消了基因3资源类别,同时处理了影响它们的稳定问题。 遗憾的是,在此期间我们无法提供计算能力的工作流程被取消。 受影响的客户应将其资源类别从gen3改为gen2并重新运行这些工作流程。 我们感谢你在我们团队努力解决这个问题期间的耐心.
自动翻译自官方事件更新。
从协调世界时03:18开始,一个子集的客户可能遇到了装入app.circleci.com的错误. 已部署一个固定装置,我们正在监测全面恢复情况。 谢谢你的耐心 因为我们的工程师确认康复。 我们将很快提供另一个最新情况.
在协调世界时03:18至2026年7月22日协调世界时06:04之间,一子集的客户无法访问app.circleci.com. 这个问题已经解决,准入已经恢复正常。 我们感谢你在我们团队努力执行一个解决方案时表现出的耐心.
自动翻译自官方事件更新。
我们已经与 GitHub API 请求找到一个问题, 可能导致一些客户看到工作流程卡入运行状态, 或工作流程无法启动 。 GitHub报导了API事件, https://www.githubstatus.com/incidents/ph5nns5y4gxj 互联网档案馆的存檔,存档日期2014-12-02. https://www.githubstatus.com/incicents/8vfyvq16hzh9 互联网档案馆的存檔,存档日期2014-12-21. 我们正在监测GitHub APIs的稳定性,并将在获得更多信息后更新这一页面.
由于上游API停用, 用户可能需要为这些推力事件重新试验管道.
我们看到从GitHub API恢复的迹象。 我们将保持监测状态,以核实API出错率已恢复.
GitHub API出错率已恢复到正常水平. 事件中,一些客户可能看到管道启动失败或没有收到状态更新. 一些管道可能被卡在运行状态下. * 你应该重新推入或使用UI手动触发未启动的管道. * 中断运行状态下的管道应被取消并重新运行。 如果您遇到任何问题, 请联系 CircleCI 支持 .
□ 总结 2026年7月20日 UTC凌晨0点22分至01点45分,CircleCI客户使用我们的GitHub集成,经历了运行管线的故障并体验了工作流程被卡住. 在这起事件中,一些由用户使用GitHub所触发的管线未能启动或作为出错管线运行. 其输油管失效或作为输油管错误运行的客户应当重新运行. 这是[GitHub的上游API退化](https://www.githubstatus.com/incicents/ph5nns5y4gxj)造成的,它影响了CircleCI用来触发和运行管道的许多GitHubAPI. 到协调世界时01:45,GitHub APIs恢复,客户管道正常运行. 原始 CircleCI 状态页面可参见 [这里] (https://status.circleci.com/incicents/9lvbbs9l87b). # 发生的一切 # # What happened # \(所有时间为世界协调时) 从2026年7月20日00:22起,GitHub开始为以下API请求回回升错误: *`申请/*/提出' * `背书/*/承诺' * `repos/*/*/contents/*`' * `repos/*/*/hoks' * `repos/*/*/houks/*`' * `重置/*/*/钥匙' * `repos/*/*/pulls' * `持有/*/*/现状/*`' CircleCI依靠这些请求来正确触发并运行管道. 00: 22,我们的内部监督 提醒我们这个问题。 我们的团队开始调查,发现少数属于GitHub项目的管线要么未能启动,要么作为出错管线运行. 这包括排定的管道和工作流程。 此外,少数客户工作流程经历了被卡住的工作,需要重新运行工作流程来修复. 01:45,GitHub恢复,管线加工恢复到正常运行水平. 只有事故窗口期间所触发的管道受到影响,客户应当重新运行这些管道. □ 未来的预防和改进过程 我们正在积极努力,在GitHub服务中断期间提高管道处理的复原力,以减少今后类似事件的客户影响。 我们是范围界定的特点,有助于客户在事件解决后采取减少人工步骤后恢复。 客户经验是我们的最高优先事项,我们承诺不断提高我们的系统的可靠性,以适应客户对我们的信任。 请联系我们的支援小组 任何问题或关注.
自动翻译自官方事件更新。
我们正在调查一个问题 顾客可能会发现 CircleCI 网络应用的加载错误 和签名, 以及管道和预定的工作流程 没有启动或运行迟缓。 这与目前影响GitHub的事件有关。 您可以在https://www.githubstatus.com/incicents/gxycch3076xk上了解GitHub的状况. 我们的工程师正在积极调查 一旦有更多的信息要分享,我们将提供另一个最新情况.
我们继续看到GitHub API的高故障率正在影响登录和工作流程处理。 我们将继续监测GitHub API的恢复情况.
发生什么事了? 影响GitHub的上游事件已经得到缓解,现在正在GitHub一侧进行监测. 您可以在https://www.githubstatus.com/上了解GitHub的状况。 你还能期待什么? 访问CircleCI网络应用,登录,以及管道和工作流程处理正在恢复正常. 由于系统稳定,您仍然可以看到断断续续的错误,或者延迟了预定的管道和工作流程. 谢谢你的耐心,我们监测到完全康复.
影响GitHub的API的事件使CircleCI客户遭遇了在网络应用上加载并签名的错误,同时还有管道和计划的工作流程未能启动或运行滞后. GitHub解决了基本事件(https://www.githubstatus.com/),所有受影响的功能都恢复正常. 工作或管道失灵的客户可能重新运行。 事故中被错过的已排定的管线和工作流程不会自动运行,需要重新触发. 我们感谢你的耐心.
自动翻译自官方事件更新。
在协调世界时7月13日15:30至22:40之间,由于来自我们的云提供商的能力限制,我们遭遇了多克(Gen 2)资源类开始就业的延迟. 延迟达到约1分48秒. 自协调世界时约15:45起,我们继续经历这些拖延。 迄今为止,拖延时间已达1分19秒左右。 我们正在与云提供方合作,增加能力,并将随着局势的变化而更新这一事件.
在协调世界时7月13日15:30至22:40之间,由于来自我们的云提供商的能力限制,我们遭遇了多克(Gen 2)资源类开始就业的延迟. 同一问题于协调世界时7月14日15:45至协调世界时22:50相继出现. 延迟时间于7月13日达到25分,7月14日达到24分. 中分+和2个X-大+资源班的等待时间最长. 这起事件的更早更新根据平均等待时间报告出数字,这并没有反映一些顾客可能经历过的最大影响. 等待时间现已恢复正常。 我们正在继续与云提供方合作,以便在下一个高峰期之前增加能力。 谢谢你的耐心.
自动翻译自官方事件更新。
我们目前正在调查一些客户使用Bitbucket作为身份提供者的登录错误.
我们的团队继续调查一些使用Bitbucket作为身份提供者的客户的登录错误.
发生什么了? 一些使用 Bitbucket 关联身份登录的客户受到影响. 这可能还包括客户与GitHub登录,但账户上有一个链接的Bitbucket身份. 此外,一些客户正在经历没有开始或更新的工作流程。 你还能期待什么? 受影响的客户可能看到登录错误. 一些客户也可能注意到无法启动或不按预期更新的工作流程. 谢谢你在工程师调查时的耐心 下次更新 一旦我们有更多信息要分享,我们将提供另一个最新情况
发生什么了? 一些使用Bitbucket相关身份登录的客户受到影响. 这可能还包括与GitHub登录的客户,这些客户的账户上有Bitbucket的身份。 一些客户还经历了没有开始或更新的工作流程。 你还能期待什么? 已部署一个固定装置。 我们正在监测局势,以证实全面恢复。 下次更新 如果有什么变化,我们会提供最新情况
客户登录Bitbucket关联身份时遇到登录错误的问题,以及一些客户经历的工作流程未能启动或不更新的问题已经解决. 你可能仍然经历和需要做的事 - 如果您使用 Bitbucket 作为登录方法, 请登录并重新认证 CircleCI Bitbucket 集成 。 - 如果你的工作流程被卡住或显示 缺少状态检查, 请重新运行它们 取回修复。 - 如果你在采取这些步骤后继续遇到问题,请联系CircleCI支助。 我们感谢你在我们团队努力执行一个解决方案时表现出的耐心.
□ 总结 从协调世界时01:33到2026年7月14日协调世界时05:18,拥有Bitbucket链接身份的客户无法登录到CircleCI,由于Bitbucket的OAuth服务报告账户权限发生变化,一些客户经历了无法启动或更新的工作流程. UTC凌晨5点07分,我们部署了一个修正系统 如何读取更新权限域的固定设备。 一些顾客需要登录 并重新认证 他们的Bitbucket集成 在我们部署固定。 我们的系统继续处理积压的工作,直到协调世界时08:39。 我们感谢我们的顾客在我们解决这一事件时的耐心。 请联系我们的支援小组 任何问题或关注。 本次事件的状况页面可参见[这里](https://status.circleci.com/incidents/gsyjwybg477g). □ 背景情况 CircleCI支持使用 GitHub 账户, Bitbucket 账户, 或电子邮件和密码登录 。 当一个客户登录一个Bitbucket链接的身份,或者当CircleCI需要替客户刷新访问权限时,我们用Bitbucket的OAuth服务交换授权令牌. 这个交换包括一个权限列表,或称"镜",客户已经给了我们,Bitbucket和CircleCI用来确认CircleCI授权代表客户做什么. # 发生的一切 # # What happened # \( 所有时间为 UTC ) 2026年4月8日, [Bitbucket宣布更改其OAuth服务] (https://developer.atlassian.com/cloud/bitbucket/changerlog/#CHANGE-3139):它将重新命名用于报告客户授权的域. Bitbucket运行了一段过渡期,期间既有新旧字段名称,后于2026年5月4日完全去除旧字段名称. 我们的系统还没有更新来识别新的域名,所以一旦Bitbucket完全淘汰了旧的域名,依赖它的要求开始失败. 2026年7月14日01:33,我们的系统开始无法处理返回的Bitbucket链接账户权限信息,因为我们的系统仍然期待旧权限结构. 这导致所有 Bitbucket 链接账户的登录尝试失败,包括客户登录 GitHub 但有一个 Bitbucket 身份与其账户相链接. 01: 59,自动监测 提醒我们的工程组 发现受影响系统的错误激增。 调查组立即开始调查,确认客户在02:38受到冲击,并在02:51通过我们的状态页面向客户发出警报. 至03:00,球队已经将故障隔离到更名的比特巴克特球场. 从03:17开始,属于客户的Bitbucket管道的工作流程状态更新,使用过期的访问令牌开始被放弃. Bitbucket权限检查在我们整个平台上广泛使用,这些权限失败也影响了我们的一些内部工作处理系统. 这导致一个子集的工作流程在没有最终状态的情况下被卡住,并导致一些拉出请求显示缺少或卡住状态检查. 04:21,团队部署初步固定,解决了根本问题,恢复了登录流量,使我们的内部许可系统恢复正常运行. 一些受到影响的客户需要登出并重新登录以取回修复. 到了05:07,团队又部署了两个额外的修补方法,这样我们的系统就可以开始接受Bitbucket新的权限野外格式前进. 我们在05:18解决了这件事 一些客户确实需要登录并重新认证他们的Bitbucket集成,然后才能完全收回账户. 我们的系统继续处理积压的工作,大约8:39恢复到正常水平。 □ 未来的预防和改进过程 我们正采取下列步骤来防止再次发生这种情况并缩短我们的反应时间: ** 我们正在硬化我们的授权代码,以对抗上游API的变化。 ** 之所以发生这个事件,是因为我们的系统没有在第三方身份提供者的回应中优雅地处理一个被更名的字段. 我们将立即更新授权代码,以使来自GitHub、Bitbucket和GitLab的出乎意料或缺失的字段得到安全处理。 ** 我们正在改进我们追踪上游提供者变化的方式。 ** 目前我们已经监控了身份提供商的更改日志 确切的说就是这种破解的更改, 但我们没有在监控中及时添加这种特定的更改, 以便在发货前抓住它。 我们正在审计和扩大这种监测,以便在供应商的通告影响客户之前通知我们的小组。 ** 我们正在改进在最早几分钟内对事件进行分类和通报的方式。 ** 这一事件最初的分类并没有立即反映其针对客户的严重程度. 我们正在完善我们的事件工具和指导,以帮助工程师更快地识别和传达客户的影响。 ** 我们正在提高工作流程处理流程的复原力。 ** 这一事件中下游出故障,导致一些工作流程状态更新被放弃,而不是被再试或明显浮出水面. 我们正在审查这个系统的重试和错误处理行为 这样类似的下游故障就更容易恢复 客户经验是我们的最高优先事项,我们承诺不断提高我们的系统的可靠性,以适应客户对我们的信任。 请联系我们的支援小组 任何问题或关注.
自动翻译自官方事件更新。
我们收到一些报告 我们的mac基础设施 和一个VCS供应商之间 间歇性的网络问题 我们正在调查,并将提供最新情况.
我们还在调查这些断断续续的网络问题 我们很快会再次更新, 我们感谢你的耐心.
我们已经能够重现这个问题,但似乎还是很间断. 我们继续与我们的Mac基础设施供应商合作,帮助诊断这个问题. 我们很快就会更新的.
我们已经确定了问题所在。 一些顾客可能遇到在Github期间因间歇性网络问题而吊起或未能进步的工作. 我们的工程师正在积极监测 同时,我们已经看到成功 将不输出时间增加到15 - 20分钟 允许更多的时间 Github取回。 可通过下列社区指南做到这一点:https://support.circleci.com/hc/en-us/articles/3600007188574-Build-has-Hit-Timeout-Limit
不幸的是,由于与我们的Mac基础设施供应商不断发生断断续续的联网问题,仍有一些客户在Github采取步骤期间可能遇到挂起或未能取得进展的工作。 我们的工程师正积极地与他们合作解决这个问题。 我们感谢你的耐心。 同时,我们已经看到成功 将不输出时间增加到15 - 20分钟 允许更多的时间 Github取回。 可通过下列社区指南做到这一点:https://support.circleci.com/hc/en-us/articles/3600007188574-Build-has-Hit-Timeout-Limit
我们的Mac基础设施供应商正在测试他们的网络配置的改变,以努力孤立问题的来源. 我们正积极验证这是否解决了影响,并将很快跟进另一个更新. 与此同时,将不输出时间提高到15-20分钟继续有所帮助:https://support.circleci.com/hc/en-us/articles/3600007188574-Build-has-Hit-Timeout-Limit
我们确认这个问题是一些从受影响的 VCS 供应商进入的路线 导致显著降低可用的带宽 这会对回取时间产生不利影响 我们正与我们的Mac基础设施供应商合作,试图将入境流量转移到不同的路线上,然而这一过程可能需要较长的时间才能完成. 我们将继续提供最新资料。 正如我们在前几次更新中分享的那样,将无输出时间增加到15-20分钟继续有所帮助:https://support.circleci.com/hc/en-us/articles/36007188574-Build-has-Hit-Timeout-Limit
我们的Mac基础设施供应商已经转移了入境路线,我们看到在VCS恢复的时间。 我们将在今后几个小时内继续监测这一问题。 我们很快就会更新的.
我们继续看到 VCS 缓慢、渐进的复苏时间。 我们很快就会继续监控和更新 我们感谢你的耐心.
我们开始看到VCS再次上升 我们的工程团队正在积极调查,并与我们的Mac基础设施供应商合作解决这个问题. 我们再次感谢你的耐心.
我们的Mac基础设施供应商将更多的流量转移到工作网络供应商,我们开始在VCS获取时间中再次看到显著恢复. 和往常一样,我们的工程组将继续密切监视这个,我们将很快提供另一个更新.
我们继续看到,在过去几个小时里,VCS取得了可观的时间恢复。 我们要解决这起事件,我们的工程组将继续密切监视. 我们非常赞赏你耐心地和我们的Mac基础设施供应商合作。 有问题请联系支援组.
□ 总结 从协调世界时2026年7月13日18:00到协调世界时2026年7月14日23:18,一些在CircleCI的macOS车队上运行工作的客户在GitHub取台阶时遇到挂起或未能进步的工作. 对于这些顾客,GitHub取出通常需要1-2分钟的台阶,需要20-30分钟,然后超时. 造成这个问题的原因是我们Mac基础设施供应商和GitHub之间的网络路径存在能力和路由问题,相关的断断续续的网络问题减缓了GitHub的接取速度. 在整个事件中,我们的团队直接与我们的Mac基础设施提供商合作,确定并调整交通路线,使其远离受影响的网络路径. 我们于协调世界时7月13日19:40解决了初步事件。 该问题于同日协调世界时21:52再起,我们重新开启了事件,到协调世界时7月14日23:18完全解决. 我们的macOS船队几周前也有类似的问题. 从20:18协调世界时2026年6月24日到2026年6月25日03:09协调世界时,顾客遭遇了[类似事件](https://status.circleci.com/incicents/gvysjmkf4ct9),影响了macOS工作到达GitHub的能力. 这一事件也是由我们Mac基础设施供应商的网络线路问题所造成。 我们感谢我们的客户在我们处理这一事件时表现出的耐心。 关于CircleCI和我们的Mac基础设施提供者将采取的具体行动,请见下文。 请联系我们的支援小组 任何问题或关注。 这一事件的状态页可参见[这里](https://status.circleci.com/incicents/n1tc2lw9q7l0)和[这里](https://status.circleci.com/incicents/7cnl777wp9qz). □ 背景情况 CircleCI的macOS工作由第三方Mac基础设施供应商主持. 该供应商通过多个冗余的上游网络路径与更广泛的互联网连接,包括GitHub等服务。 当其中一条路径遇到容量下降或路由问题时,从网络路径沿线的目的地获取代码或依赖性的工作可以放慢速度或间歇地挂起,即使CircleCI自己的平台,第三方基础设施供应商和目的地服务都正常运行. # 发生的一切 # # What happened # (所有时间为世界协调时\) 7月13日18:00,一些运营macOS工作的客户开始经历间歇性故障和延迟从GitHub获取代码和依赖性. 我们18点55分开始调查 并通过状况网页通知客户 到了19:04,我们的Mac基础设施提供商确定了其网络路径之一的延迟增加,并调整了环绕它的交通路线. 找到恢复的时间,我们把事件转到了19:29的`监测 ' 和19:40的`解决 ' 。 在协调世界时20:44,顾客报告说,这个问题已经回归. 我们重开事件,并将现状页更新为21:52 " 调查 " 。 在接下来的两个小时里,我们与我们的基础设施提供者密切合作,收集诊断数据,努力隔离受影响的网络路径。 同时,我们公布了指导准则,建议客户将 " 不产出 " 设置增加到15至20分钟,以便GitHub在间歇性减速期间有更多的时间完成采集,并将状态页移至 " 监测 " 23:35。 在协调世界时7月13日23:35发布环绕工作指南后,我们预计潜在的网络问题将在一夜之间得到改善。 它没有。 在协调世界时7月14日13:59,我们确认客户仍然间歇性故障,并将状态页移回`调查'。 我们的工程小组直接使用我们自己的测试工具复制了故障,这有助于证实这是一个一般性的 " 牵线 " 问题,而不是任何特定建造工具、集装箱图像或软件更新的具体问题。 15:35,我们更新了状态页面,分享我们的基础设施提供者正在测试其网络配置的变化,以隔离问题的来源. 16:31,我们再次更新状态页面,分享我们确定的原因 是一个特定路线的入行带宽减少, 我们正在与我们的供应商合作 将流量转移到另一个路线。 16:36,我们的基础设施提供者查明了受影响的网络路径,并转移了交通,收回了恢复的时间,16:58,我们更新了状态网页“监测”。 到了下午一早,一些顾客再次看到取货时间较慢,我们把状态页移回 " 调查 " 20:18。 我们的基础设施提供者确定了另外两条性能退化的网络路径,并在22:07之前将交通从这些路径转移出。 获取时间在以下几小时内稳定下来,我们把事件 " 解决 " 标为23:18。 总体而言,经营Mac工作的客户在协调世界时7月13日18:00至协调世界时7月14日23:18之间,可能遭遇了部分窗口间歇性工作减速或故障. 我们的基础设施供应商自此报告其整个网络的清洁测试结果,并认为潜在的能力问题源于更上游,更靠近GitHub,而不是在自己的网络内。 我们正在继续密切监测这一情况。 □ 未来的预防和改进过程 我们正采取下列步骤来防止再次发生这种情况并缩短我们的反应时间: ** 我们正在为macOS车队的GitHub-fatch性能建立额外的自动监测。 ** 我们的大规模自动监测没有抓住这一事件。 我们现在特别增加了对GitHub采集物的端到端监测,以便积极主动地发现类似的问题。 ** 我们正与我们的Mac基础设施供应商直接合作,进行更快、更主动的检测。 ** 我们要求我们的供应商建立能够检测退化的网络路径并自动绕道的监测,而不是依赖CircleCI来确定并请求在正在发生的事件中调整路径. ** 我们正在把我们在这一事件中建立的诊断工具变成一种常设能力。 ** 这将让我们能够根据需求检测和复制这种类型的网络故障,而不是在一次正在发生的事件中组装测试基础设施。 ** 我们正在审查我们的事件反应程序,以便有一个充分的确认窗口,然后才能标出与网络有关的事件。 ** 这一事件在早早解决之后短暂地再次发生;我们正在正式确定在结束此类事件之前进行经确认的清洁监测的最低限度时间。 随着调查和补救工作的继续,我们将继续定期提供最新情况。 ** 我们正在积极从一个单一的Mac基础设施供应商**转到多个供应商。 ** 这将使CircleCI能够将即将到来的客户工作量输送到最可用和业绩最好的供应商。 客户经验是我们的最高优先事项,我们承诺不断提高我们的系统的可靠性,以适应客户对我们的信任。 请联系我们的支援小组 任何问题或关注.
自动翻译自官方事件更新。
我们收到报告称 我们的mac基础设施 和VCS供应商之间 间歇性网络问题 我们正在调查,并将提供最新情况.
我们正与我们的Mac基础设施供应商合作 试图缓解。 很快会再次更新.
我们的Mac基础设施供应商已经做了一个修复, 我们开始看到恢复。 我们正在监控,我们很快会再次更新.
我们已经证实了我们的基础设施供应商的修复 和成功的测试 我们的端。 如果客户继续看到任何故障运行,请再次运行成功连接,如果有进一步的问题,请联系支持.
自动翻译自官方事件更新。