哈喽大家好啊,你们的土豆服务器探秘者又回来啦!
这段时间我接到不少私信,问我出甚么事了,我说怎么惠氏,给我发了几张截图。我一看,哦,源赖氏佐田,有两个年轻人,三十多岁,一个体重九十多公斤,一个体重八十多公斤,发帖问我是不是被维基点管理员秘密做掉了,很久没能联系上我,也好长时间没看我上线做盘点了,B站贴吧都没更。
是的,粉粉们,我从地狱回来了。
好吧说正经的,最近三次实在是有点忙了,没空处理这些线上消息。你们给我发的私信我也看到了,太多了,没办法全都回复,只能在这里一起感谢大家的关爱。不过具体到说我在干什么,我只能说暂时无可奉告好吧,要是告诉你们这个,那我饭碗就该丢了。
那话不多说,今天给大家带来的是wikidot最让人印象深刻,闻风丧胆的崩溃事件,Top 5~
IP属地:俄罗斯 来自手机贴吧 1楼 2022/5/19 22:13
IP属地:山东 来自网页端贴吧 2楼 2022/05/19 22:14
楼主下面没有了
怎么都2202年了还在玩马保国烂梗,被抓到缅北弹棉花去了是吧😅
IP属地:西安 来自网页端贴吧 3楼 2022/05/19 22:26
前排例行叠甲:本次盘点中排名的依据为个人体感,鉴于wikidot的崩溃状况和频率因人而异,如果你有频繁经历某一种崩溃现象,并对你造成了很大困扰的经历,那么对于你而言那种现象就是Top 2~
那么开始我们今天的盘点吧!
Top 5:Ajax Request Failed. Code:504
“据说有科学家研究出了在冬天存活的蚊子。”
“Ajax Request Failed. Code:504”是一个较为常见的wikidot崩溃类型,它的出现形式通常是一个浏览器弹窗,显示图上的这些东西,弹窗的样式就因浏览器而异了。它的主要出现原因其实已经从它的code中体现出来了,504的意思就是gateway timeout,意思就是服务器等不到数据,超时了,或者网络连接信号不好。本地页面上传数据到服务器的过程就像你在纸上画画,一条直线画到一半突然手一抖,出现了一个断点,这个传输的过程就被中断了——当然了,这通常不会是你这边的问题,肯定是wikidot的土豆服务器又烧糊了。
为什么这个东西非常常见,但排名最靠后呢?答案很显然,因为它是我们今天盘点的几个崩溃类型中危害最小的一个。就算上传断联,你只需要点掉那个“OK”,然后重新上传一次就可以了,并不会导致你损失什么数据,或者无法访问页面之类的。
一个不那么恰当的类比就像,如果把其他wikidot崩溃事件比作你做菜时切到了手,那Ajax Request Failed这个崩溃类型就好像一个会时不时咬你一口的蚊子。确实会有点痒,而且非常烦人,你不知道它什么时候会咬你,但好在它没有那么明显的创伤。
P.S. 我这边网络不是特别好,发帖会比较慢,大家多包涵。
IP属地:俄罗斯 来自手机贴吧 4楼 2022/05/19 22:34
想起来之前做版式的时候五次保存里就有一次ajax failed😒这东西频不频繁纯看你保存的勤不勤吧,保存一千次能有200次failed,但只保存三次那可能就一次都不fail了。
IP属地:天津 来自手机贴吧 4楼 2022/05/19 22:37
Top 4:无法访问此网站
“我已经加载三十分钟了!”
“无法访问此网站”有几种表现形式,其中一种如图所示,会显示你的链接响应时间过长,这也是这种崩溃类型下最常见的表现形式。图上是Chrome的示例,不同的浏览器可能会显示不同的样式,不过大致意思应该是类似的。它的主要出现原因也是timed out,加载时间过长。如果浏览器认为它加载这个页面时间太长,它就会自动放弃继续加载,免得做无用功。
它只能屈居第四,是因为这个崩溃类型其实并不常见,至少我没看见过很多人经常抱怨过它。毕竟wikidot,尤其是SCP基金会的页面上通常都只有文字和图片,数据总量并不大,想要加载出来并不是什么难事。但是,如果你的页面上有很多listpages或者countpages,这种需要遍历很多特定页面来展示某些结果的module,那你的噩梦可就要开始了。页面加载速度少则半分钟,多则三分钟,见到这个崩溃类型的机会多得是,重灾区正是使用各种listpages module的作者页面,崩溃复现率简直令人发指。
不过,以上都是wikidot心情好的时候才会出现的事情……如果赶上人流量高,或者服务器烤熟了的时候,wikidot会直接大堵车,那时候你点哪个网页都会加载四五分钟然后无法访问,纯纯恶心人。这种大堵车不常见,但一旦出现就会波及所有人,最广为人知的应该是那次2021年CN2k前夕的那次大堵车,不知道大家还记不记得。坊间传言说那一次是站长卖了自己北京的一套四合院,把钱给波兰那边打过去,他们整个换了一遍土豆服务器才整好的。不知道真的假的。
IP属地:俄罗斯 来自手机贴吧 5楼 2022/05/19 22:47
Top 3: Please Try Again等
“就算重来一次也不会成功的。”
Please Try Agian、504 Bad Gateway、Wikidot Temperately Unavailable,它们可能有着不同的名字和成因,但都有着相似的表现形式。点进一个链接,无需等待加载时间,立刻跳转到一个空白页面,上面有几行大字,告诉你你需要重新加载,或者暂时无法访问,但无论你怎样重试,结果都是一样的无法访问。就像数学一样,不会就是不会,努力也不会有什么结果。
这种崩溃类型最独特也是最能区分于其他前两种崩溃类型(其实还包括下一种类型)的地方在于,它普渡众生。其他类型的崩溃都是极具个人化体验的,如果你经历了一次崩溃,那么大概率其他人不会经历。即使你始终“无法访问此网站”,你或许可能拜托其他人帮助你加载出来并获得你想要的信息。但是,如果出现了try again或者unavailable这样的崩溃,那么你的选择恐怕只剩下到社交软件上和其他写手一起痛骂波兰程序员了,因为在同一时间,所有的人都访问不了wikidot。Try again的福音平等地关怀着每一个人,这种别样的“社群互动感”可能也是它能成为最让wikidot写手们记忆犹新的崩溃类型的主要原因。
有对这方面关注的朋友可能会发现,近些年来,wikidot出现这种崩溃类型的情况越来越频繁了。有些人可能觉得这是波兰程序员摆烂的结果,但经过我的调查发现,事实可能并不像我们想象的这么简单。众所周知,wikidot虽然名满天下,但他们使用的服务器是需要经常更换的土豆。不管怎么说,运行网络服务器终归是一个比较复杂的工作,这就对他们使用的土豆品质有一定程度上的要求。根据Wikidot每年的财报可以得知,为了节省开支,他们采购的土豆大多是当地种植的品种,而从2018年开始,波兰就开始连年经受严重的干旱和春季霜冻等反常气候。这些气候变化被当地认为是厄尔尼诺现象的一种影响,直接导致了当地产出的土豆内部淀粉含量的稳定性降低。另外,在2019年,欧盟对农药政策进行了一些调整,禁用了波兰当地原本用在土豆作物上的一些强力农药,致使当地对虫害的控制能力大幅下降了。更加雪上加霜的是,在2020年疫情之后,波兰甚至失去了从荷兰,德国等国家进口高质量土豆的渠道。种种原因导致wikidot的服务器质量在这几年里连年下滑,这根本不是区区几个程序员能拯救的问题。
想必现在大家也在经历一场惨绝人寰的try again大崩溃。可惜wikidot当年也是英雄一世,一套现实连招下来竟沦为残寇。真是时也运也啊。
IP属地:俄罗斯 来自手机贴吧 6楼 2022/05/19 22:59
Top 2:saving page…
荣耀、威严、能力、权柄,皆归于他。
从万古以前到如今,直到永远。
Saving page的大名,相信即使是从来没有使用过编辑功能的纯读者,哪怕是根本没上过网站的玩梗云鬼,也是不可能不认识的。它是几乎所有人公认的wikidot最恶性bug,行踪诡谲,防不胜防,复现概率远远高于前面所列举的任何崩溃类型。它的威名不止体现在其普遍性上,更在于其极强的危害性,如果没有应对的经验,它能在顷刻间将你的草稿化为乌有,让你一下午的时间付之一炬。它是无数写手背弃wikidot的原因,是笼罩在“保存”键上散不去的阴云,所有人都无法摆脱的梦魇。
Saving Page就像是这个网站的一体两面。早在wikidot创立之初,就已经有人发现了它的存在。一位名叫ninemila的用户在2006年12月发帖称,自己的页面在点击保存后,saving page的示意进度条不会消失,刷新后发现此次编辑没有保存——太熟悉了,是不是?就像深藏在南极冰川里的病毒,这个bug从太古生存至今,从未改变,与网站同生共死。
在这名用户前些年出版的回忆录《To My Life》中,他声称尽管当时并没有引起重视,但他在2007年的6月左右因为这一bug与wikidot的工作人员进行了历时许久的通话,详细描述了当时触发这一崩溃案例的环境、他的编辑内容、时间,等等内容。与他接洽的工作人员一开始并不相信他,因为这一bug,当时的技术人员声称,“极为难以复现,也几乎不可能存在”。这一质疑在对面成功触发了第一次saving page后突然荡然无存。这一用户声称,在那之后,对面的声音中浮现出了明显的喜悦的情绪,并且开始不断要求他提供更多的崩溃当时的细节,每成功触发一次,对面的语气就激动几分,最后甚至欢呼了起来。而在他询问对面为何如此的时候,对面的态度却骤然冰冷,只说了一句“你可以挂断了”就再也没有理他。这次诡异的通话经历困扰了他很长时间,而此后他再也没有使用过wikidot。好巧不巧,根据wikidot统计学家Allen·Lager去年的最新报告,saving page还真不是从一开始就一直与wikidot同在的。它的出现频率从某一时间节点开始骤然升高,而此前的复现率几乎可以忽略不记;这一时间点正是2007年6月到7月期间。这么看来,ninemila在回忆录中声称的,wikidot在借由saving page培养低危网络病毒的指控恐怕并不无道理。不过他的另一个猜想,说saving page作为某种外来生命控制了wikidot技术人员,即使在今天看来也过于扯淡了。听一乐吧。
如今,在古往今来无数能人异士的努力下,无数预防saving page出现的组件,以及帮助人们在遇到saving page时自保的教程都已经广为流传。即便如此,依然有数不清的wikidot新用户饱受其害。这一流毒源远流长,除之不尽,断其不绝。说它是Top 2,我话说完,谁赞成?谁反对?
IP属地:俄罗斯 来自手机贴吧 7楼 2022/05/19 23:31
Top 1:波俄事变
“从没想过要伤害谁~”
是的,你们没有想错,这里的波俄事变指的正是发生在2022年5月20日,震惊了全世界的wikidot大崩溃事件。事故发生当时,所有SCP相关的网站会随机出现多种崩溃类型,这一现象进而蔓延到全部wikidot网站上,导致在相当长的一段时间内,没有任何人能够访问任何页面。转天中午,wikidot官方发布公告,称俄罗斯黑客攻击了wikidot的服务器,进而导致了此事件。在此之后,所有俄罗斯ip都被禁止访问wikidot页面,历史的转折也由此开始。
当然,这是明面上的说辞。只要大家仔细想一想,就能发现其中端倪:wikidot的服务器,真的需要被人“攻击”才会出现这些状况吗?
答案当然是否定的。就算放着不管,wikidot的服务器也会自己烂掉。更何况,wikidot使用的土豆服务器技术本就脱胎于俄罗斯,也就是传说中的谢尔盖的土豆服务器技术。在wikidot刚刚成立的时候,他们对这一技术进行了“符合当时年代的改良”,增加了服务器的稳定性,减少了需求的土豆数量,我们姑且可以称之为谢尔盖式服务器2式。不过,并非我想要诋毁波兰程序员的能力,但他们既没有早期的技术积累,也没有能反复迭代的能力。其他我们熟悉的土豆服务器使用者,例如育碧Ubisoft,从90年代就开始改良这一技术,如今已经迭代了三十多次,实现了依靠单一的一颗土豆来带动整个服务器,并外接其他蔬菜增加其运行速率和稳定性的功能。而wikidot的服务器版本则彻底停留在了2式,十几年来从没有任何进步。不能适应时代的潮流,也早晚被时代所淘汰。
说回波俄事变,经过后续的内部调查,我们发现事情其实是一个美丽的连环巧合。首先一个必须要了解的背景是,欧洲的很多基本菜式离不开土豆,因此在疫情期间,土豆成为了兵家必争的战略物资。从2020年开始,欧洲各国一直在尝试争夺彼此的土豆进口渠道,波兰虽然实力不弱,但在这场争夺战中依然占不到便宜。另一方面,俄罗斯方面其实也在一直研究并改良谢尔盖的服务器技术,因此如果你能搞到政府的财报,你会发现他们每年定期会有一笔相当可观的支出,用来购置大量的实验用土豆。在这种情况下,留给波兰的土豆资源本就捉襟见肘,价格自然也是水涨船高,这使得wikidot总部失去了本应该有的,充足的服务器替换件储备。他们因此拉长了更换服务器的安全间隔时长。
我们目前认为服务器自身的崩溃是最先发生的。我们都知道,土豆在发芽后,其内部的淀粉含量和稳定性就会低于未发芽的同体积个体,而这两者是制衡服务器运行时所产生温度的核心。一旦失衡,土豆就会很快被烤熟。当时的情况正是如此,但即便这样,通常而言,被烤熟的服务器也可以勉强支撑十几个小时,足够技术人员将新的土豆替换上来。
压垮骆驼的最后一根稻草是当夜值班的醉酒工作人员和他带去工位的宠物仓鼠,相信聪明的小伙伴听见这两个要素就知道是怎么回事了。对的,醉酒的工作人员没能及时更换服务器,也没能及时给他的仓鼠喂食,于是饿急了的仓鼠开始疯狂啃食服务器。主要结构被破坏,服务器彻底崩溃,而当我们到达现场时,人还在醉着,而仓鼠早就已经撑破肚皮,魂归天外了。讽刺的是,那只仓鼠是一只侏儒仓鼠,原产地正是俄罗斯——因此说是“俄罗斯黑客攻击了wikidot的服务器”,似乎也并无不妥。
时值战争敏感时期,wikidot恰好需要一个理由与俄罗斯割席,此次事件也成为了一个相对合理的台阶。其中曲折过于神秘,我认为将其列为Top 1再合适不过。
那么我是土豆服务器探秘者,我们下期再见~
IP属地:俄罗斯 来自手机贴吧 8楼 2022/05/19 23:51















