有些上传失败
Issues轻微事件
- investigating
上传到 Sirv 的一些账户失败, 因为服务器有问题 。 这也可能防止图像偶尔显示. 我们正在努力尽快解决这一问题.
- resolved
问题的原因已经确定,现已得到全面解决。 在此期间,大约25%的Sirv账户可能经历了一定比例的文件上传失败. 稍稍重试上传可能已经成功,因为这只影响到少数请求。 目前正在进行审查,稍后将在此提供进一步资料.
自动翻译自官方事件更新。
46 Sirv incidents · 2014年11月 — official updates, affected components, duration and resolution details.
上传到 Sirv 的一些账户失败, 因为服务器有问题 。 这也可能防止图像偶尔显示. 我们正在努力尽快解决这一问题.
问题的原因已经确定,现已得到全面解决。 在此期间,大约25%的Sirv账户可能经历了一定比例的文件上传失败. 稍稍重试上传可能已经成功,因为这只影响到少数请求。 目前正在进行审查,稍后将在此提供进一步资料.
自动翻译自官方事件更新。
少量上传和请求由于Sirv主数据中心的多起网络开关故障而返回出错. CDN请求正常运行. 我们正在密切监测局势,并将在获得更多信息后提供最新情况.
所有服务恢复正常,请求正在完成.
这个问题由影响Sirv主数据中心的核心路由器断层所引起. 这导致了文件存储和上传的短暂,间歇性断断续续的中断,涉及所有传输类型:API,S3和FTP. Sirv自动切换到它的故障处理服务,因此文件处理和交付继续正常进行. 疾控中心的请求也继续正常。 一旦数据中心解决了核心路由器断电问题,所有服务便得到恢复.
自动翻译自官方事件更新。
在德国,对一些请求的答复时间比正常时间慢,少数请求正在赶出时间。 这个问题正在调查之中.
这个问题已经得到解决。 其中一台服务德国的服务器超载,反应比平时慢. 服务器现在又健康了 我们正在审查应采取哪些行动来减少再次发生这种情况的可能性.
自动翻译自官方事件更新。
加利福尼亚州的一些请求进展缓慢,少数(不到2%)请求失败. 这正在调查之中,可能与今天在洛杉矶部署的新CDN服务器有关.
这个问题已经得到解决。 这个问题的起因是 影响到我们洛杉矶新的数据中心的数据包丢失。 数据中心将这一问题追溯到其上游供应商Arelion,后者正在经历网络不稳定。 当Arelion作为上游供应商暂时被停用,交通通过其他供应商改道时,这个问题就已经解决了. 我们要求数据中心在此种情况下自动和迅速地确定和调整交通路线。 然而,这个问题的解决速度不够快,鉴于这个问题是在通过这个新的数据中心后不久发生的,我们决定停止使用它。 目前所有流量均从我们最初的洛杉矶数据中心(截至2025年4月7日)进行接驳.
自动翻译自官方事件更新。
由于服务器集群问题,一些文件上传尚未完成. 原因正在调查中。 这个问题影响到少数账户。 如果您的文件上传失败, 请等待这个问题解决 .
这一问题仍在进行中。 问题的原因已经确定,我们正在努力尽快解决这一问题.
这个问题已经得到解决。 造成这一问题的原因是一个集群的两个服务器同时失效. 这影响了新文件上传到Sirv账户的约20%. 上传被设计为在一个服务器倒下但两个服务器倒下时继续正常运行,一些上传可能失败,这就是所发生的. 由于一个出口商服务停止在一个服务器上运行,然后另一个服务器运行,所以它们失败了. 错误使服务无法重新启动 。 随后的第二期由于服务器无法被重启,使得决议花费了比预期更长的时间. 这是由于一个过时的BIOS. BIOS更新后,服务器被重启并解决了根本问题的原因. 为了防止这种情况再次发生,我们用数据中心实施了一个新的BIOS管理程序。 我们还在缩短硬件更新周期,以便更频繁地进行硬件升级。 为了减少出口商服务故障的再起机会,我们取消了一个程序,并且正在监测服务器的计量标准.
自动翻译自官方事件更新。
在协调世界时09:29至09:32的3分时间内,一些请求没有被退回. 这个问题只影响到某些请求,而只影响到某些账户。 大多数账户没有受到影响.
这个问题在3分钟内得到解决. 原因是同时重启多个服务器,而原本只应当重启1个服务器. 这是对我们标准作业程序的一个监督。 我们正在研究如何自动保护和防止这种情况再次发生.
自动翻译自官方事件更新。
服务器故障导致一些文件上传失败,导致数量有限的账户出现故障. 这个问题正在得到解决。 如果您体验到上传失败, 请稍候再试 .
这个问题已经得到解决。 异常多的服务器同时失败. Sirv被设计为在服务器出故障时继续正常运行,所有系统都确实继续正常运行,但一些文件上传失败. 我们正在考虑今后可以作出哪些可能的改革来帮助这种局势.
自动翻译自官方事件更新。
为 API 文件上传请求, 将返回504次超时.
API继续从上传请求中重负. 一个促成因素是AI图像升级请求数量众多,处理这些请求比通常需要更长的时间. 请求排队导致的延迟导致一些API文件上传请求以504个响应失败.
已经作出改变,这个问题几乎得到解决。 大多数上传请求都成功.
API上传超载几乎完全解决.
这个问题已完全解决。 当重型图像提升API请求超载上传API时开始发行,导致部分API请求还原出504个错误. 这个问题已经解决了,但一次敲门效应导致大约5%的API请求以502个响应失败. 为防止再发生这个问题,已经进行了改进来减少图像提升的负荷并更好地分配负荷. 还正在改变伐木和警报,以更快地查明这种情况。 这个问题最大的影响是在Sirv WordPress插件上. 该插件正在所有管理员页面上发送一个API请求,该请求阻止页面加载,直到收到响应 - 通常小于300ms,但如果API请求超时,最多可达20秒. 不需要这些API请求,所以在协调世界时1805年(11月14日)发布了一个新的WordPress插件版本v7.3.3来去除这些请求并阻止这个问题再起: . https://wordpress.org/plugins/sirv/ -- -- -- -- -- -- 如果您使用 Sirv API, 我们建议您的脚本被写入来重试收到502个响应的请求 。 关于处理502和其他错误答复的建议,请参见:https://sirv.com/ help/articles/sirv-rest-api/#error-loating-guide
自动翻译自官方事件更新。
一些文件不会被退回到少数账户。 这个问题正在得到紧急解决.
这个问题已经得到解决。 在协调世界时1052分,对少数账户(12个账户,50 000多个账户中的12个账户)提出的请求中,约有11%是在本应退回200个答复时归还404个答复(文件没有找到)(OK)。 当Sirv团队查明了这个问题后,他们迅速努力解决了这个问题,到UTC1206年,所有这样的请求都在归还正常的200个响应. 出现这个问题的原因是Sirv工程师在配置新的存储集群硬盘时的配置不当. 一些请求是在新硬盘准备接受之前提出的。 被归类为重度等级3:轻微影响.
自动翻译自官方事件更新。
对Sirv的25个CDN位置的大量请求正在返回一个错误. 我们的工程师们正在迅速工作,以查明和解决问题.
这个问题已经得到解决。 它是由一个软件守护进程在多个服务器上同时失败而导致的. 这是一个轻而高效的服务经理,过去从未失败过. 在此期间,有3%至58%的HTTPS请求返回了错误,这取决于25个CDN地点中哪一个收到请求. 我们现在正在调查为什么发生这种情况,并将采取行动防止这种情况影响今后提供服务的情况。 被归类为严重程度等级2:有意义的影响.
自动翻译自官方事件更新。
CDN出现415个错误。 我们的工程师正在调查原因.
我们正在继续调查这一问题的原因。 其性质复杂. 它作为415个错误代表自己,从零字节的文件. 此外,还有500个错误,虽然比率较高,但较低。 大多数请求都得到200次成功的响应。 我们的工程师正在努力理解和解决这个问题.
415出错的问题是由一些文件被截取而来,这意味着它们失去了部分内容. 这些文件在 my.sirv.com 的控制面板中显示有0字节. 今天上传的文件更有可能被截断,尽管文件的截断似乎已经发生很长时间了. 这一点没有被确定,因为它们的性能是完全正常的,因为缓存了非通口版本. 在基础设施升级之后,短短文件问题今天才显出。 服务器缓存被清除,被截断的版本变得明显. 短跑的原因被认为已经是一个软件错误,现在已经解决了. 我们目前正在努力恢复被截断的文件,这一过程可能需要几个小时到几天的时间。 如果您可以重新装入任何当前没有装入的文件, 请现在就这样做 。 这个问题估计会影响大约~0.2%的档案.
大约80%被截断的文件已经找到。 415个错误的数量已大幅下降,尽管仍然上升。 为了充分解决问题,需要用原始文件来取而代之的是剩余的截取文件. 我们正在努力寻找这些剩余文件,尽管它们很难获得,可能需要几个小时或几天的时间。 对于尽可能快的解析,建议您重新加载文件. 这类文件会在您的账户中显示为 0 字节 。 开始于以下 URL,查看过去30天上传的所有文件列表: https://my.sirv.com/#/search/?created=30d 通过按大小、 递升排序结果来查找任何零字节文件 。 一旦我们收到其余文件的消息,将发布另一个最新消息.
我们正在继续收回剩余的少量短文。 估计还需要12至24小时。 如果您有任何文件没有被服务,您可以通过重新装入直接解决. 我们正在创建一个生成零字节文件列表的工具 。 如果您想要您账户中任何零字节文件的列表,请在https://sirv.com/help/support/#support上提交请求,工具一旦准备好,我们将准备一个列表. 无论如何,我们将继续努力 收回所有的文件。 如果您使用 Sirv 的 Autofetch 特性上传文件, 您可以简单地删除零字节文件, 并在下次请求时从您的远程位置重排它们 .
已恢复更多文件 。 415个出错率持续下降. 您可以在您的账户页面中看到415个错误列表: https://my.sirv.com/#/analytics/errors/415? from=20231206&to=20231206 您可以上传文件来解决文件中的415个错误 。 如果您需要, 我们可以提供零字节文件列表 - 请通过此表单询问 Sirv 支援团队 : https://sirv.com/ help/ support/# support 我们正在继续恢复尽可能多的文件.
造成415个错误比率上升的问题已经解决。 被截取的文件是由一个软件问题造成的,它用零字节写出一些文件. 由于是软件,这使得被截取的文件被复制到所有版本的主文件. Sirv三相复制了每个文件以防硬件问题(服务器或硬盘故障),然而,更新后的文件通过了所有检查并忠实地三相复制了文件. 它的存在没有被发现,因为缓存版本的文件被用于处理和交付. 所有系统都运转良好 直到昨天的基础设施升级 缓存文件被清理 根本原因通过识别并纠正了导致分流的软件问题而得到解决. 该工程于协调世界时12月5日到1500年完成. 然后的任务是恢复那些被截断的文件。 在整个平台上,大约0.2%的文件受到影响。 在这些档案中,我们能够恢复95%至100%,这取决于账户。 任何恢复率低于100%的账户都会被发送一个零字节文件列表,通过再次上传文件来恢复. 请用文件列表查看我们的邮件 。 如果您需要帮助, 请通过下列 URL 通知我们 : https://sirv.com/ help/ support/# support 正在对这一问题进行彻底调查,将通过电子邮件详细报告。 报告将列出为防止任何可能重复这一问题而正在采取的行动,以及正在设计的改进和新特点。 我们向所有受这一问题影响的客户道歉。 这是第一次丢失主数据。 我们将从中吸取一切可能的教训,使Sirv变得更加强大和可靠.
其余99%以上的短文件现已恢复。 向任何受影响的用户提供了受影响文件的确切清单。 这个问题没有剩余影响。 被归类为重度一级:临界影响.
自动翻译自官方事件更新。
从协调世界时0419起,从悉尼CDN位置返回了429个更高误差.
这个问题于协调世界时1031年解决. 原因是服务器配置错误,使得悉尼CDN的位置可以看到来自同个IP地址的所有请求,而不是真正的客户端IP地址. 这引发了DDOS保护,以限制同一IP的请求过多. 对许多请求作出了429个答复。 当悉尼数据中心网络无法使用时,这个问题似乎是一个极为短暂的问题。 这个问题只持续了大约1分钟。 然而,在我们团队恢复了悉尼CDN位置后,实际事件立即开始,这就是服务器错误配置被应用的时候. 这个问题在我们发现错误配置并纠正后就解决了. 正在采取多种行动,防止这一问题再起并减少今后类似但不同问题的影响: - 新问题提交表 - 对背景敏感的解决建议 - 更大的内部警报,只有悉尼CDN的位置受到影响。 被归类为重度等级3:轻微影响.
自动翻译自官方事件更新。
11月22日协调世界时18:30左右,我们开始将主文件数据库升级为新的更强大的集群. 在升级期间,API搜索查询失败.
协调世界时11月23日10时35分,升级完成并恢复了搜索正常运行. 没有停机时间,所有系统都正常运行,只是API搜索请求一直在回回错误回复. 由于其他API请求恢复正常,所以这个问题没有被识别出来,所以API总的错误响应只略微提升,没有触发警报. 这个问题是在事件发生后,一个用户的报告引起调查后确定的。 为了在今后自动确定这些问题,我们正在评估具体监测搜索API的方法。 我们还将更新 Sirv WordPress 插件,以便在搜索失败时显示清晰描述的信息 。 被归类为重度等级4:最小撞击.
自动翻译自官方事件更新。
My.sirv.com的文件管理工具由于服务器故障而正在缓慢地加载. 文件列表和文件搜索需要2到20秒,而通常需要1到4秒. 失败的服务器正在被替换,我们期望速度在72小时内恢复正常. 随后将在未来3个月对整个控制面板服务器集群进行重大升级.
我们正在等待提供一个新的服务器来加入集群,然后UI的导航速度会变得快得多.
新服务器于11月14日晚被部署,并逐渐填补了缓存. 控制面板现已恢复到原来的快性能. 更多服务器正在升级,因此控制面板将在未来两周内更快地加载. 被归类为重度等级4:最小撞击.
自动翻译自官方事件更新。
10月23日协调世界时14:10,向华盛顿特区CDN地点提出的请求急剧增加,导致一小部分请求缓慢返回,超过2秒。 这一问题在今后3个小时内有所缓解,尽管平均答复时间仍然延长。 次日14点发回:协调世界时10月24日32分发回,比前作更严重地造成17%的请求慢入-超过2秒,有的长达30秒. 这个问题影响到Sirv的25个CDN两个地点.
该问题于协调世界时10月25日06:48解决. 调查指向两个原因: 猛增的原因是Sirv的DNS供应商将洛杉矶的持久性有机污染物请求传递到华盛顿特区。 孤立地说,这本来是好的,但数据中心似乎使接收服务器的带宽受限,造成反应缓慢。 调查正在进行中,尚未得出明确结论,需要与我们的DNS和数据中心提供者合作。 已经采取行动防止这一问题再次发生。 稍后将在此提供一份详细的报告.
对这一问题的详细调查发现有两个促成因素。 第一个是AWS Route53的更新,它似乎是由AWS于10月17日实施的. Sirv没有改变其Loute53规则,而是改变Route53服务本身。 洛杉矶持久性有机污染物与其他持久性有机污染物的路由逻辑略有不同,而AWS的更新导致路由行为不同,交通正向华盛顿下降。 这一点没有引起注意,因为他的负载较高,而且请求被成功退回,因此没有引起注意,因为华盛顿特区能够处理额外负载。 第二个因素是10月23日和24日美国贸易高峰时段的流量高于正常流量。 这两个因素加在一起,使华盛顿DC硬盘返回请求的速度大大慢于正常. 自这一问题发生以来,我们采取了多起行动来防止它再次发生;减轻类似的可能事件;并在发生事件时加快解决时间。 行动包括: - 应用了新的路线逻辑. - 华盛顿特区的能力已经增加。 - 增加了所有其他CDN地点的储备能力。 - 引入了新的容忍度,将CDN地点从线路中移除。 - 增加磁盘监测,帮助及早准备能力升级。 - HDD被替换为SSD. - 更新《标准作业程序》,供我们的支助小组调查和应对类似问题。 被归类为重度等级3:轻微影响.
自动翻译自官方事件更新。
更早的上传使用率高的一期还原了,少数API上传失败.
这个问题在上传量正常后9分钟内解决. 在此期间,大约98%的上传成功,2%失败. REST API的上传限制在每小时,以您 Sirv 账户的用法页面 https://my.sirv.com/#/account/usage上指定的数量为限. 如果使用REST API来上传图像,最佳做法是检查每个上传请求的响应,如果收到错误响应(400,401,429等),然后暂停上传并稍后重试. 参见这里的文件: https://sirv.com/ help/articles/sirv-rest-api/#error-loating-guide 被归类为重度等级4:最小撞击.
自动翻译自官方事件更新。
少数REST API上传请求由于负载非常高而失败.
一旦上传API上的负载开始下降,这个问题就解决了. 在此期间,大约97%的上传成功,3%失败. REST API的上传限制在每小时,以您 Sirv 账户的用法页面 https://my.sirv.com/#/account/usage上指定的数量为限. 如果使用REST API来上传图像,最佳做法是检查每个上传请求的响应,如果收到错误响应(400,401,429等),然后暂停上传并稍后重试. 参见这里的文件: https://sirv.com/ help/articles/sirv-rest-api/#error-loating-guide 被归类为重度等级4:最小撞击.
自动翻译自官方事件更新。
其中一款洛杉矶CDN服务器变得不健康并开始在协调世界时0:00返回4xx错误. 它在90秒后被从路由中移除,再过60秒内,所有流量被接通健康服务器.
这个问题在3分钟内自动解决. 被归类为重度等级4:最小撞击.
自动翻译自官方事件更新。
向Sirv CDN的伦敦POP提出的一些请求,由于负载高,正在返回错误. 这一持久性有机污染物服务于联合王国和爱尔兰。 我们正在拟订一项决议.
这个问题已经解决,目前正在监测之中.
伦敦一款CDN服务器收到的一些请求由于结合了本地DNS分辨率和脉冲网络超时而失败. 这个问题从协调世界时12:15开始,于协调世界时13:32解决. 在此期间,来自英国和爱尔兰的请求中有25%回复了404或500个错误. 这个问题本可以早些解决,但几个小时前一个无关的SSL证书验证失败,阻止了我们的监测系统收到警报。 已经进行了一些改革,以防止这一问题再次发生。 SSL证书问题已经解决;已配置了二级独立监测;正在试验另外的卫生自动化,有可能自动解决这些问题。 被归类为重度等级3:轻微影响.
自动翻译自官方事件更新。
这个问题于协调世界时07:55解决. 在协调世界时6:25,一些向印度的CDN POP(为印度服务)提出的要求开始返回404个答复(文件没有找到),而不是200个答复(OK)。 这个问题发生在更新全球所有CDN服务器14小时后。 所有持久性有机污染物都表现良好,包括印度持久性有机污染物,但印度持久性有机污染物没有成功更新,最终开始出现错误。 一旦确定这一问题,就通过向印度持久性有机污染物重新部署更新程序来解决。 事件期间,94%的请求回复出错误. 向所有其他国家提出的请求均照常归还。 为防止这一问题再起,正在为部署进程的一部分制定新的自动部署规则,因为那里只有人力检查。 还正在建立一个额外的警示指标,以查明部署失败的情况。 我们向所有受这一事件影响的客户表示歉意,我们正在评估其他的变化,这些变化可能有助于防止任何可能的重复。 如果出现这样的CDN问题,您可以控制的一个即时解决方案是暂时在您的 Sirv 设置中禁用CDN : https://my.sirv.com/#/count/ settings/ domains 被归类为严重程度等级2:有意义的影响.
自动翻译自官方事件更新。